Bernard, Wolfgang,
RFC 2868 also defines a SALT for encrypting an attribute, and I believe (and hope) it is not broken, as apparently in this RFC the SALT is at the beginning.
Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Dienstag, 14. Dezember 2004 05:19
An: radiusext@ops.ietf.org
Betreff: Re: Issue 6: Encryption
Wolfgang Beck said:
"Issue 6
To be honest, I did not find an RFC that describes how to encrypt individual RADIUS attributes other than User-Password and Tunnel-Password."
RFC 2548 also defines encryption of the MPPE-Key attributes. However, the use of the SALT field in that draft is broken -- the SALT if used, needs to go at the beginning, not the end!
Putting it at the end is silly because a known plaintext attack compromises the keystream, and then the attacker can continue the key stream guessing various SALT values. So the SALT has no security value at all in making the stream cipher harder to crack.
Given the attacks on MD5-based stream ciphers (see RFC 3579 for details), I'm not sure we'll be able to get any document using them past security review.
If we really do need to encrypt an attribute, probably the way to go is to use an AES-based wrap.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>