[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isms] RE: Follow up on Authorize Only issue
- To: "Nelson, David" <firstname.lastname@example.org>
- Subject: RE: [Isms] RE: Follow up on Authorize Only issue
- From: "Glen Zorn \(gwz\)" <email@example.com>
- Date: Tue, 25 Jul 2006 14:16:41 -0700
- Authentication-results: sj-dkim-2.cisco.com; header.Fromfirstname.lastname@example.org; dkim=pass ( sig from cisco.com verified; );
- Cc: <email@example.com>, <firstname.lastname@example.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; email@example.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<firstname.lastname@example.org> |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:email@example.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,
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.