Subject: Re: [Isms] FW: RADEXT WG Last Call on NAS Management AuthorizationSpecification

From: "David Harrington" <[email-masked]>
Date: Sat, 29 Mar 2008 11:52:39 -0400

Hi,

I have reviewed draft-ietf-radext-management-authorization-02.txt for
the WGLC and have comments.

---------------------May fix editorial-------------------
Description of issue
Submitter name: David Harrington
Submitter email address: [email-masked]
Date first submitted: 3-29-08
Reference: URL to e-mail describing problem, if available
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: '1' Should fix
Section: various

Requested changes:
throughout:
"Note that" is usually unnecessary. Don't we want readers to note
everything in the document, or we wouldn't have said it?
section 3:
OLD: "While remote management by interactive CLI
   sessions is carried over protocols, such as Telnet, Rlogin, and
SSH,
   these protocols are primarily for the delivery of terminal, or
   pseudo-TTY services.  Note that, in this context, "SSH" means the
   remote terminal service of SSH, not the more general protected
   transport service of SSH."
NEW: While remote management by interactive CLI
   sessions is carried over protocols, such as Telnet, Rlogin, and the

   remote terminal service of SSH, these protocols are used in this
context
   for the delivery of terminal, or pseudo-TTY services."

section 6:
OLD: "To aid in understanding of this document, it"
NEW: "It"

section 6:
   It is expected that the additional features of this document with
   respect to remote access to the CLI of a NAS will be used in
   conjunction with the existing practice regarding the NAS-Port-Type
   attribute described in this section.
Should this also be expected of other management interfaces if this is
existing practice for the vendor?

section 8.2
s/The acronyms used/The names used/

I suggest the descriptions of the values should identify the threats
and the mitigation provided, in a clear and unambiguous manner. For
example, 
OLD: 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.
NEW: The transport ptotocol MUST protect against unauthorized
disclosure of information.  The secure transport MUST provide
encryption.

section 13:
I have made it a practice to identify the specific registries to be
modified, and the specific changes that need to be made to each
registry. This is easier for IANA, and removes the chance of IANA
misinterpreting what is needed. You say "RADIUS Attributes registry" -
is that the RADIUS Attribute Types registry, or the RADIUS Attribute
Values registry, or both?

Will IANA know just which TBA should be replaced with which assigned
type or value?

section 14:
this entions accounting, but accounting is explicitly out of scope for
this document.

Author's Address:
Greg has no address.

---------------------Should fix editorial-------------------
Description of issue
Submitter name: David Harrington
Submitter email address: [email-masked]
Date first submitted: 3-29-08
Reference: URL to e-mail describing problem, if available
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: '1' Should fix
Section: various

Requested changes:
Section 3:
OLD: "NETCONF (XML over HTTP/BEEP/SOAP)" 
NEW: "NETCONF (XML over SSH/BEEP/SOAP)"

Section 4:
VACM is composed of multiple tables
OLD: (VACM) table [RFC3415],
NEW: (VACM) [RFC3415],

---------------------Technical Issues-------------------
Description of issue
Submitter name: David Harrington
Submitter email address: [email-masked]
Date first submitted: 3-29-08
Reference: 
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: '1' Should fix
Section: various

section 8.1 (and elsewhere)
Shouldn't Framed-Managament-Protocol "Web-based" (2) be HTTP or
HTML/HTTP? Isn't HTTPS Framed-Management-Protocol=HTTP plus
Transport-Protocol=TLS?
Should we develop acronymns NETCONFS and SNMPS and CLIS so we can just
lump the non-secure and secure versions into Configuration-based, and
Polling-based names and so on?

Should SFTP and SCP be listed separately or lumped together?

section 8.2
   The same "No Protection"
   semantics are conveyed by omitting this attribute from an Access-
   Accept packet."
Why is this the default behavior? Wouldn't it be better to default to
full security if the attribute is not present?

section 8.3
The first paragrapgh says zero or more, while the fourth paragraph
says you should not send two or more. 
OLD" "Zero or more"
NEW: "Zero or one"

Paragraph 3 says what to do if one is receiverd; and paragraph talks
about receiving more than one. What if zero are received?

Paragraph 3 says if "the policy rules are incorrectly
   formatted, the NAS MUST treat the packet as if it had been an
Access-
   Reject."
Doesn't this potentially override what the management protocol says
should be done if the rules are incorrectly formatted? If the mgmt
protocol defines an error condition for incorrectly formatted rules,
that error won't be sent because the session is rejected, right? What
happens if it is considered incorrect formatting to have an empty
table of rules, but the operator is trying to gain mgmt access to set
the policy rules into the table? Would RADIUS even know whether the
rules were incorrectly formatted?

section 8.4
I don't understand why we need a special Management-Privilege-Level
attribute. This should be able to specified as a named policy in the
Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
"2" and "3". Implementations simply need to map between the policy
name and their  privilege-level policy implementation.

Different implementations might handle priivilege levels differently -
some might use integers internally, others might use a different range
of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply
a mapping exercise. This is a great opportunity to suggest standard
names for privilege levels, and then vendors can map those standard
names to the internal routines. If vendors provide an API, operators
could name the policies as they wanted and map them to the vendors'
APIs for invoking different privilege levels.

I do not understand "Using the Management-
   Privilege-Level attribute with a Service-Type attribute with a
value
   of NAS-Prompt will have the effect of increasing the minimum
   privilege level.  Conversely, it is NOT RECOMMENDED to use this
   attribute with a Service-Type of Administrative, which may require
   decreasing the maximum privilege level."
How does it increase the minimum privilege level or decrease the
maximum security level? Wouldn't this simply be
implementation-dependent?

section 9:
I have a concern about protocol versions. What if I want SSHv2 because
I don't think SSHv1 is adequate? Should I be able to make the
distinction? or is that simply an operator-provisioning task to
disallow SSHv1 to the device?

I would change Example #4 to use a Management-Policy-ID="Level 15"
rather than a Management-Privilege-Level=15

Example #5 mentions SNMPv3, but the attribute says only SNMP. If the
operator should be permitted to decide which SNMP version can be used,
then we need these specified as different management protocols. I
think it would be better to leave the message-version decision to the
SNMP standard. So I would change the example from "SNMPv3 access" to
simply "SNMP access".  

I would change the paragraph in example #5:
OLD:   Note that there is currently no standardized way of
implementing
       this management policy mapping within SNMPv3.  Such mechanisms
       are implementation specific.
NEW: "A standardized way of mapping from Management-Policy-ID to a
particular access control policy in SNMP is under research."

Example #6 talks about using the Secure Shell Transport Model, but
most existing SNMP implementations do not support this yet. The
"transport model" approach supports a binding between the SSH
authenticated identity and the SNMP database access controls. Some
SNMP implementations support running SNMP (any version) over an SSH
tunnel, but they provide no such binding. I think it is an SNMP
internal matter for SNMP access controls to say "they must use
transport model to get database access". So I would remove the mention
of the Secure Shell Transport Model from the example:
OLD:    6.  SNMP secure Transport Model access, using the Secure Shell
       Transport Model:
NEW:    6.  SNMP access, via a fully-protected secure tunnel of SSH,
to an 
        undefined management access level:

Example#8 doesn't mention which transport protocol should be used to
provide security services. Should it, or is it intentional to allow
any transport protocol be used that can provide
Confidentiality-Protection?

David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 31 Mar 2008 13:55:29 -0400

David Harrington writes...

> I have reviewed draft-ietf-radext-management-authorization-02.txt
> for the WGLC and have comments.

Thanks you!

> "Note that" is usually unnecessary.

OK.  That's a bit of flowery writing that isn't needed.

>    sessions is carried over protocols, such as Telnet, Rlogin,
>    and SSH, these protocols are primarily for the delivery of 
>    terminal, or pseudo-TTY services.  Note that, in this context,
>    "SSH" means the remote terminal service of SSH, not the more 
>    general protected transport service of SSH."
> NEW: While remote management by interactive CLI sessions is 
>    carried over protocols, such as Telnet, Rlogin, and the
>    remote terminal service of SSH, these protocols are used 
>    in this context for the delivery of terminal, or pseudo-TTY
>    services."

OK.

> OLD: "To aid in understanding of this document, it"

Sure.  The point I was trying to convey here is that this document is not
creating the usage being described here, but simply reporting it.
 
> existing practice for the vendor?

I'm not sure what you are trying to ask.  We acknowledge an existing
practice and indicate that it is compatible with the usages defined in this
document.

> s/The acronyms used/The names used/

OK.
 
> OLD: 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.
> NEW: The transport protocol MUST protect against unauthorized

OK.  I think that confidentiality implies the use of encryption, unless the
medium of communication is physically secured, but I have no objection to
your suggested text.

> Values registry, or both?

Both, which one depending upon context.

> Will IANA know just which TBA should be replaced with which assigned

IANA gets to make up the numeric values, and hopefully can tell which is an
Attribute ID code and which is a value, but we could use a notation such as
TBA-A (for attribute IDs) and TBA-V (for values), if you think that would be
helpful.

> section 14:
> this mentions accounting, but accounting is explicitly out of 
> scope for this document.

Not entirely.  Section 12 indicates that some attributes may be included in
Accounting-Request packets.
 
> Greg has no address.

Well, he does have one -- he just hasn't provided it the current draft.
This omission will be corrected eventually -- certainly during AUTH84, if
not before.

> NEW: "NETCONF (XML over SSH/BEEP/SOAP)"

Well, OK, I guess.  Does NETCONF not have a profile for transport over HTTP?
I'm a bit confused on that point.

> OLD: (VACM) table [RFC3415],

OK.

> Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP?

Uh, yes...

> Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS?

Yes, but in the -02 revision the Management-Transport-Protocol Attribute has
been removed, because it seemed like unnecessary over-specification, and
replaced with the Management-Transport-Protection Attribute.  For that
reason, your suggestion doesn't quite work.

> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just

Well, the tradition of RADIUS documents is that we describe how to provision
existing services using RADIUS Attributes.  We stay away from actually
defining the services being provisioned, and simply provide references as
appropriate.  In that light, I think it might be inappropriate to define new
acronyms for such services in this document.

> section 8.2
>    The same "No Protection" semantics are conveyed by omitting this 
>    attribute from an Access-Accept packet."

In the interest of backward compatibility, it seems like de default should
be no security.

> section 8.3
> The first paragraph says zero or more, while the fourth paragraph

OK.

> Paragraph 3 says what to do if one is received; and paragraph talks

If zero are received no management policy is applied to the provisioned
service.  That's universally true of RADIUS service provisioning Attributes.
The absence of an Attribute generally has no significance; it does not cause
any action at the NAS.

> Paragraph 3 says if "the policy rules are incorrectly formatted, the
> NAS MUST treat the packet as if it had been an Access-Reject."
> should be done if the rules are incorrectly formatted?

What management protocol?  Are you alluding to something like the SNMP VACM?

> If the mgmt protocol defines an error condition for incorrectly 
> formatted rules, that error won't be sent because the session is 
> rejected, right?

Well, this is a bit murky.  Traditionally, RADIUS Servers provision a
service to be delivered to the user at the NAS, and the NAS is responsible
for delivering that service, and not some other.  If the NAS cannot deliver
the service (and it knows what it is) then traditionally the NAS has been
required to reject access altogether.   The access protocol may or may not
have an error channel for the NAS to signal to the user that the service has
been denied.

> What happens if it is considered incorrect formatting to have an 
> empty table of rules, but the operator is trying to gain mgmt access
> to set the policy rules into the table?  Would RADIUS even know
> whether the rules were incorrectly formatted?

Probably not.  The NAS might know, because the term "NAS" describes the
entirety of the network device or host device that contains the RADIUS
Client.  The RADIUS Client would almost certainly not know.

In view of this, it may be better or omit the phrase "or the policy rules
are incorrectly formatted".

> name and their  privilege-level policy implementation.

Well, it's just that sort of "mapping" that this attribute was introduced to
avoid.  There are a significant number of currently deployed implementations
that provision CLI access control using an integer-valued parameter.  It is
what it is.  This is simply an attempt to recognize that practice and
provide a way to provision that type of access control via RADIUS.  We are
not attempting (not should we) to redefine how CLI access control works in
NASes, just how RADIUS can be use to provision it.

> This is a great opportunity to suggest standard names for privilege 
> levels, and then vendors can map those standard names to the internal 
> routines.

Hmmm...  I think that type of standardization crosses the line into
"defining the service" and would be out of scope for this document.  I'd
like to solicit some additional WG comment on this suggestion, before we go
down that path.

> I do not understand "Using the Management-Privilege-Level attribute 
> with a Service-Type attribute with a value of NAS-Prompt will have the
> effect of increasing the minimum  privilege level.  Conversely, it is 
> NOT RECOMMENDED to use this attribute with a Service-Type of
> Administrative, which may require decreasing the maximum privilege 
> level."
> maximum security level?

Well, NAS-Prompt is the non-privileged CLI service and Administrative is the
privileged CLI service.  While implementations may vary, my understanding is
that NAS-Prompt has no privileges and Administrative has all privileges
(like root).  Since there are only two choices, this is pretty much a binary
thing -- on or off.

> Wouldn't this simply be implementation-dependent?

It might be...
 
> disallow SSHv1 to the device?

The ability to specify particular transport protocols has been removed from
the -02 version, and thus there is no way to specify a particular version of
a particular transport protocol.  I think this comes down to what is
necessary and sufficient to solve the "80% problem", i.e. what will work
sufficiently well in 80% of the possible deployment scenarios and use cases.
I think we can easily fall into the trap of over-specifying the solution,
and adding way more complexity than anyone will ever actually use
(correctly).

> rather than a Management-Privilege-Level=15

This is dependent on resolution of a previous comment.

> SNMP standard. So I would change the example from "SNMPv3 access" to

I think that the "v3" is as editing artifact, left over from the -01 version
of the draft.

>        implementing this management policy mapping within SNMPv3.
>        Such mechanisms are implementation specific.

OK, that's fine.  We can use text along those lines.

>         to an undefined management access level:

Well, there's something else wrong with Example 6.  It still uses the
removed [Management-]Transport-Protocol attribute.  (There are several
examples with this problem.)  I think that this should be revised to
indicate SNMP access using a particular protection level (i.e.
Management-Transport-Protection).

I'll submit some suggested text in a separate message dealing with errata in
the examples.  Perhaps we can continue the discussion on that basis?
 
> provide security services.

Once again, the Management-Transport-Protocol attribute has been removed
from the -02 version of the draft.

> Should it, or is it intentional to allow any transport protocol to be 
> used that can provide Confidentiality-Protection?

It is intended that any transport protocol that can meet or exceed the
specified minimum security protection requirement (integrity or integrity
and confidentiality) can be used for the session.

Thanks, once again, for your thorough and insightful review comments.

Regards,

Dave Nelson

---

From: "David Harrington" <[email-masked]>
Date: Mon, 31 Mar 2008 16:00:44 -0400

> -----Original Message-----
> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Monday, March 31, 2008 1:55 PM
> To: 'David Harrington'; [email-masked]
> Cc: [email-masked]
> Subject: RE: RADEXT WG Last Call on NAS 
> ManagementAuthorizationSpecification
> 
> > section 13:

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.

> I'm a bit confused on that point.

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

> Yes, but in the -02 revision the 
> Management-Transport-Protocol Attribute has

Transport-Protocol still shows up in section9, and possibly elsewhere
in -02-.

> acronyms for such services in this document.

I was being sarcastic.

> In the interest of backward compatibility, it seems like de 

I disagree. 

> What management protocol?  Are you alluding to something like 

Yes, the implementation of the access control mechanism is the only
thing that willl have enough knowledge of the rules to know if they
are incorrectly formatted. Certainly, the RADIUS client is not
expected to know if VACM rules are incorrectly formatted. I think it
is a "layer violation" to expect the NAS to apply a RADIUS-specific
error responde to a non-RADIUS configuration error. That error should
be detected either when the access control policies are being
configured, e.g. via Netconf or SNMP, or when the policies are being
enforced. The configuration of the access control policies is out of
scope of this document. 

Likewise, if I send a faulty shell script to an interactive shell
interface, I do not expect to get a RADIUS response to this condition;
I expect to get a shell-specific response.

> are incorrectly formatted".

Yes. I believe it would be better to drop that clause.

> NASes, just how RADIUS can be use to provision it.

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

> like to solicit some additional WG comment on this 

Actually, it is only defining a recommendation for how to "name" the
policies for use with management-policy-id. If we shouldn't be
"defining the service" then I have to question whether we should be
providing this other type of mapping for privilege level. I far as I
can see, either approach is defining recommending naming for a policy;
using privilege-level requires an extra attribute for this specific
policy mechanism; using manageent-policy-id uses a consistent
machanism for identifying policies regardless of management protocol.
My understanding is RADIUS attributes are scarce, so why waste one
unnecessarily?

> > Wouldn't this simply be implementation-dependent?

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 Administrtaive, how does my usage
increase/decrease privileges? What if I set a level of '2' to match
NAS-Prompt, and define new evels 0 and 1 to have even less privilege,
how does using this increase/decrease privileges? It seems to be
implementation-dependent.

> and adding way more complexity than anyone will ever actually use

Traponsport-Protocol is still in the official version of -02-. See
section 8.2, section #3 and #6, and section 14.

> and confidentiality) can be used for the session.

I have a concern with removing transport-protocol. 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. If we remove the
operator choice of tunnel protocol, I fear we might under-specify what
is needed to secure a management protocol.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 31 Mar 2008 16:50:28 -0400

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

> 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".
> 

OK.

> So the "mapping" would simply be to take privilege level policy name

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.

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

> 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

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.