[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authentication Mechanism Matrix (was L2TP vs IPSEC)



On Wed, 21 Jun 2000, Ben McCann wrote:
> "CHINNA N.R. PELLACURU" wrote:
> > 
> > Consider this model:
> > 
> > You add anohter AV pair to whatever legacy authentication server you are
> > using today, like a IKE-Pre-Shared-Key attribute. Now, we fetch the
> > pre-shared key from the legacy authentication server, and do the IKE
> > pre-shared key authentication in a way that it is not vulnerable to
> > passive off-line dictionary attacks. This will do the authentication of
> > the user in a way that IPSRA wants.
> 
> It is not safe to "fetch" the preshared key from the authentication
> server because now that server becomes an "oracle" that can be asked
> "Give me the pre-shared key for user FOO". The current Radius mechanism
> accepts queries of the form "Is FOO's password equal to BAR" and returns
> TRUE or FALSE. It requires an active dictionary attack to learn FOO's
> password is BAR rather than just _asking_ the server.
> 
You're correct, except that you can protect the radius server in some way, or
you can encrypt the new attribute in some way. If you send it in the clear
over a public net, you deserve to get hacked. There are ways of protecting
it.

What chinna didn't mention is that this scheme relies on aggressive mode,
since otherwise we don't know whose secret to ask for.

This scheme also doesn't help with the 'machine' versus 'human'
authentication. I don't think this should be what IPSRA should be
considering.

> I know you could authenticate the gateway to the Radius server but
> I assert a PASS/FAIL mechanism has to be safer than just 'Tell me
> the secret' no matter how strongly you authenticate the gateway.

If you authenticate both ways, by encrypting the the reply or at least the
relevant attribute, you come close. I'm not sure if they aren't equivalent at
that point, but that's really irrelevant, since this whole scheme doesn't
address IPSRA...

> So,
> I doubt the AAA group or the IAB would support a Radius change that
> requires the radius server to divulge the authentication secret.
> 
That part you're right about, although I've heard rumblings in the AAA group
for distributing keys in some fashion already. I was more than surprised when
I heard this, and asked someone: "So what are you planning on using to
distribute these keys?" I know radius won't do it. The radius group would
have a cow. Maybe diameter. Maybe a new protocol, I was told.

jan
 --
Jan Vilhuber                                            vilhuber@xxxxxxxxx
Cisco Systems, San Jose                                     (408) 527-0847