RE: replay field size

[Ran Atkinson <[e-mail]>]

--- On Sun, 9 Feb 1997 15:42:07 -0500  Roy Pereira <[e-mail]> wrote:


> Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention) 
> released with a 64-bit replay counter if so many of us objected?

Because contrary to your assertions, there were NOT (repeat NOT)
many objections to the 64-bit counter _during WG Last Call_.  A very small
number of people do NOT constitute "many".  

Process aside, the technical merit is slight.  The amount of code 
needed for 2 replay sizes is clearly small (evidence some of the 
conforming implementations that existed prior to Last Call).

The reason last call exists is to provide a "last" opportunity to 
object before things move forward to standards-track status.  Input
needs to arrive during the Last Call period, not afterwards.

Participants are expected to remain current with the drafts all the
time, last calls live at least a week so that folks can have a chance
to re-read the draft before it proceeeds.  If folks do not take the
time to make their specific issues known to the WG chairs during last
call, that is the choice of those individuals not the fault of the
chair(s).

> Furthermore, why wasn't a generic digest algorithm RFC released 
> (HMAC-x Authentication) instead ?  

The WG chose to proceed in the way it has.  The changes Steve Kent
has proposed would increase the fixed structure to both AH and ESP.
If the WG decides to accept his edited drafts for Draft Standard, 
then a different approach can be employed down the road.  At this point,
a crucial consideration is avoiding making existing conforming
implementations suddenly non-conforming by issuance of new RFCs.
My understanding has always been that Steve's changes don't make
existing conforming implementations suddenly non-conforming.

> We should be able to just plug in a new cipher algorithm and a new 
> digest algorithm without having to re-invent the wheel.  Just plug in 
> their identifiers and go...

There _is_ more to it than just identifiers.  Different algorithms have
different modes and different resulting data sizes and IVs and so forth.
With AH HMAC SHA-1 there was the question raised of using the standard
160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
If one truncates, then the method/process of truncation needs to
be openly and clearly specified.  Just assigning identifiers will
tend NOT lead to interoperable implementations.  Additional structure
to the base specifications will help, but is probably not a panacea.

Ran
[e-mail]