[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isms] RE: Follow up on Authorize Only issue
- To: "Nelson, David" <dnelson@enterasys.com>
- Subject: RE: [Isms] RE: Follow up on Authorize Only issue
- From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
- Date: Tue, 25 Jul 2006 14:16:41 -0700
- Authentication-results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; );
- Cc: <isms@ietf.org>, <radiusext@ops.ietf.org>
- Dkim-signature: a=rsa-sha1; q=dns; l=2176; t=1153862202; x=1154726202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=aGQy48QN+hyclNVLIOSxwp5MIueCM0JLTx/G7ct6NzyouWM+Poo74tCyZa7DfLp8lz6ykn7g B2eXrqKRQs46J4UCbykRdS463g3SLONX/IIAtwGkXeO+MhL2vX1OmniT;
Nelson, David <mailto:dnelson@enterasys.com> 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
--
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/>