[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Padding complexities

<SNIP!>
> While I agree that both AH and ESP should be changed so that the padding
> rules specified in the authentication algorithms are followed, a big
> question is what do existing implementations do?

Existing implementations just feed in the message and let the algorithm's
"Finish" routine close it out the way it sees fit.

For example, consider a UDP/IPv4 datagram with one byte of data.

    IP (20 bytes) + UDP (8 bytes) + data (1 byte)

Now AH is inserted, and let's use HMAC-MD5-96 for the algorithm...

    IP (20 bytes) + AH (24 bytes) + UDP (8 bytes) + data (1 byte)

Now assuming an HMAC implementation has the same interface as the MD5 in RFC
1321, there are three functions:

      MD5init()
      MD5update()
      MD5final

Now for HMAC, you have to feed in the key, fine.  The _update_ is what's
important, as that's what you feed bytes into.  So I feed in 20+24+8+1 == 53
bytes (ugggh, pardon that number).  I then call _final_, which pads
implicitly and returns you a digest result.  The receiving side does the same
thing; it feeds in 53 bytes, and gets a digest after calling _final_.  And
you save valuable MTU cruft (the phrase "MTU plaque" seems fitting here) by
not transmitting unnecessary padding on the wire.

No real rocket science here; it's just left up to the algorithm.

I can safely speak for SunOS 5.x, and Mentat, whom I've interoperated
against.  (BTW, I'm looking for more people to interoperate against, send
mail to the address above, or see my .signature for a phone #.)  I suspect
others do the same, given what Marc told me about whom HE interoperated
against.

> If they follow the existing AH and ESP specs and use a standard
> implementation of either MD5 or SHA-1, they would add an additional 64
> bytes onto the end of a padded message.

No extra bytes are _added_ to messages with AH with the current set of
algorithms.  They are added to ESP ONLY so a block cipher doesn't choke on
what it's fed.  If it's DES or 3DES, you generate padding pre-encryption to
round out the packet to the 8-byte block size of DES.  My interoperability
assertions apply here too.

Hope this helps!
--
Daniel L. McDonald  -  Solaris Internet Engineering  ||  MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*>        ||  NOT NECESSARILY SUN'S!
Phone: (650) 786-6815            |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
Follow-Ups: References: