Re: DIGEST-MD5 SASL mechanism?

[Lawrence Greenfield <leg+@xxxxxxxxxxxxxx>]

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

   No, it is just encrypted with the message, it isn't part of the message. The
   MAC for encrypted messages is the padding concatenated with the MAC for
   unencrypted messages.

This really doesn't make sense.  A "MAC" is a message authentication
code; padding is not part of the message authentication.

Further, you don't cover what happens if the HMAC length is not a
multiple of the cipher blocksize.

draft 03 specifies the encryption as follows:

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 }

>From your message, I've corrected this to:

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

Of course, the 10 byte HMAC prefix is not a multiple of the 8 byte DES
block.

I would propose encoding instead as follows:

SEAL(Ki, Kc, SeqNum, msg) = 
   CIPHER(Kc, { msg, pad, CMAC(Ki, SeqNum, msg) } )

CMAC(Ki, SeqNum, msg) =
   { 0x0001, HMAC(Ki, (SeqNum, msg))[0..9], SeqNum }

where pad is 1 or more bytes containing the amount of padding needed
to make msg + CMAC be a multiple of the block size.

Is there a reason that the sequence number and version field were left
unencrypted?  In order to minimize the amount of easy cribs?

Larry