Subject: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt

From: "Dave Nelson" <[email-masked]>
Date: Wed, 15 Apr 2009 14:11:29 -0400

[IESG Evaluation DISCUSS] by Pasi Eronen

> I have reviewed draft-ietf-radext-management-authorization-06. Overall,
> the document looks good, but I have the following concerns that I'd like
> to discuss before recommending approval of the document:
> 
> The document recommends using Management-Privilege-Level only for
> Service-Type 7 (not 6). However, when the NAS receives, for example,
> an SSH connection, does it know whether the user is asking for full
> privilege access, or less privileged management access?  If it does
> not know, what should it do?

The NAS is not expected to know what level of access the user is "asking
for", other than perhaps that an SSH sub-system is involved.  That's purely
a matter of implementation detail, BTW, and is not being standardized.

The RADIUS server is expected to provision the appropriate level of access
for the user, based on the user's authorization profile stored in the
server's database (or otherwise obtained by the server). The server may use
optional (recommended) hint attributes in the Access-Request message that
identify the NAS in question and the type of interface used, e.g. a virtual
terminal connection, in conjunction with the user's authorization profile,
in making its access rights decision.

After discussion on the RADEXT mailing list and at IETF-74, it does not
appear that any change to the draft is required.

> Another question: should the document recommend something about
> Management-Privilege-Level values? For example, should bigger numbers
> mean "more access" or "less access"? (The actual levels are of course
> implementation dependent, but if vendors use opposite conventions, it
> seems that would create unnecessary confusion.)

There is no one convention used by all vendors, and in fact many
implementations allow the mapping of the integer access level to specific
access rights to be configured on the NAS by the user.

After discussion on the RADEXT mailing list and at IETF-74, the
recommendation is to clarify this issue by adding the following text to
Section 5.4 of the draft:

     The mapping of integer values for this attribute to specific
     collections of management access rights or permissions on the NAS
     is vendor and implementation specific.  Such mapping is often a
     user configurable feature.  It's RECOMMENDED that greater numeric
     values imply greater privilege.  However, it would be a mistake
     to assume that this recommendation always holds.

> It seems that a NAS implementing e.g. NETCONF, FTP or web-based
> management would often include the IP address (and perhaps port
> number) where connection came from in the Access-Request message.
> Should the document give some guidance on NAS-Port-ID (or perhaps
> Calling-Station-ID) attributes?  (It seems having at least a mild
> recommendation about the attribute and formatting would be useful,
> instead of every vendor doing things differently.)

Discussion on this issue on the RADEXT mailing list and at IETF-74 yielded
the following observations.  These attributes are not required for use in
management access by RFC 2865 and RFC 2869, and the authors don't think we
want this draft to update those RFCs.  The variation in the format of the
NAS-Port and Calling-Station-Id attributes among different implementations
has been an issue for a long time.  It's probably an interesting topic for a
separate work item, but likely doesn't belong in this draft.  It does not
appear that any change to the draft is required.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: <[email-masked]>
Date: Thu, 16 Apr 2009 21:56:28 +0200

Dave Nelson wrote:

> The NAS is not expected to know what level of access the user is
> "asking for", other than perhaps that an SSH sub-system is involved.
> That's purely a matter of implementation detail, BTW, and is not
> being standardized.
>
> The RADIUS server is expected to provision the appropriate level of
> access for the user, based on the user's authorization profile
> stored in the server's database (or otherwise obtained by the
> server). The server may use optional (recommended) hint attributes
> in the Access-Request message that identify the NAS in question and
> the type of interface used, e.g. a virtual terminal connection, in
> conjunction with the user's authorization profile, in making its
> access rights decision.
> 
> After discussion on the RADEXT mailing list and at IETF-74, it does
> not appear that any change to the draft is required.

The situation for Access-Accept (the important part) is clear, and 
I guess for the hints in Access-Request, we can leave it
implementation-specific... (like many other parts in RADIUS :-)

> implementations allow the mapping of the integer access level to
> specific access rights to be configured on the NAS by the user.
> 

Looks good!

> Discussion on this issue on the RADEXT mailing list and at IETF-74
> yielded the following observations.  These attributes are not
> required for use in management access by RFC 2865 and RFC 2869, and
> the authors don't think we want this draft to update those RFCs.
> The variation in the format of the NAS-Port and Calling-Station-Id
> attributes among different implementations has been an issue for a
> long time.  It's probably an interesting topic for a separate work
> item, but likely doesn't belong in this draft.  It does not appear
> that any change to the draft is required.

Could you provide pointers to the RADEXT mailing list discussions?  
I couldn't find anything in the archive, and the IETF74 minutes don't
mention anything either.

To the degree the source IP/port is just for human consumption
(e.g. troubleshooting or forensics), it's probably OK to leave the
contents implementation-specific. 

But if they're used for something else, to me it seems that this draft
would be the right place to make some recommendations (not necessarily
requirements that would update 2865/2869) for the management 
protocols listed here. (Not for any other use of RADIUS, of course.)

Best regards,
Pasi

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 17 Apr 2009 08:57:05 -0400

Pasi Eronen writes...  

> implementation-specific... (like many other parts in RADIUS :-)

The use of appropriate hint attributes in the Access-Request is RECOMMENDED,
but the NAS can only hint what it knows.  It knows how the session "arrived"
i.e. over what mechanism.  It does not know the intent of the human at the
other end of the connection.  I think this is the best we can reasonably do.

> I couldn't find anything in the archive, and the IETF74 minutes don't

I'll search for the mail message(s) when I get a bit more time.  It was
presented in the slide deck at IETF-74 the proposed resolution to this
issue.  No one suggested we do otherwise.

> protocols listed here. (Not for any other use of RADIUS, of course.)

The attributes that have variability are the NAS-ID and NAS-Port-ID, which
are basically as you have indicated -- human readable strings with no
specific recommended format.  I have to think that these attributes were (a)
intended for use in accounting, where they are simply logged verbatim for
humans to inspect later on or (b) were intended for use in authentication
and/or or authorization decisions, in some vendor-specific fashion.  The
RFCs don't give us any guidance here.

If there are (b) usages, it might be nice to standardize them someday.  The
point we were making was that it's not directly related to the NAS
Management Authorization work, and it's something that may be very difficult
to achieve consensus on, given the large diversity of implementations over a
large number of years.  In sort, the authors feel that it would be
unreasonable to hold *this* draft accountable for solving that problem.

Regards,

Dave Nelson

---

From: <[email-masked]>
Date: Mon, 20 Apr 2009 12:32:09 +0200

Dave Nelson wrote:

> The attributes that have variability are the NAS-ID and NAS-Port-ID,
> which are basically as you have indicated -- human readable strings
> with no specific recommended format.  I have to think that these
> attributes were (a) intended for use in accounting, where they are
> simply logged verbatim for humans to inspect later on or (b) were
> intended for use in authentication and/or or authorization
> decisions, in some vendor-specific fashion.  The RFCs don't give us
> any guidance here.
> 
> If there are (b) usages, it might be nice to standardize them
> someday.  The point we were making was that it's not directly
> related to the NAS Management Authorization work, and it's something
> that may be very difficult to achieve consensus on, given the large
> diversity of implementations over a large number of years.  In sort,
> the authors feel that it would be unreasonable to hold *this* draft
> accountable for solving that problem.

I was not asking this draft to fully solve the problems about
NAS-Port-Id.

I was asking a very specific suggestion: given that many NASes
implementing this specification will probably send the IP address 
(and possibly port number) of the SSH/NETCONF/etc. client *somewhere* 
in the Access-Request packet, should the document give some guidance  
on what attribute/format could be used?

Do I understand correctly that you think it's better to *not*
give any guidance, leaving each vendor to do things differently? 
(remembering that we're talking about new NASes that implement 
the attributes from this draft, not old stuff)

Best regards,
Pasi

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Apr 2009 13:22:27 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, April 20, 2009 1:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: IESG review DISCUSS 
> ondraft-ietf-radext-management-authorization-06.txt
> 
> Dave Nelson wrote:
> 
> decisions, 
> > in some vendor-specific fashion.  The RFCs don't give us 
> any guidance 
> > here.
> > 
> > If there are (b) usages, it might be nice to standardize 
> them someday.  
> > The point we were making was that it's not directly related 
> to the NAS 
> > Management Authorization work, and it's something that may be very 
> > difficult to achieve consensus on, given the large diversity of 
> > implementations over a large number of years.  In sort, the authors 
> > feel that it would be unreasonable to hold *this* draft accountable 
> > for solving that problem.
> 
> I was asking a very specific suggestion: given that many 
> NASes implementing this specification will probably send the 
> IP address (and possibly port number) of the SSH/NETCONF/etc. 
> client *somewhere* in the Access-Request packet, should the 
> document give some guidance on what attribute/format could be used?
> 
> (remembering that we're talking about new NASes that 
> implement the attributes from this draft, not old stuff)
> 
> Best regards,
> Pasi
> 

My opinion is that it is better to not give any guidance in this
document, for the reasons mentioned by David. A proper and complete
solution would require long discussions and I am not certain is within
the scope here, and in the absence of a complete solution I prefer to
leave this implementation dependent at this point in time. 

Dan

---

From: <[email-masked]>
Date: Mon, 20 Apr 2009 13:39:41 +0200

> leave this implementation dependent at this point in time.

We all know that proper and complete solution will never happen... but
since so many other RADIUS details are vendor-dependent, I guess this
one won't really change the overall interoperability situation.

I'll clear when David's proposed text for Section 5.4 (email 2009-04-15,
about management privilege levels) is there. An RFC editor note would
work for me.

Best regards,
Pasi

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 20 Apr 2009 13:57:07 -0400

> implementing this specification will probably send the IP 
> address (and possibly port number) of the SSH/NETCONF/etc.

Actually, I don't think that this is a common practice.  If I understand
this correctly, you're asking that the NAS send the IP address and (source)
TCP/UDP port number of the protocol *peer* as hints in an Access-Request
packet.  This is basically the protocol-domain identity of the remote host.
That's how I interpret "client" as it appears in your message, quoted above.
I presume that one use case for this would be a listing of client systems,
maintained at the RADIUS server, from which such connections are allowed to
be originated.  Personally, I don't see any significant value in host-based
authentication in addition to RADIUS user authentication.

If this information *were* to be sent, we would need either a new attribute
(or new attributes), or a further overloading of the Calling-Station-Id
attribute.  Calling-Station-Id was defined in RFC 2865 to be a phone number
and overloaded in RFC 3580 to be an Ethernet MAC address.  We *could*
further overload this attribute to be an IPv4 or IPv6 address.  I'm not sure
that would be the best approach.  Do you have a specific motivation for
including remote host identity in the Access-Request packet?

> give any guidance, leaving each vendor to do things differently?

No, not better.  My question was whether this issue was in scope for this
draft and whether there was currently sufficient consensus in the RADIUS
community to standardize this usage, or if not, how long it might take to
establish consensus. 

> the attributes from this draft, not old stuff)

Yes, but if the solution overloads or redefines the content of existing
attributes in any way, it's no longer a "green field" discussion.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 20 Apr 2009 14:02:26 -0400

> I'll clear when David's proposed text for Section 5.4 (email
> 2009-04-15, about management privilege levels) is there. An 
> RFC editor note would work for me.

Dan had suggested that we issue a -07 revision once all the DISCUSS and
COMMENT issues have been conceptually cleared.  That should not take more
than a day or so.