IESG review COMMENT on draft-ietf-radext-management-authorization-06.txt

["Dave Nelson" <d.b.nelson@comcast.net>]

[IESG Evaluation COMMENT] from Jari Arkko

> The document is silent on exactly how authentication
> from, say, SCP or is actually represented in RADIUS.

That's true.  Isn't that a matter for SCP (et. al.) to specify?  Certainly
we wouldn't attempt to do so in a RADIUS document.  This document defines
the format and syntax of RADIUS attributes.  It does not act as an
application guide, much as the companion document in the ISMS WG, "RADIUS
Usage for SNMP Transport Models", does for SNMP.  Maybe there is a need for
additional companion documents that provide additional application advice
for other areas such as NETCONF and for adaptation of specific transports
such as SCP.

> Perhaps that is obvious? (But aren't there non-trivial
> details, depending on what kind of challenge or password
> mechanism is in use?) Or is authorize-only used?

Based on discussion of this issue on the RADEXT mailing list and at IETF-74,
the authors suggest adding a new section, in the form of implementation
notes, that reviews the existing forms of RADIUS credentials and points out
that secure transport authentication methods would need to be compatible
with one of the existing RADIUS authentication methods.  This seems obvious,
but it may be worth stating.

 n.  Implementation Notes

   RADIUS currently supports the following user authentication methods,
   although others may be added in the future:

   *  Password (RFC 2865)
   *  CHAP  (RFC 2865)
   *  ARAP  (RFC 2869)
   *  EAP  (RFC 2869, RFC 3579)
   *  Digest (RFC 5090)

   The secure transport protocols selected for use the RADIUS
   remote NAS management sessions, for example those described
   in Section 5.1, obviously need to support user authentication
   methods that are compatible with those that exist in RADIUS.
   The integration of the user authentication mechanism of the
   secure transport with that of the RADIUS client is a matter
   of implementation.

> I support Pasi's Discuss.

Addressed in a separate email message. 


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