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

[Denis Ovsienko]

24.10.2013, 18:10, "Juliusz Chroboczek" <jch at pps.univ-paris-diderot.fr>:
> Dear Dennis,
>
>>  the next (05) revision of the Babel authentication I-D is available at: http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-05
>
> I had read a previous version of your draft, but I've now started
> a very careful read of -05, reading every single comma and picking as
> many nits as I can.  Unfortunately, I've been interrupted at page 14
> by other stuff (as in student exams and plumber visits).  Since
> I won't have time before the week-end to resume my read, here's
> a summary of what I think right now.
>
> The document (or at least the first 14 pages) is beautifully written
> and very clear -- whenever I had a question, I found out it was
> answered immediately after it occurred to me.  I have a number of
> minor rewordings to suggest to you, but they're really not that
> important.
>

Hello and thanks for the review.

> On the other hand, there is one point that I strongly disagree with (1),
> and one point that I don't understand (2).
>
> 1. In Section 3.1, you say that the default value of RxAuthRequired
> MUST be TRUE.  I strongly disagree with that -- this requirement is
> going to be disregarded by most implementations if you keep it a MUST.
>
> I think that the default value SHOULD be TRUE if there are any CSAs
> configured, and FALSE otherwise.  I'm pretty sure about the SHOULD --
> there are perfectly legitimate reasons to sign the packets you send
> but promiscuously accept any packets you hear.
>

It is already defined to work as you describe, let me explain. RxAuthRequired defaults to TRUE. However, note the first step of the receiving procedure:

   1.   If the current incoming interface's sequence of CSAs is empty,
        accept the packet.

This specific case stands for the default configuration:

   management policy.  The default state of an interface's sequence of
   CSAs is empty, which has a special meaning of no authentication
   configured for the interface.  The sending (Section 5.3 item 1) and
   the receiving (Section 5.4 item 1) procedures address this convention
   accordingly.

Finally, there is the logic to handle the short-circuit:

   The final action conceptually depends not only upon the result of the
   authentication-specific processing, but also on the current value of
   RxAuthRequired parameter.  Immediately after any processing step
   below accepts or refuses the packet, either deliver the packet to the
   instance of the original protocol (when the packet is accepted or
   RxAuthRequired is FALSE) or discard it (when the packet is refused
   and RxAuthRequired is TRUE).

This way authentication is mandated to act as soon as security associations are configured and an explicit non-default short-circuit is possible.

> 2. In Section 2.1, you specify two distinct hash algorithms as
> mandatory-to-implement: RIPEMD-160 and SHA-1.  Not being a crypto
> specialist myself, I would have expected just one mandatory-to-implement
> algorithm.  I'd appreciate it if you could clarify why you need two.

Cryptographic agility. I studied Section 4.5 of RFC6709, took it seriously and made it work.

-- 
    Denis Ovsienko