RE: I-D Action:draft-ietf-radext-management-authorization-02.txt

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

Juergen Schoenwaelder writes...
 
> > The resolution to this particular set of comments was to change 
> > the attribute to Management-Transport-Protection, and only 
> > provision that which is important -- the level of protection 
> > required for the remote management session.  The four possible
> > values of this attribute are:
> >
> >    o  No-Protection: No transport protection is required.  Accept
> >       connections via any supported transport.
> >
> >    o  Integrity-Protection: The management session requires protection
> >       in a secure or protected transport, that is supported by the
> >       management access protocol and implementation.  The secure
> >       transport MUST provide Integrity Protection.
> >
> >    o  Confidentiality-Protection: The management session requires
> >       protection in a secure or protected transport, that is supported
> >       by the management access protocol and implementation.  The secure
> >       transport MUST provide Confidentiality Protection.
> >
> >    o  Integrity-Confidentiality-Protection: The management session
> >       requires protection in a secure or protected transport, that is
> >       supported by the management access protocol and implementation.
> >       The secure transport MUST provide both Integrity Protection and
> >       Confidentiality Protection.
> 
> I like the general approach.
> 
> I am wondering however how authentication fits into the above list or
> whether you assume integrity-protection and confidentiality-protection
> imply authentication of the two parties involved.

RADIUS is all about authentication.  That basic function of RADIUS has not
changed.  The RADIUS server authenticates the user (via one of the supported
authentication methods) before choosing to send an Access-Accept message.
If the RADIUS server chooses not to authenticate an actual user (e.g.
Call-Check) it would likely not authorize provision of a service that
required a protected transport.  (Although there may be valid uses case for
doing so...)

It is reasonable to assume that in any use case where authentication of the
user (e.g. the SNMP principal attempting to connect to the NAS) is
important, that receipt of an Access-Accept message at the NAS indicates
that the user has been authenticated by the RADIUS server.

What is not specified in this mechanism is a cryptographic binding between
the authenticated RADIUS user identity and the keys, certificates, or other
credentials used to establish the protected transport session.  The NAS may
be in a position to perform this "binding" by relating the authenticated
RADIUS user identity to some local transport session handle.  The details of
this would be a matter of implementation, I would think.

If the NAS is capable of determining, via its API to the transport security
layer, that a protected transport is in use and what its properties are, the
NAS is in a position or enforce the provisions of the
Management-Transport-Protection attribute.  If the NAS is not capable of
making that kind of determination (e.g. because of limitations in the APIs,
etc.), then the whole issue of requiring a protected transport is very
questionable, whether you call it out by name (e.g. SSH or TLS) or you call
it out by property (e.g. Integrity-Protection or
Confidentiality-Protection).

Does that line of thinking make sense to you?



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