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

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Sun, Sep 11, 2005 at 07:42:18PM -0700, Bernard Aboba wrote:

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

True. I didn't analyze how much security the salt actually adds, because
it depends on the details of MD5, so I started from the worst case where
every response using an RA for which the hash is known can be decrypted. 

As you say, it's indeed an additional barrier the attacker has to take,
so the situation with PAP is even less bleak than I painted it.

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

Of course. If you obtain S, all is lost and the installation's RADIUS
security is FUBAR.

On a related note, would it be a good idea if the practice of using a
different secret in each direction would be more widely adopted? 

If you obtain an S that's used from client to server only, you can't
forge responses or decrypt their attributes, only perform on-line
attacks on passwords and sniff passwords from other authentications. It
also may shield against MD5's issues a bit better than the salt at the
end.

It's very easy to do, and the feature to allow two secrets to be
specified can be added gradually and independently at clients and
servers.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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