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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Jeffrey Hutzelman <mailto:jhutz@cmu.edu> supposedly scribbled:

> On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)"
> <gwz@cisco.com> 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".   

OK, one more time: that seems to be what a Service-Type of Authorize-Only would do....

> 
> -- Jeff

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

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