Subject: security report for sasl digest-md5

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Mar 2003 15:25:53 -0500

During the SASL working group meeting at IETF 56,
Eric Rescorla and I agreed to review the security of cipher usage in
the digest-md5 SASL mechanism draft (draft-ietf-sasl-rfc2831bis).  We
have reached the following conclusions:

1) Instructions on how to use rc4 are unclear; an implementation might read
the draft and assume that  the PRNG should be initialized for every
message sent.  This would  allow an attacker to retrieve the xor of
multiple plaintext messages given the ciphertext and in most
situations would completely compromise confidentiality.

2)  The use of CBC is unclear.  The draft does not specify whether the
IV is reinitialized  from one message to the next or whether  the  the
last block of  ciphertext becomes the IV of the next message.  From a
security standpoint the IV should not be reinitialized and instead
should be chained between messages.

3) The handling of parity bits is significantly different from other
   protocols that specify how to set up keys and may lead to
   confusion.

4) Part of the key material is used as the IV for the 3DES cipher.

5) As previously discussed on the SASL list, the protocol is
vulnerable to CBC chaining issue (the Rogaway attack).

6) Implementation guidance on avoiding timing attacks related to
verifying padding before performing the MAC operations needs to be
given.  See http://lasecwww.epfl.ch/memo_ssl.shtml.

Since existing implementations of the RC4 cipher do preserve PRNG
state between messages, there is no technical objection to retaining
the existing RC4 cipher or even to making it mandatory to implement.
An appropriate document for a normative reference will need to be
found and the text will need to be clarified if the working group
wishes to proceed in this direction.

We recommend that the working group deprecate the existing DES and
3DES ciphers.  An AES cipher should be specified.  The AES cipher can
either use counter mode or avoid the CBC chaining attack in some other
way such as the addition of random text to each message.  The AES
cipher should not use key material as part of the IV.