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

[Gabriel Kerneis]

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.

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.

   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.

   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.

 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.

   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.

   configured for authenticated exchange (A) and another not not

Typo (not not).

   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"?

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

Use [HMAC] instead of [RFC2104]?

Best,
-- 
Gabriel