[Babel-users] Babel authentication I-D version 01

[Denis Ovsienko]

22.01.2013, 19:27, "Gabriel Kerneis" <kerneis at pps.jussieu.fr>:
> Denis,
>
> On Thu, Jan 10, 2013 at 12:05:53PM +0400, Denis Ovsienko wrote:
>
>>  This is the next version of the Babel authentication spec:
>>  http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01
>
> I did not read version 00, so the following are general comments not necessarily
> related to recent changes.
>

Thanks for the feedback, Gabriel.

> Overall, the document reads well.  It gives a very good level of details for
> someone intending to implement packet authentification, with rationale for most
> design choices and pitfalls to avoid, as well as possible optimisations.  At
> first, I thought most of these advices should be moved in non-normative
> appendixes; but in fact it really helps understanding how this mechanism works,
> and by the end of the document I got used to having them intertwined with the
> description of the mechanism itself.
>
>    [RIP2-AUTH] established the reference method of HMAC construct
>    application housing the computed authentication data inside the
>    message being authenticated.
>
> I do not understand what this means.

I will refine this sentence.

>
>    Since any fixed arbitrary value of a padding constant does not affect
>    cryptographic characteristics of a hash algorithm and the HMAC
>    construct, and since single-octet padding is more straightforward to
>    implement, the padding constant used by this mechanism is 0x00
>    single-octet value.
>
> It would be nice to either have a reference for "does not affect cryptographic
> characteristics" or give a hint why everybody else is doing it the "magic
> value" way.

If one can control at least a part of a hash function's digest through magic bytes in the message, or, alternatively, withstand such attempts by the same means, this effectively means the hash function isn't a cryptographic hash function. I need some time to provide the reference.

>
>    An implementation MUST allow the operator
>    discovering the effective value of MaxDigestsIn in runtime or from
>    the system documentation.
>
> Or from configuration files (unless you consider this a special case of "in
> runtime"?).  Idem for MaxDigestsOut, etc.  Maybe also mention "such as CLI or
> SNMP" here, as you do it later for ANM Table.

OK, I guess I see a good way to put this right in the next revision. I will work on it.

>
>  3.  Remove all duplicate keys from the copy.
>
> It is essential that you explain how duplicates are removed, since it changes
> the list of ESAs!  Consider the following case: K1,K2,K3,K1.  If you remove the
> first occurrence of K1, then K2 and K3 will be selected (assuming the value of
> MaxDigests is 2), otherwise K1 and K2.

You are right, for me it was obvious that the first copy remains (K1, K2). I will make it into the text.

>
>    No CSA structure field (including HashAlgo, LocalKeyID, and
>    AuthKeyOctets) value has to be unique within a given CSA, or within a
>    given list of CSAs, or within all lists of CSAs of a Babel speaker.
>    […]
>    Another intent is to set authentication key management and security
>    association management as two interfaced, but otherwise independent
>    processes.  This way an implementation can include arbitrary
>    authentication key management process(es) and at the same time
>    conform to the CSA management constraints defined in Section 3.8.
>    This is also the reason why LocalKeyID field has a bit length in ESA,
>    but not in CSA.
>
> I'm probably missing something obvious, but I don't understand this whole
> section.

It is not the clearest section in the document, but I couldn't find any better words to explain the sense I see. I will need time to improve this section.

>
>    configured for authenticated exchange (A) and another not not
>
> Typo (not not).
>

Fixed.

>    Uni-directional links are not specific to use of this mechanism, they
>    naturally exist on their own and are properly detected and avoided by
>    the original protocol (see Section 3.4.2 of [BABEL]).
>
> "Avoided" is a bit confusing in this sentence; "dealt with", "handled
> properly"?
>

Changed to "detected and coped with".

>    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
>               Hashing for Message Authentication", RFC 2104,
>               February 1997.
>
> Use [HMAC] instead of [RFC2104]?

Actually it was [HMAC] in pre-00 revisions, but I tried and found that [RFC2104] was better readable in respective context, especially in the view of the second normative reference, [FIPS-198]. Does [HMAC] look better to other readers?

-- 
    Denis Ovsienko