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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Jul 2006 14:16:41 -0700

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

> Glen Zorn writes...
> 
>> Aside from the fact that "Authorize Only" is hardly an authentication
>> method,  ...
> 
> It's been described as the "null" authentication method, purely from
> a conceptual viewpoint. 
> 
>> ... 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...
> 
> Well, the new attribute need not be empty.  I could contain an
> identity string, for auditing purposes. 
> 
> I think that the use of User-Name to contain the auditing information
> (as you posited in a separate post) is problematic.  

Not sure I really understand this.

> I also think
> that omitting the User-Name as the only way to signal Authorize Only
> is also problematic.  

If User-Name is omitted, how do you know who is being authorized?

> The problems I see are with existing RADIUS
> server implementations.  Since the _presence_ of a particular kind of
> credential-bearing attribute has always selected the authentication
> method, I'm concerned about the backwards compatibility aspects of
> simply omitting any such.  Perhaps others have thoughts on this? 

Don't quite understand this either: if a server doesn't recognize the postulated Asserted-Identity Attribute, it seems that as far as it is concerned there will be no credential-bearing attribute in the message.  So just omitting any credential-bearing attribute (along with the addition of the other stuff we've been talking about) should get just the same response from a legacy server, right?
  
...

> 
>> 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.
> 
> I think we have rough consensus on that point.

That's gratifying to hear!

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 18:21:49 -0400

On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)" 
<[email-masked]> wrote:

> Don't quite understand this either: if a server doesn't recognize the
> postulated Asserted-Identity Attribute, it seems that as far as it is
> concerned there will be no credential-bearing attribute in the message.
> So just omitting any credential-bearing attribute (along with the
> addition of the other stuff we've been talking about) should get just the
> same response from a legacy server, right?

>From a _legacy_ server, yes.  The concern is about how this would affect 
handling of some new authentication method invented in the future.  Suppose 
there is a new method that requires a "Frobozz" attribute, and we have a 
client that sends a request using that method.  A server which supports 
"Frobozz" will respond correctly, as will a server that does not support 
either "Frobozz" or authorize-only.

However, a server that supports authorize-only but does _not_ support 
"Frobozz" will believe the client intended authorize-only, and will return 
a successful response on that basis, without verifying the user's identity. 
That's the situation which we need an "Asserted-Identity" attribute to 
avoid.  The _contents_ of such an attribute are irrelevant; the important 
thing is an affirmative indication that the client meant authorize-only and 
not some unknown "Frobozz".

-- Jeff