Subject: Re: [Isms] Transport directorate review of draft-ietf-isms-radius-usage-06

From: "Dave Nelson" <[email-masked]>
Date: Wed, 6 May 2009 09:55:31 -0400

Hannes Tschofenig writes...

> Subject: Transport directorate review of draft-ietf-isms-radius-usage-06
> 
> I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents.

Thanks for your review and your comments.

> Since I am familiar with the work on RADIUS I had already a clue about
> the direction the document when I read the title. Still, a diagram would
> help with the basic idea. In some sense your document is based on a
> fairly obvious idea, namely to use the RADIUS backend infrastructure to
> relay authentication and authorization for SSH. So, a figure like this
> one could help:
> 
>                                       +--------+
>                                       |RADIUS  |
>                                       |Server  |
>                                       +--------+
>                                           ^
>                                  RADIUS + |  Back-End
>           Management-Transport-Protection |  Protocol
>                Framed-Management-Protocol |  Support
>                                           |
>                                           v
>   +---------+                      +---------------+
>   | Admin's |  SNMP                |RADIUS Client /|
>   | Device  |<-------------------->|Network Device |
>   +---------+  SSH                 +---------------+

Another reviewer indicated that a diagram would have been helpful to him, so
we should probably consider adding one.

> Regarding the following statement:
> 
>    The RADIUS protocol [RFC2865] provides authentication and
>    authorization services for network access devices, usually referred
>    to as a Network Access Server (NAS).
> 
> This is not the only usage of RADIUS. See, for example,
> http://www.ietf.org/rfc/rfc5090.txt
> 
> The interesting thing is that you are defining a RADIUS usage that is
> conceptually extremely close to RFC 5090.

My reading of RFC 5090 was that is adds another authentication method to
RADIUS.  I guess I'm missing the part where it changes the basic RADIUS
model.  :-)
 
> Section 1.2 provides an overview of RADIUS. However, I don't think it is
> appropriate to use RFC 2119 language in that section.

Hmmm.  I fear getting the reverse comment if we de-capitalize the keywords.

> You write:
> 
>    RADIUS almost always involves user authentication as
>    prerequisite to authorization, and there is a user authentication
>    phase for each of these two use cases.
> 
> Since you mention authorize only later you could refer to this aspect as
> well.
> The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt allows
> you  todo authorization without running the authentication exchange even
> though you bind the authorization step to a previously done
> authentication exchange.

We may end up using a two-step process involving "Authorize Only" when we
take up the VACM-related work.  There is no reason to mention such a
mechanism in the scope of this document, however. 

>   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:
> 
> Why don't you use a MUST here?

The reason is that "hint" attributes are traditionally optional.

> In the previous section you describe how
> important it is for the AAA server to figure this information out and
> here you  have a SHOULD and do not explain what happens otherwise if
> this information is not sent.

Another reviewer mentioned this same point.  We could consider making this a
MUST, without unduly impacting interoperability with existing RADIUS servers
as servers are always free to ignore such hints.
 
>    The following RADIUS attributes are used in an Access-Accept message
>    to provision SNMP over a secure transport which provides both
>    integrity and confidentiality (i.e. authPriv):
> 
> I suspect that this should read as
> "
>    The following RADIUS attributes MUST be used in an Access-Accept
>    message to provision SNMP over a secure transport which provides
>    both integrity and confidentiality (i.e. SNMP authPriv):
> "

I'm not sure that a keyword is required here, but if one were to be required
is would be MUST.

> In Table 2 I was only expecting to see the newly introduced RADIUS
> attributes  rather than the attributes that come via the base RADIUS
> RFC. I wouldn't do that.

I'm following the precedent of RFC 3580 which defines RADIUS usage for Layer
2 access control (IEEE 801.1X).

> You excluded accounting from the document and I was wondering whether
> logging isn't a useful feature (or event required) to ensure
> accountability when it comes to the management of network equipment.

Well, there was no discussion in the ISMS WG that accounting was an operator
requirement.  I agree there is a case to be made for it, but in some sense
the work of ISMS is in response to operator's perceptions of deployment
impediments with SNMPv3.  We are out to alleviate those impediments.

> If you look at
> http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
> zation-06.txt then you will notice that they allow accounting messages
> to carry these new attributes. Btw, the authors of
> http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
> zation-06.txt also allow CoA to be used even though I cannot really say
> whether this is useful in the context of a SNMP.

The ISMS WG saw no use case for SNMP.

> Withdrawing access
> right for a person that is logged into an administrative interface, as
> it can be done with CoA, does not sound too far fetched to me. Another
> example is the need for re-authentication after a certain time period.

Session timeouts are supported in the document.

> http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
> zation-06.txt defines 4 new RADIUS attributes, namely
> - Framed-Management-Protocol
> - Management-Transport-Protection
> - Management-Policy-Id
> - Management-Privilege-Level
> 
> You don't make use of the last two. Is there a specific reason?

Yes, because they are not needed to solve the problem this draft addresses.
If the currently proposed re-chartering is approved in the ISMS WG, then one
of these, the Management-Policy-Id, will likely be used to provision an
extension to VACM.  The last one is defined to apply to CLI only, so would
never be of interest in SNMP work.
 
> In your document you only focus on RADIUS whereas the document that
> defines the attributes, namely
> http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
> zation-06.txt, also defines them for Diameter. Any reason why you did
> not extend your description also to Diameter? Maybe because Diameter is
> not used in your envisioned usage domain or so?

Right.  The ISMS WG was formed to address impediments operators perceived in
the "ease of deployment" of SNMPv3.  The goals were to apply mechanisms and
infrastructure that the operators were already using.  This drove choices
such as SSH and RADIUS.

> Regarding the security considerations: The interworking between RADIUS
> and SSH for authentication and authorization does not really allow
> "high-quality" authentication mechanisms to be used. In the document
> itself you state that mostly username/password is going to be utilized
> and hence I believe that the solution is not secure outside a single
> adminstrative domain. Hence, I would spell this out in the security
> consideration section instead of referring to AAA roaming, particularly
> RFC 2607.

Could you elaborate?  We all know that RADIUS has outdated security
mechanisms, but what specifically about usage with SSH causes additional
concerns?

> Regarding the usage of the Message authentication in RADIUS. I suggest
> to copy-and-paste the following paragraph from
> http://tools.ietf.org/html/draft-ietf-radext-design-07
> and modify it slightly:
> 
> "
>    Message authentication in RADIUS is provided largely via the Message-
>    Authenticator attribute.  See [RFC3579] Section 3.2, and also
>    [RFC5080] 2.2.2. Unfortunately, the Message-Authenticator attribute
>    does not provide confidentiality protection.

We had something longer, but it was shortened to the current form to resolve
WGLC comments.  :-)  Another commented asked for an explanation of why this
recommendation was being made, and the following answer was given.

It is useful because the Message-Authenticator Attribute is the best
available mechanism in RADIUS as it stands today to provide tamper-evident
integrity protection of the service provisioning attributes in an
Access-Accept packet.  It is slightly less important for Access-Request
packets, although it may be desirable to protect any "hint" attributes
contained in those messages.  This protection mitigates the fact that RADIUS
messages are not encrypted and attributes could be added, deleted or
modified by an adversary in a position to intercept the packet.

This is all pretty standard RADIUS Security Considerations material, and
could be shortened to a brief explanation for inclusion in this draft.

>    To avoid eavesdropping of RADIUS message exchanges a secure
> communications protocol, such as
>    IPsec or TLS (with RadSec
> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-04.txt)
> MUST be used.  See [RFC3579] Section 4, and [RFC3580] Section 5 for a
> more in-depth explanation of these issues.
> "

Well, yes.  I'm not sure how far to go here.  The idea was to use the
operators' existing RADIUS infrastructure.  Yes, new firmware will be
required in the NASes, but the attributes used in this document can be added
to the data dictionary of a data dictionary driven RADIUS sever without any
change to the server software.

> If you add RadSec as a normative references your document will
> unfortunately be blocked a little bit (until RadSec is completed) and
> you will have to repeat the IETF Last Call since RadSec will have to be
> indicated as a DownRef in the LC.

I don't think that would serve the goals of the ISMS WG.
 
> IPsec on the other hand can be used without any problems (and is used
> today a lot for protection of RADIUS).

Yes, but is it used in the deployment scenarios this work is targeting?

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 6 May 2009 18:30:17 +0300

Hi Dave, 
 
Thanks for your extremly quick response. 
See my response below. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Dave Nelson
>Sent: 06 May, 2009 16:56
>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'TSV Dir'; 
>[email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [tsv-dir] Transport directorate review 
>ofdraft-ietf-isms-radius-usage-06
>
>> I've reviewed this document as part of the transport area 
>> directorate's ongoing effort to review key IETF documents.
>
>> the direction the document when I read the title. Still, a diagram 
>> would help with the basic idea. In some sense your document is based 
>> on a fairly obvious idea, namely to use the RADIUS backend 
>> infrastructure to relay authentication and authorization for 
>SSH. So, 
>> a figure like this one could help:
>> 
>>                                       +--------+
>>                                       |RADIUS  |
>>                                       |Server  |
>>                                       +--------+
>>                                           ^
>>                                  RADIUS + |  Back-End
>Another reviewer indicated that a diagram would have been 
>helpful to him, so we should probably consider adding one.

OK. 

>My reading of RFC 5090 was that is adds another authentication 
>method to RADIUS.  I guess I'm missing the part where it 
>changes the basic RADIUS model.  :-)

It adds an authentication mechanism as well. The important part, however, is
that it uses RADIUS for an application layer protocol (HTTP and SIP) rather
than for network access. You are essentially doing the same (just for a
different protocol). 

> 
>> Section 1.2 provides an overview of RADIUS. However, I don't 
>think it 
>> is appropriate to use RFC 2119 language in that section.
>

Might be. 

>> Since you mention authorize only later you could refer to 
>this aspect 
>> as well.
>> The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt 
>> allows you  todo authorization without running the authentication 
>> exchange even though you bind the authorization step to a previously 
>> done authentication exchange.
>
>We may end up using a two-step process involving "Authorize 
>Only" when we take up the VACM-related work.  There is no 
>reason to mention such a mechanism in the scope of this 
>document, however. 

OK. I don't know the background of your work. 

>> In the previous section you describe how important it is for the AAA 
>> server to figure this information out and here you  have a 
>SHOULD and 
>> do not explain what happens otherwise if this information is 
>not sent.
>
>Another reviewer mentioned this same point.  We could consider 
>making this a MUST, without unduly impacting interoperability 
>with existing RADIUS servers as servers are always free to 
>ignore such hints.

I don't think this will impact interoperability in any way. If you don't
want to use a MUST then you might want to say what happens if these
attributes are not provided and how the AAA server should react.

>I'm not sure that a keyword is required here, but if one were 
>to be required is would be MUST.

When the AAA server made the decision that the authentication and
authorization step was success then wouldn't you send these attributes. 

>2 access control (IEEE 801.1X).

We should put these things in the RADIUS design guidelines on what one would
write into these tables. The current table is incomplete as the RADIUS RFC
puts more attributes in there. 

>Well, there was no discussion in the ISMS WG that accounting 
>was an operator requirement.  I agree there is a case to be 
>made for it, but in some sense the work of ISMS is in response 
>to operator's perceptions of deployment impediments with 
>SNMPv3.  We are out to alleviate those impediments.

OK. 

>
>> If you look at
>> 
>http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
>> ri zation-06.txt then you will notice that they allow accounting 
>> messages to carry these new attributes. Btw, the authors of 
>> 
>http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
>> ri zation-06.txt also allow CoA to be used even though I 
>cannot really 
>> say whether this is useful in the context of a SNMP.
>

OK. 

>http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
>> ri zation-06.txt defines 4 new RADIUS attributes, namely
>If the currently proposed re-chartering is approved in the 
>ISMS WG, then one of these, the Management-Policy-Id, will 
>likely be used to provision an extension to VACM.  The last 
>one is defined to apply to CLI only, so would never be of 
>interest in SNMP work.
> 
OK. 

>http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
>> ri zation-06.txt, also defines them for Diameter. Any reason why you 
>> did not extend your description also to Diameter? Maybe because 
>> Diameter is not used in your envisioned usage domain or so?
>
>Right.  The ISMS WG was formed to address impediments 
>operators perceived in the "ease of deployment" of SNMPv3.  
>The goals were to apply mechanisms and infrastructure that the 
>operators were already using.  This drove choices such as SSH 
>and RADIUS.

OK. 

>> consideration section instead of referring to AAA roaming, 
>> particularly RFC 2607.
>
>Could you elaborate?  We all know that RADIUS has outdated 
>security mechanisms, but what specifically about usage with 
>SSH causes additional concerns?

I could imagin that administrators might not want their username / password
to travel over the the AAA broker infrastructure when they are also allowed
to configure network equipment. So, the security risk of exposure of
credentials is more than just fraud. 

No problem with SSH as such. 

Maybe I see it more dramatic as it is. 

>We had something longer, but it was shortened to the current 
>form to resolve WGLC comments.  :-)

Sorry. I know what you mean; I had many comments from Glen already :-) 

  Another commented asked 
>for an explanation of why this recommendation was being made, 
>and the following answer was given.
>
>It is useful because the Message-Authenticator Attribute is 
>the best available mechanism in RADIUS as it stands today to 
>provide tamper-evident integrity protection of the service 
>provisioning attributes in an Access-Accept packet.  It is 
>slightly less important for Access-Request packets, although 
>it may be desirable to protect any "hint" attributes contained 
>in those messages.  This protection mitigates the fact that 
>RADIUS messages are not encrypted and attributes could be 
>added, deleted or modified by an adversary in a position to 
>intercept the packet.

I know the Message-Authenticator.  

>
>This is all pretty standard RADIUS Security Considerations 
>material,

That's true. 

> and could be shortened to a brief explanation for 
>inclusion in this draft.

I just thought that the text from the RADIUS Design Guidelines draft was
quite good. With the background on all the key management work I thought it
would be useful to mention the confidentiality protection. 

(I deleted the sentence that said that RADIUS security is quite bad.)
>Well, yes.  I'm not sure how far to go here.  The idea was to 
>use the operators' existing RADIUS infrastructure.  Yes, new 
>firmware will be required in the NASes, but the attributes 
>used in this document can be added to the data dictionary of a 
>data dictionary driven RADIUS sever without any change to the 
>server software.

I think IPsec usage is fine if operators care about the security of their
credentials.

>> you will have to repeat the IETF Last Call since RadSec will have to 
>> be indicated as a DownRef in the LC.
>

Most likely not.  

>Yes, but is it used in the deployment scenarios this work is targeting?

You tell me. 

Whatever you write in this document the operators will use anyway whatever
they want. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 6 May 2009 14:39:30 +0300

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

I understand the purpose of the document and I am fine with the content.
I only have some minor comments/questions. 

                                      +--------+
                                      |RADIUS  |
                                      |Server  |
                                      +--------+
                                          ^
                                 RADIUS + |  Back-End

You write: 

Why don't you use a MUST here? In the previous section you describe how
important it is for the AAA server to figure this information out and
here you  have a SHOULD and do not explain what happens otherwise if
this information is  not sent. 

message
   integrity and confidentiality (i.e. SNMP authPriv):

accountability when it comes to the management of network equipment. If
you look at
whether this is useful in the context of a SNMP. Withdrawing access

You don't make use of the last two. Is there a specific reason? 
I would have just copied the Table of Attributes from
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt and maybe you would have to add a little bit of text
indicating whether these two additional AVPs are somehow in relationship
with SNMP usage.

"

more
   in-depth explanation of these issues.
"

Editorial:

FROM:

SSH server implementations often use the Pluggable
   Authentication Modules (PAM)
   [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by
   operating systems such as Linux and Solaris to integrate with
   password based network authentication mechanisms such as RADIUS,
   TACACS+, Kerberos, etc.

TO:

SSH server implementations often use the Pluggable
   Authentication Modules (PAM) [ref1] interface provided by
   operating systems, such as Linux and Solaris, to integrate with
   password based network authentication mechanisms, such as RADIUS,
   TACACS+, and Kerberos.

[ref1] http://www.opengroup.org/rfc/rfc86.0.html

FROM:

 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a
   mechanism for providing transport layer security for SNMP, allowing
   protocols such as SSH and TLS to be used to secure SNMP
   communication.

TO:

 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a
   mechanism for providing transport layer security for SNMP, allowing
   protocols, such as SSH and TLS, to be used to secure SNMP
   communication.

FROM:

   The Secure Shell protocol provides a secure transport channel with
   support for channel authentication via local accounts and integration
   with various external authentication and authorization services such
   as RADIUS, Kerberos, etc.

TO:

   The Secure Shell protocol provides a secure transport channel with
   support for channel authentication via local accounts and integration
   with various external authentication and authorization systems, such
   as RADIUS, and Kerberos.

FROM:

   1.  Service-Type with a value of Framed-Management.
   2.  Framed-Management-Protocol with a value of SNMP.
   3.  Management-Transport-Protection with a value of Integrity-
       Confidentiality-Protection.

TO:

   1.  Service-Type with a value of TBA-x for "Framed-Management.
   2.  Framed-Management-Protocol with a value of (1) for "SNMP".
   3.  Management-Transport-Protection with a value of (3) for
       "Integrity-Confidentiality-Protection".

The Service-Type value for TBA-x is registered via
draft-ietf-radext-management-authorization. 

FROM:

   The following RADIUS attributes MAY be optionally used, to authorize
   use of SNMP without protection (i.e. authNoPriv):

TO:

   The following RADIUS attributes MAY be optionally used, to authorize
   use of SNMP without integrity and confidentiality protection (i.e., 
   equivalent to the SNMP authNoPriv access).

FROM:

   1.  Service-Type with a value of Framed-Management.
   2.  Framed-Management-Protocol with a value of SNMP.
   3.  Management-Transport-Protection with a value of No-Protection.

TO:

   1.  Service-Type with a value of TBA-x for "Framed-Management.
   2.  Framed-Management-Protocol with a value of (1) for "SNMP".
   3.  Management-Transport-Protection with a value of (1) for
"No-Protection".

Ciao
Hannes