RE: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification

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

David Harrington writes...

> My intent was to ask you to spell out in detail which changes you 
> want made to which registry, and then to this document, so IANA 
> doesn't have to figure it out.

Yes, I got that point.  Thanks.  That issue will be clarified in -03.

> RFCs 4742, 43, and 44 defines transports for SSH, SOAP, and BEEP
> respectively. There is no separate mapping for HTTP.

Separate mapping?  I guess I need to learn a bunch more about NTECONF...

> Transport-Protocol still shows up in section 9, and possibly elsewhere
> in -02-.

Yes, but I've indicated that is an error in -02, and I described in a
previous posting to the RADEXT list that it was being removed, and why it
was being removed.  For the sake of comments on -02, please assume it is
gone.

> I was being sarcastic.

Sorry, I couldn't tell.  :-(

> > > Why is this the default behavior? Wouldn't it be better to
> >  > default to full security if the attribute is not present?
> >
> > In the interest of backward compatibility, it seems like de
> > default should be no security.
> 
> I disagree.

You disagree that we should optimize for backward compatibility, or you
disagree that defaulting to fully secure would hinder backwards
compatibility?

> > In view of this, it may be better or omit the phrase "or the
> > policy rules are incorrectly formatted".
> 
> Yes. I believe it would be better to drop that clause.

OK.

> So the "mapping" would simply be to take privilege level policy name
> "1" or "Level 1" and run it through an asctoint() function as part of
> the processing of management-policy-id.

The content of Management-Policy-Id is intended to be a flat name of local
scope.  The only valid operators on this name are strncmp() or
strncasecmp().  That is to say, no transforms are anticipated, other than a
lookup using it as a search key.  Anything else is fraught with
interoperability perils, IMO.

> Actually, it is only defining a recommendation for how to "name" the
> policies for use with management-policy-id.

If we can't (and don't) make such recommendations for the content of
Filter-Id, how could we do so for Management-Policy-Id?

> So if I set a level of '0' to be exactly the same as NAS-Prompt, and a
> level of '16' to be the same as Administrative, how does my usage
> increase/decrease privileges?

For all values of the Management-Privilege-Level attribute (call it X),
where 0 < X < 16, using that attribute in conjunction with a Service-Type
value of NAS-Prompt will elevate the effective CLI privilege level, and
similarly using that attribute in conjunction with a Service-Type value of
Administrative will lower the effective CLI privilege. 
 
> Transport-Protocol is still in the official version of -02-. See
> section 8.2, section #3 and #6, and section 14.

See above.  This is an oversight.

> I have a concern with removing transport-protocol.

Ah, that we can discuss.

> IPSec can provide a fully-secured tunnel, but it never authenticates
> the principal that is used at the application layer. nor does TLS.
> SSH provides user-authentication at a level above transport.

The current proposal, as intended by the -02 draft, is to provision a
minimum security requirement, that the NAS is expected to check and enforce,
as to whether or not the management transport protocol is (a)
integrity-protected (cryptographically check-summed) and (b) confidentiality
protected (encrypted).  In order to implement this proposal, the NAS (not
just the RADIUS Client portion of the NAS) MUST be able to determine if the
required protection is present.  Authentication of the principal is handled
via the traditional authentication mechanisms of RADIUS, and therefore need
not be handled by the secure transport.  It is possible, of course, that the
secure transport participates in providing the principal's identity to the
RADIUS Client for the purpose of authentication.

> If we remove the operator choice of tunnel protocol, I fear we might 
> under-specify what is needed to secure a management protocol.

Let's pursue this a bit.  If we specify the tunnel protocol, then we also
need to specify other properties.  Bernard Aboba pointed that out in his
commentary on the -01 draft.  We then specify the authentication mechanism.
This could involve specification of optional cipher suites.  We could
specify certificates, types of certificates, and certificate authorities,
etc.  This can get very complicated, very fast.  Do we really want or need
to go there?  :-)

My answer to Bernard's commentary was to step back and try to discern what
problem we really needed to solve.  While specifying all the security
properties and options of the secure transport protocol and its support
ecosystem may be needed in some environments, I think it is not required in
the vast majority of environments.  Let's solve a simple problem that we can
solve well, and then see if further work is needed later on, once we have
some deployment experience.

Knowing that your principal has been authenticated (and authorized) and that
the management session is protected from tampering and disclosure is
probably all that the RADIUS Server, and the system administrator, need to
provision.  Additional details, such as a list of acceptable tunnel
protocols, cipher suites, certificate chains, etc, can be provisioned on the
NAS in an implementation-specific fashion.


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