[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DIGEST-MD5 SASL mechanism?
> -----Original Message-----
> From: Lawrence Greenfield [mailto:leg+@xxxxxxxxxxxxxx]
> Sent: Sunday, July 04, 1999 7:00 PM
> To: ietf-sasl@xxxxxxx
> 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 }
>