Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Jul 2006 13:10:57 -0700

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> Jeffrey Hutzelman writes...
> 
>> Overloading Service-Type in this way was almost certainly a mistake;
>> ...
> 
> Perhaps.
> 
>> ...as you note, it prevents the attribute for being used for its
>> intended purpose, ...
> 
> In this case, providing a service hint.
> 
>> I think this is up to radext to fix; possibilities I can think of are
>> defining an "authorize-only" authentication mechanism, or defininig
>> a new attribute which carries the value that Service-Type would have
>> had. 
> 
> One suggestion that comes to mind is to create a new attribute called
> Asserted-Identity, which could be empty.  In RADIUS, the
> authentication method is implicitly selected by the inclusion of the
> corresponding credential-bearing attribute(s), such as User-Password,
> CHAP-Password, EAP-Message, etc.  Asserted-Identity could be the
> attribute which selects the Authorize Only authentication method.  

Aside from the fact that "Authorize Only" is hardly an authentication method, it seems a bit silly to define a new attribute to indicate that other attributes are missing.  The absence of User-Password, etc. would seem to be enough to implicitly select authorize-only...
   
> 
>> I must note, BTW, that if you are trying to restrict what
>> information the RADIUS server gives out because you don't trust the
>> NAS, then giving out informaton based on what service the NAS claims
>> it is providing, or what port type the NAS claims the user came in
>> on, is kind of silly.

What's actually silly is talking about untrusted NASen at all: if a RADIUS client that has a valid shared secret has been compromised, life is pretty much over anyway.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 16:38:00 -0400

On Tuesday, July 25, 2006 01:10:57 PM -0700 "Glen Zorn (gwz)" 
<[email-masked]> wrote:

> Aside from the fact that "Authorize Only" is hardly an authentication
> method

It's not an authentication method, but it fills that role in the protocol. 
Ordinarily, the RADIUS server must have some means of verifying the user's 
identity, because the NAS is counting on it to do that.  The authentication 
method is simply the answer to the question "what is that means?".  What 
we're doing is defining a new possible answer, which is "there is none; the 
NAS is not counting on you to verify the user's identity, so you don't have 
to do it".

Now, you've suggested that the way to represent that answer is simply by 
not including the attributes required for some other method.  The problem 
with that is that such a request is indistinguishable to the RADIUS server 
from a request using an authentication method it does not understand.  A 
RADIUS server which supports authorize-only will probably want to return 
success for the request using that feature, but still must return failure 
for requests using methods it doesn't understand.  To make the distinction, 
you need an affirmative indication from the client that it wants 
authorize-only; that is, that it is not depending on the RADIUS server to 
verify the user's identity.

> What's actually silly is talking about untrusted NASen at all: if a
> RADIUS client that has a valid shared secret has been compromised, life
> is pretty much over anyway.

Not necessarily.  With the kinds of authentication mechanisms which make 
authorize-only RADIUS attractive, a NAS never gains the ability to 
impersonate a user.  So, the service that NAS is providing probably has big 
problems, but the users' passwords haven't been compromised, and neither 
have other RADIUS clients.  The compromised device can be turned off, and 
the problem is gone.

-- Jeff

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 25 Jul 2006 13:50:10 -0700

>What's actually silly is talking about untrusted NASen at all: if a RADIUS 
>client that has a valid >shared secret has been compromised, life is pretty 
>much over anyway.

There is still the 'cascading vulnerabilty' problem.

That is, compromise of a single NAS should not imply compromise of other 
services, NASes or users.