Subject: RE: [Isms] FW: RADIUS integration

From: "Nelson, David" <[email-masked]>
Date: Wed, 12 Jul 2006 13:33:11 -0400

> Authentication and authorization
> _are_ separate concepts, and people are beginning to recognize that
and
> treat them separately.  Authentication is no longer always about
usernames
> and passwords, and some authentication methods do not lend themselves
to
> authenticating to some entity other than the one you want to talk to.
> Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup,
> authentication may take place via a mechanism that is outside the
RADIUS
> server's control.  Once that happens, the application needs to make a
> decision as to whether to provide access and at what level, and RADIUS
is
> an appropriate tool for that, even though it did not handle
> authentication.
> But it can only be used that way if a RADIUS client can say "this is
the
> user's identity; tell me what I need to know to make an access
decision".

This concept was presented this past Monday in the RADEXT WG meeting at
IETF-66, in the context of the concrete example of using Kerberos
authentication with RADIUS authorization.  Perhaps using the example of
Kerberos was inadvisable.  In any event, a few of those present asserted
that this work should probably not go forward in RADEXT or ISMS because
it would be a major architectural change to Kerberos.  Since Kerberos
already contains authorization elements, that are cryptographically
bound to the authentication (ticket) it was argued that allowing a
mechanism by which RADIUS authorization, lacking s similar cryptographic
binding, to over-ride or modify any Kerberos provided authorization
opened up security concerns, and architectural concerns.

We will discuss this late today in the ISMS WG meeting.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 12 Jul 2006 14:25:52 -0400

On Wednesday, July 12, 2006 01:33:11 PM -0400 "Nelson, David" 
<[email-masked]> wrote:

> In any event, a few of those present asserted
> it would be a major architectural change to Kerberos.

Yeah; I heard about that, but that's not really a very good argument. 
Kerberos provides a means to _carry_ data related to authorization, for 
cases where that is useful, but it does not itself define any authorization 
mechanism.  The philosophy of Kerberos is that authentication and 
authorization are separate concepts, and Kerberos provides only the former. 

> Since Kerberos

This is not an issue; Kerberos is intended to allow applications to 
identify clients by name, and make authorization decisions on that basis. 
There is nothing in the Kerberos architecture which precludes applications 
using any means at their disposal to make authorization decisions one 
authentication is complete.

If anyone is confused or concerned about this issue, I'd be happy to 
discuss it further in person.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA