[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isms] RE: Follow up on Authorize Only issue
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
> ... it seems a bit silly to define a new attribute to indicate that
> other attributes are missing. The absence of User-Password, etc.
> 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. I also think that
omitting the User-Name as the only way to signal Authorize Only is also
problematic. 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?
I believe that the presence of User-Name already has a well defined
semantics. I am concerned that the omission of User-Name may have
muddled semantics, given RFC 3576 implementations. In RFC 3576 the
Service-Type of Authorize Only in an Access-Request provides that
signal. We wish to use a Service-Type of Framed-Management (or some
such) in the ISMS use case, so we need another attribute to signal
> What's actually silly is talking about untrusted NASen at all: if a
> client that has a valid shared secret has been compromised, life is
> much over anyway.
I think we have rough consensus on that point.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.