Subject: DIGEST-MD5 SASL mechanism?

From: Lawrence Greenfield <[email-masked]>
Date: 4 Jul 1999 22:00:04 -0400

Hi,

I'm attempting to clean up our implementation of DIGEST-MD5, and have
some questions that I'm unable to answer from
draft-leach-digest-sasl-03.txt.  I was wondering if anyone else has
attempted to implement this or has thought about it.

Specifically, I'm wondering about how to correctly implementing
privacy protection with block ciphers such as DES or 3DES and other
issues related to privacy and integrity protection.

The text I'm having trouble with is quoted below.

There appear to be several ambiguities in this:

- a "2-byte message type number" conflicts with "0x00000001"

- the MAC is defined including the "variable length padding prefix",
  but the padding is treated as part of the message.

- the padding  appears to be ambigious.  it is impossible to
  determine upon receipt of the message whether padding was or was not
  inserted versus a message that happened to end with something that
  looked like padding.

- it is unclear whether the encipherment of the {msg,pad} should be
  done before or after the encipherment of the HMAC.

Thanks,
Larry

----
[from section 2.4]

   The MAC is a variable length padding prefix followed by 16 bytes
   formatted as follows: a 2-byte message type number in network byte order
   with value 1, the first 10 bytes of the HMAC-MD5 [RFC 2104] of the
   message and the 4-byte sequence number in network byte order. If the
   blocksize of the chosen cipher is not 1 byte, the padding prefix is one
   or more octets each containing the number of padding bytes such that
   length of the message plus the length of the padding prefix is a
   multiple of the blocksize.

   SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
         SeqNum, msg)
   CMAC(Ki, Kc, SeqNum, msg) =
       { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum }