Subject: [secdir] Review of draft-ietf-isms-radius-usage-05

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 May 2009 10:13:06 -0700

$Id: draft-ietf-isms-radius-usage-05-rev.txt,v 1.1 2009/05/05 16:12:55 ekr Exp $

This document is about the use of RADIUS servers with SNMP "transport
models" (security protocols such as SSH used with SNMP). As far as I
can tell, the idea is to explain how to outsource some of the
authorization decisions to RADIUS.

I found this document extremely difficult to read. I realize that
the intended audience is for people with a lot of RADIUS and
SNMP experience, but despite some familiarity with them, I had
to work fairly hard to figure out what it was trying to say
and I'm still not sure. This document would benefit very greatly
from a diagram explaining how the authors think things are supposed
to work.

My big question is how the user authentication decisions are
expected to be split between (e.g., SSH), and RADIUS. For
example:

- If the user has a password, who checks it the RADIUS server
  or the NAS? RADIUS certainly can do this.
- If the user is authenticating with SSH pubkey auth, who
  checks that? 

These seem like important architectural issues but I'm not getting
them out of the document, and they should in particular
be in the security considerations.

IMO, this document would benefit from a rewrite that makes it a
lot clearer to someone not enmeshed in the WG.

S 2.
I don't understand what the difference is between service authorization
and access control in this context.

S 2.3.
I don't get the SHOULDs here. If you're defining how code points are
set, why are these optional?

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 5 May 2009 23:44:50 -0400

Eric Rescorla writes...

> Subject: Review of draft-ietf-isms-radius-usage-05

Thanks for your review and comments.

> lot clearer to someone not enmeshed in the WG.

Umm.  OK.  That's a bit disheartening to hear, but useful feedback.

> As far as I can tell, the idea is to explain how to outsource 
> some of the authorization decisions to RADIUS.

Correct.

> SNMP experience...

That's true.  Those are the intended audiences.  Additional explanatory
material was added to give each group some background information.

> ...but despite some familiarity with them, I had
> from a diagram explaining how the authors think things are 
> supposed to work.

Diagrams can be useful.  We can certainly think about what might be helpful
in that regard.

>   or the NAS? RADIUS certainly can do this.

The RADIUS server makes the authentication decision.  If the credential is a
password, as is the typical use case, the password is sent (hidden) in a
RADIUS Access-Request message.

> - If the user is authenticating with SSH pubkey auth, who

The SSH server, i.e. the NAS.  SSH is used to create a protected transport
session (a tunnel, if you will) and the RADIUS credentials are obtained from
the SSH server implementation in the NAS and used by the RADIUS client in
the NAS to authenticate the user with the RADIUS server.  Of course, it has
to be an authentication method that RADIUS supports, and SSH public key is
not one of those.

> be in the security considerations.

I'll re-read the document with your questions in mind.  Of course, as a
draft author and a RADIUS expert, I may have overlooked some unstated
assumptions.

> and access control in this context.

Service Authorization means that the user is authorized to (a) manage the
NAS and (b) use SNMP in particular as the management mechanism.  Access
Control Authorization relates to the SNMP Access Control Subsystem and could
be thought of as analogous to access control lists or packet filters or any
similar fine-granularity access control mechanism.
 
> set, why are these optional?

OK, let's look at each one of these:

   RADIUS servers compliant to this specification SHOULD use RADIUS
   service provisioning attributes, as described herein, to specify
   SNMP access over a secure transport.

This one could arguably be a MUST.  In fact, I tend to think it ought to be
a MUST.

   The following RADIUS attributes SHOULD be used, as hint attributes
   included in the Access-Request message to signal use of SNMP over
   a secure transport (i.e. authPriv) to the RADIUS server:

RADIUS documents have traditionally held that appropriate "hint" attributes
are desirable in an Access-Request message, but that they are optional.
This preserves that tradition.  I suppose this could be changed to MUST
without impacting interoperability with RADIUS servers, which are always
free to ignore such hints.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 May 2009 06:22:44 -0700

At Tue, 5 May 2009 23:44:50 -0400,
> to be an authentication method that RADIUS supports, and SSH public key is

so, this is what concerns me: architecturally these are pretty
different--and challenge-response may be different yet. That
seems like it deserves some analysis.

-Ekr

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 May 2009 15:38:37 +0200

> lot clearer to someone not enmeshed in the WG.

This document has been revised several times to make it say the right
things in the terminology used and understood by RADIUS folks and SNMP
folks and while the result might not be optimal for a more general
audience, I believe the target communities had reached concensus that
the document does in fact say the right things in a way appropriate
for the two main target audiences.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 6 May 2009 10:06:54 -0400

Eric Rescorla writes...

> seems like it deserves some analysis.

Perhaps some additional analysis and explanation of the "don't gets" would
be useful.  The draft clearly focuses on the "gets" and on describing a
particular use case involving SSH and password-based authentication.  There
are other SSH authentication methods that cannot be integrated with RADIUS.
Since they cannot be used, we don't spend any time discussing them.

In an operator has an existing deployment using SSH and public key
authentication, they may be able to use the transport-based security
features of SNMPv3 defined in the companion ISMS WG drafts, but they won't
be able to use RADIUS as part of that solution.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 May 2009 12:06:50 -0400

>>>>> "Dave" == Dave Nelson <[email-masked]> writes:

    Dave> The SSH server, i.e. the NAS.  SSH is used to create a
    Dave> protected transport session (a tunnel, if you will) and the
    Dave> RADIUS credentials are obtained from the SSH server
    Dave> implementation in the NAS and used by the RADIUS client in
    Dave> the NAS to authenticate the user with the RADIUS server.  Of
    Dave> course, it has to be an authentication method that RADIUS
    Dave> supports, and SSH public key is not one of those.

I'm sorry, but I didn't understand this answer at all.  It seems like
you're both saying "you can't do that with RADIUS (what I thought the
answer was)," and "the ssh server."  I don't understand how to
reconcile those.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 6 May 2009 23:21:42 -0400

Sam Hartman writes...

> I'm sorry, but I didn't understand this answer at all.

Yeah, I'm afraid I've muddled up what this document is about with what
*might* happen outside the scope of the document, in an attempt to answer
Eric's questions.

> It seems like you're both saying "you can't do that with RADIUS 
> (what I thought the answer was)," and "the ssh server."  I don't 
> understand how to reconcile those.

Let me try again.  What's being standardized is the use of RADIUS to
outsource user authentication and service authorization for SNMP access.
This works with SNMP Transport Models, e.g. with SSHTM.  Only those
authentication methods that are natively supported in RADIUS, e.g. password,
are in scope for this document.

In the case of SSH, there are other authentication methods, such as public
key.  Such methods cannot be use with RADIUS as described in this document.
Full stop.

I added some confusion when I attempted to indicate that SSH and SSHTM
*might* be used with SSH public key authentication, but *not* with RADIUS.
In that case the use authentication resides with the local SSH server
implementation in the NAS.  Presumably the public key(s) of the user(s)
has/have been installed in the SSH server's local configuration data store.
This has nothing to do with RADIUS.  It has no central AAA component, and
credentials are provisioned on a device-by-device basis.  This is what many
deployments of SSH with public key have today.  It can be used with SNMP,
after a fashion.  However, it has nothing to do with the document under
review.  Sorry to have introduced that confusion.