Subject: RE: DIGEST-MD5 SASL mechanism?

From: Paul Leach <[email-masked]>
Date: Tue, 6 Jul 1999 10:06:08 -0700

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Sunday, July 04, 1999 7:00 PM
> To: [email-masked]
> Subject: DIGEST-MD5 SASL mechanism?
> 
> 
> 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"

Sorry -- didn't update the example when changing the spec. Should be
"0x0001"

> 
> - 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.

> 
> - 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.

There is always at least 1 pad byte: "the padding prefix is one or more
octets each containing the number of padding bytes". I tried to not have any
extra padding if the message happened to be a multiple of the cipher
blocksize, but couldn't figure out a way.
 
> 
> - it is unclear whether the encipherment of the {msg,pad} should be
>   done before or after the encipherment of the HMAC.

Before.  The definition in section 2.4 is
    SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
SeqNum, msg)

So, the CIPHER happens before the CMAC.

> 
> 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 }
>

---

From: Lawrence Greenfield <[email-masked]>
Date: 7 Jul 1999 16:19:39 -0400

[...]

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

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 20 Jul 1999 09:15:06 -0400 (Eastern Daylight Time)

FYI,

A new draft version of the above I-D is now available at, e.g. ietf.org.
Comments and feedback is welcome and solicited.

Thanks,
-- Magnus

Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000

---

From: Lawrence Greenfield <[email-masked]>
Date: 7 Jul 1999 16:19:39 -0400

[...]

CMAC(Ki, SeqNum, msg) =

Larry

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 20 Jul 1999 09:15:06 -0400 (Eastern Daylight Time)

FYI,

Thanks,
-- Magnus