Re: DIGEST-MD5 SASL mechanism?

[Lawrence Greenfield <leg+@xxxxxxxxxxxxxx>]

   [...]
   However, I take your point. I'll admit I was loose with the terminology --
   it would have been more accurate to be something like the "MAC trailer"
   which is the pad, version, MAC, and sequence number.

I guess I sometimes have enough problems understanding these
specifications without the little confusions.

   [...] current:
   > 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.

   [... my suggestion deleted ....]
   The simplest change is just to make the size of the pad big enough to (msg +
   10) (10 being the size of HMAC output) be a multiple of the block size.

   The reason for preferring the simplest change is that the DIGEST-SASL
   mechanism is holding up the LDAP RFCs.

While this could work with silly enough coding, I don't think that
this is really what we want.  Let's see what would come over the wire:

ciphertext 0x0001 ciphertext SeqNum
{msg,pad}         {pad,HMAC}

This means, in order to decrypt using a block cipher, I'll have to
extract the ciphertext corresponding to {msg,pad}, extract the
ciphertext corresponding to {pad,HMAC}, concatenate the two, perform
the decryption, take the last 10 bytes for the HMAC, and the remaining
non-pad bytes corresponding to the msg.  This seems overly complex.

If we could go:
{ msg, HMAC, pad, version, SeqNum }
  ----encrypt----
   
that would work.  Then it's also clear that I don't use the padding to
generate the checksum.

Another possible solution makes me ask this ignorant
question---perhaps it is obvious: why is the HMAC encrypted?

Larry