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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

> 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?

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?

> Do I understand correctly that you think it's better to *not*
> 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. 

> (remembering that we're talking about new NASes that implement
> 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.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>