Re: A bit of background on [RFC3580] Section 5.3

[Bernard Aboba <aboba@internaut.com>]

> If you take a look the password hiding algorithm, assuming <= 16 octet
> passwords to leave out the chaining for simplicity, where ^ denotes XOR,
> and . denotes concatenation:
> 
> 	User-Password' = User-Password ^ md5 (Secret . Req-Authenticator)
> 
> you can see that if you know one User-Password and User-Password', you
> know the MD5 hash of (Secret . Req-Authenticator).
> 
> This same hash is also used in the response packet to 'encrypt' response
> attributes. That means the attacker who captures a request and response,
> is able to decrypt the request- and response attributes for that session
> and all future sessions using the same Secret and Authenticator. This
> includes the sessions themselves if they are somehow protected by the
> contents of response attributes, as is the case with MPPE-*-Key.

Attributes hidden in the Access-Accept (such as Tunnel-Password & 
MPPE-*-Key) use a salt. 

For example, from RFC 2868, Section 3.5:

            b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)

Where S = secret, R = Request Auth, A = Salt. 

Since MD5 utilizes padding, knowing MD5(S + R) (e.g. discovering 
the keystream via known plaintext attack on PAP) doesn't provide much help 
in computing MD5(S + R + A). 

Of course if you can obtain S (such as via an offline dictionary attack), 
that is a different story. 


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