[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
- To: "Avi Lior" <avi@bridgewatersystems.com>, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
- Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
- From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
- Date: Wed, 26 Jul 2006 11:18:21 -0700
- Authentication-results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; );
- Cc: "David Harrington" <ietfdbh@comcast.net>, "Eliot Lear" <lear@cisco.com>, <isms@ietf.org>, <radiusext@ops.ietf.org>
- Dkim-signature: a=rsa-sha1; q=dns; l=4384; t=1153937903; x=1154801903; c=relaxed/simple; s=sjdkim6002; 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=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DEvtPMlNbcxEdOSYlFBdUnxJo5Vs=3D; b=fmckMKsI0sMKqbFW9gKAfV1cGR7VsRGVCUp54HBWsV9WBW1P6hkela/uprE3936ManPGEh6M YVMbpMVVOMpBPRRhhjsBwBf02kH9jlysdX0SML9fGk0nQis8l8swxX9/;
Avi Lior <mailto:avi@bridgewatersystems.com> supposedly scribbled:
> Hi Hannes,
>
> When I wrote the word "assertion" I was thinking a SAML assertion.
In order for this to have any meaning at all, the source of this assertion would need to be trusted by both the RADIUS client and server. This seems to imply a bunch of new keys, at a minimum, unless you don't care to authenticate the token/assertion/whatever (in which case why bother?). In addition, the token/assertion/whatever would need to be somehow delivered from something, somewhere in a secure fashion to the RADIUS client for forwarding to the RADIUS server. Aside from those minor nits (modifying both the RADIUS entities to receive, transmit & understand the token/assertion/whatever & more than likely the SSH/Kerberos/whatever entities to actually generate & deliver the token/assertion/whatever), I think this is a great idea.
>
> A word of caution though, everytime I mention XML to my AAA
> developers they conspire to kill me.
Good people & wise!
>
> XML, parsing strings etc are performance killers for a AAA server.
>
>
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Wednesday, July 26, 2006 4:55 AM
>> To: Avi Lior
>> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; isms@ietf.org;
>> radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only
>> issue (was RE: [Isms] ISMS session
>>
>> Hi Avi,
>>
>> I like the idea of using some information to tie the authentication
>> and the authorization process/exchange together. In fact we discussed
>> this at the last IETF meeting when David gave his presentation.
>>
>> I suggested to use an existing mechanism to accomplish this binding,
>> namely SAML. I can elaborate a bit more about the details if someone
>> case about it.
>>
>> Ciao
>> Hannes
>>
>> Avi Lior wrote:
>>> I proably did not make myself clear....or maybe I did and I am
>>> missing something.
>>>
>>> When the NAS sends the Access-Request Auth-Only message I agree that
>>> it MUST contain Message-Authenticator(80) etc...
>>>
>>> What I meant is that it would be nice if there was a token or an
>>> assertion that came from the place that did authenticate the user
>>> to indicate in a cryptographic way that this user was authenticated.
>>>
>>> The AAA server can use that token to verify that the user was
>>> authenticated by an entity that it trusts. Like a kerberose ticket.
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
>>>> Sent: Tuesday, July 25, 2006 3:47 PM
>>>> To: Avi Lior; David Harrington; Eliot Lear
>>>> Cc: isms@ietf.org; radiusext@ops.ietf.org
>>>> Subject: RE: Follow up on Authorize Only issue (was RE: [Isms]
>>>> ISMS session
>>>>
>>>> Avi Lior <mailto:avi@bridgewatersystems.com> supposedly scribbled:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> If I was specifying how this is done:
>>>>>
>>>>> It would be nice if the AAA client could return some sort
>>>>
>>>> of token to
>>>>
>>>>> the AAA server to assert that the user has been authenticated by
>>>>> an entity that it trusts. The token can be generated by the
>>>>> Authentication Server.
>>>>>
>>>>> We need this assertion to make sure we deliver the correct
>>>>> profile.
>>>>
>>>> I disagree: the fact that the message is being sent by an
>>>> authenticated client at all says that the user has been
>>>> authenticated elsewhere. Note that safety requires the inclusion
>>>> of a MAC (either the Message-Authenticator or preferably the
>>>> Message-Authentication-Code Attribute) in the Access-Request.
>>>>
>>>> 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/>
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/>