Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Jul 2006 14:12:23 -0400

Bernard Aboba writes...

> Does the Service-Type of "Framed-Management" imply 
> authorization-only?

No.  It could equally be used when RADIUS is providing both
authentication and authorization.

> Or is it possible for authentication to be requested 
> as well?

Yes.

> For example, what attributes are used in existing SSH 
> implementations acting as a RADIUS client?

I rather suspect that existing implementations either ignore the
Service-Type (i.e. authenticate only) or expect something like
NAS-Prompt.

There is an issue to be worked out, and that it how does the NAS signal
to the RADIUS Server that it is seeking Authorize Only service
specifically for SSHSM?

The existing Authorize only usage in RFC 3576 suggests that:

   The NAS then sends an Access-Request
   to the RADIUS server with a Service-Type Attribute with value
   "Authorize Only".  This Access-Request SHOULD contain the NAS
   attributes from the Disconnect or CoA-Request, as well as the session
   attributes from the Request legal for inclusion in an Access-Request
   as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As
   noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
   SHOULD be included in an Access-Request that does not contain a
   User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

So it seems clear that the Access-Request message, in the SSHSM
Authorize Only usage, should contain;

Service-Type = Authorize Only
Message-Authenticator

Plus various forms of ID attributes, such as NAS-IP-Address,
NAS-Identifier, etc.

But what else?

It would be typical to include:

Service-Type = Framed-Management
Framed-Management-Protocol = SNMPv3

as hints, however, the value of Service-Type conflicts.

Perhaps simply including: 

Framed-Management-Protocol = SNMPv3

is a sufficient hint to the RADIUS Server, along with Service-Type =
Authorize Only, to indicate the SSHSM Authorize Only use case.

I would fully expect that the Access-Accept message would contain:

Service-Type = Framed-Management
Framed-Management-Protocol = SNMPv3
Message-Authenticator

Plus what ever else might be desired.

There was also a suggestion on the list that the NAS convey the asserted
identity to the RADIUS Server for audit purposes.  This could be
accomplished by a (new) Asserted-Identity attribute.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 14:28:50 -0400

>    User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

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, 
which is to indicate something orthogonal to whether you want 
authentication or authorize-only.

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.

I must not, 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.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Jul 2006 14:33:23 -0400

Hi David,

Per the discussion at the ISMS interim meeting, there is an
architectural issue here. 

The authorize-only functionality is meant to be used by the SNMP
(data) Access Control subsystem, not by the message security subsystem
or the transport mapping. SSHSM is a combination of transport mapping
and message security model, but it is not a model in the SNMP (data)
access control subsystem. 

You use SSHSM when you want SSH to provide the user authentication.

Ergo, I believe SSHSM should never use the "authorize-only" feature.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 2:12 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Isms] RE: Follow up on Authorize Only issue
> 
> Bernard Aboba writes...
>

---

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

> Ergo, I believe SSHSM should never use the "authorize-only" feature.

I'm not entirely sure that's true.

First, it's reasonable for SSH itself to use this feature.  Some ssh 
userauth mechanisms need to be able to determine from the client's 
authenticated identity whether it is allowed to use a particular SSH 
username, and this would be an appropriate use of RADIUS.  Of course, it's 
also reasonable for the SSH server to use RADIUS to decide whether a 
particular SSH username is allowed to use a particular service or command, 
including SNMP.

For the record, these uses of RADIUS by SSH are not things I think we need 
to or should specify in ISMS, but they are appropriate uses of 
authorize-only.

Second, you might want to use RADIUS to determine how to map an SSH 
username to an SNMP username.  It's not clear to me that we nailed down how 
this is supposed to happen, but it clearly needs to happen in the transport 
model, since no higher layers are SSH-specific.  If the mapping is other 
than the identity or some simple transformation, it might be desirable to 
use RADIUS for this.  If so, this is definitely a use for authorize-only, 
since the TM is not directly involved in authentication.

Of course, the real motivator here is as you described -- to allow the 
access-control subsystem to get information it needs to make fine-grained 
access control decisions.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA