Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas <[e-mail]>]

Alan,


> On Jan 15, 2024, at 7:25 PM, Alan DeKok <[e-mail]> wrote:
> On Jan 15, 2024, at 6:22 PM, Jeffrey Haas <[e-mail]> wrote:
>> 1. We learn the Seed for this session for the first time.  This somewhat
>> argues we need a bfd.MetKeyIsaacKnown variable.  We require it to not
>> change.  Note that it's critical that we say that we're setting it only
>> after ISAAC authentication has succeeded.
> 
>  That makes sense.
> 
>> 2. We need to generate the ISAAC table from the existing sequence number.
>> It can't simply be sequence 0 because that's attackable.
> 
>  Section 5.1 defines how ISAAC is seeded.  It doesn't use sequence numbers to generate the information.
> 
>  More below.
> 
>> 3. Since we can't set it to zero, and we don't want to generate all
>> intervening ISAAC pages to "catch up" to our random sequence number we
>> started with,
> 
>  But we don't need to "catch up".   We just need to record that we started at an agreed-upon sequence number.

We appear to be in agreement about that, but that's not what the current text seems to say.  In particular, the reset to seq#.

> The important bit is that we have a transition from
> 
> 	 bfd.MetKeyIsaacKnown=false
> 
>  to
> 
> 	 bfd.MetKeyIsaacKnown=true
> 
>  When that transition happens, the sequence number in the packet is used as the start point.  That number is the new bfd.MetKeyIsaacPageBase variable you mentioned.
> 
>  Saving that number means that if we get a new sequence number Y, we can do:
> 
> 	Auth Key index = Y - bfd.MetKeyIsaacPageBase
> 
>  If that value is smaller than 256, the sequence number is in the current page.  If it's 256 or more, then we need to generate a new page.

We're in agreement.

There is one additional corner case to deal with.  Here's the scenario:

A is transitioning from strong authentication to ISAAC.  
A's seq# mod 256 is 255.  
A's seq# div 0 is "0" - the first page.  This is recorded as the local page base for A.
The BFD PDU containing this is sent to B.

The packet to B is lost!

A's next seq# puts it into page 1, index 0.
The BFD PDU containing this is sent to B.

B receives this PDU.  
It notes the seed value, auth ID, and sequence number.
Having received this seed the first time, it treats this seq# as page 0.
Seeking into its first page, index 0, the ISAAC authentication fails.

The issue above illustrates the problem we have with no negotiation between the systems about where page 0 exists.  If BFD were reliable, this wouldn't be a problem.  We have two likely solutions:

Option 1:
"Page 0" is placed into the ISAAC authentication section in BFD.  Doable, crystal clear, and at best noise.  At worst, it provides one additional hint for someone who is brute forcing the passwords.

Option 2:
Each side changing to ISAAC authentication knows that lost packets could be a problem.  The draft says the window we need to keep around is 3*Detect Mult as part of our receive procedures.  Ergo, as long as the side transitioning into ISAAC does so only at a sequence number such that it is within the 3*Detect Mult window, it's reasonable to expect that at least ONE of the packets is expected to get through to the remote side.

Side observation1: I no longer remember why RFC 5880 chose the 3* multiplier.

Side observation 2: The Detect Mult itself can go up to 255.  This pathologically means the session may stay up under hefty packet loss and the best we can do is do the switch starting at index 0 of a new page and hope that we sync up.

-----

Another point likely in need of text in the draft is what ISAAC needs to have done when switching from ISAAC back to strong authentication.  Since the sequence numbers are kept going regardless of the authentication mechanism, ISAAC will need to produce new pages when it flips to strong authentication.  This is to avoid needing to "fast forward" if strong authentication is left going for a while.

-- Jeff