Re: Authentication Mechanism Matrix (was L2TP vs IPSEC)

["CHINNA N.R. PELLACURU" <pcn@xxxxxxxxx>]

On Wed, 21 Jun 2000, Jan Vilhuber wrote:

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

I mentioned it a long time ago. I thought that it was too obvious to be
repeated again and again.

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

Why do you think so? Can you please elaborate, also providing your
definition of 'machine' Vs 'user' authentication.


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

Why doesn't it address IPSRA. I think  it would be better if people
provided an argument when they make generalized statements.


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

It is not a requirement to store the keys in a AAA database. It is just
one possibility.

    chinna


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

chinna narasimha reddy pellacuru
s/w engineer