[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>, <isms@ietf.org>, <radiusext@ops.ietf.org>
- Subject: RE: [Isms] RE: Follow up on Authorize Only issue
- From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
- Date: Tue, 25 Jul 2006 13:10:57 -0700
- Authentication-results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; 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; 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=p1tNetYLfGSERllqFxrWtRYOeE4+UDQy2Gz+uHxcBEMhGsn4JqPVDM3SCDsXIZLs1b5Cxv1i 4DAl+Fa/P1peGzILzF3SW3f+p5Th5yDRkP5vACOwksuJEmidjSW+NeN/;
Nelson, David <mailto:dnelson@enterasys.com> supposedly scribbled:
> Jeffrey Hutzelman writes...
>
>> Overloading Service-Type in this way was almost certainly a mistake;
>> ...
>
> Perhaps.
>
>> ...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
>> had.
>
> 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,
~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/>