[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>, <email@example.com>, <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 13:10:57 -0700
- Authentication-results: sj-dkim-2.cisco.com; header.Fromfirstname.lastname@example.org; dkim=pass ( sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1951; t=1153858258; x=1154722258; 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=p1tNetYLfGSERllqFxrWtRYOeE4+UDQy2Gz+uHxcBEMhGsn4JqPVDM3SCDsXIZLs1b5Cxv1i 4DAl+Fa/P1peGzILzF3SW3f+p5Th5yDRkP5vACOwksuJEmidjSW+NeN/;
Nelson, David <mailto:email@example.com> supposedly scribbled:
> Jeffrey Hutzelman writes...
>> Overloading Service-Type in this way was almost certainly a mistake;
>> ...as you note, it prevents the attribute for being used for its
>> intended purpose, ...
> In this case, providing a service hint.
>> I think this is up to radext to fix; possibilities I can think of are
>> defining an "authorize-only" authentication mechanism, or defininig
>> a new attribute which carries the value that Service-Type would have
> One suggestion that comes to mind is to create a new attribute called
> Asserted-Identity, which could be empty. In RADIUS, the
> authentication method is implicitly selected by the inclusion of the
> corresponding credential-bearing attribute(s), such as User-Password,
> CHAP-Password, EAP-Message, etc. Asserted-Identity could be the
> attribute which selects the Authorize Only authentication method.
Aside from the fact that "Authorize Only" is hardly an authentication method, 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...
>> I must note, BTW, that if you are trying to restrict what
>> information the RADIUS server gives out because you don't trust the
>> NAS, then giving out informaton based on what service the NAS claims
>> it is providing, or what port type the NAS claims the user came in
>> on, is kind of silly.
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.
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.