Subject: [Isms] last call to check the changes of the radius / vacm document

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 May 2010 12:08:44 +0200

The RADIUS / VACM document <draft-ietf-isms-radius-vacm-05.txt> was
last called March 8-22.

The last call discussion resulted into several relatively minor
changes now incorporated in <draft-ietf-isms-radius-vacm-06.txt>.
This message starts a 7-day last call to verify the changes made in
the revised version. The document can be found here:

  http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-06

The changes can be found here:

  http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-06

Please post any issues you have with the changes to the WG mailing
list by May 22nd. Silence will be interpreted as support for the
changes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 May 2010 12:10:36 +0200

> list by May 22nd. Silence will be interpreted as support for the

I spotted one editorial nit:

s/GroupName, which is identifies/GroupName, which identifies/

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 15 May 2010 10:58:53 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, May 15, 2010 3:10 AM
> Subject: Re: [Isms] last call to check the changes of the radius / vacmdocument
...
> s/GroupName, which is identifies/GroupName, which identifies/

Thank you.  I've applied the correction to the xml source file.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 May 2010 18:56:00 -0700

Hi -

> Sent: Saturday, May 15, 2010 3:08 AM
> Subject: [Isms] last call to check the changes of the radius / vacm document
...
> list by May 22nd. Silence will be interpreted as support for the

I've received a total of 1 comment, a request for a typo fix.
I've applied the correction to my XML source, and can generate
an updated draft whenever you like.  Let me know how you'd like
me to procede.

Randy

---

From: Dave Nelson <[email-masked]>
Date: Wed, 26 May 2010 22:17:48 -0400

In order to be pro-active, I should indicate that I've reviewed the latest
draft and see no problems with the changes it incorporates.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 May 2010 08:17:47 +0200

> an updated draft whenever you like.  Let me know how you'd like

Just keep the typo fix in your xml source; there might be a need for
another revision later on in the process when this document hits the
IESG.

Since nobody raised substantial comments, I have an action item now to
produce a document writeup and then we can take this document to our
AD.

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 May 2010 13:18:25 -0400

Whoops. running late...

I am thrilled to see this document getting close to submission. I
think this is trememdously important specification to simplify SNMP
authentication and access control.

Unfortunately, this document repeatedly ignores RFC3411 modularity,
creates unnecessary dependencies between models, and ignores which
model has access to which information. In some cases, I think the text
as written could not be implemented in a manner that is consistent
with RFC3411 modularity. These need to be corrected. 

1) section 1:
"In this environment:" starts a list of specific choices of modules.
This is not consistent with the SNMPv3 approach of "model agility" -
ensuring different models could be used together and updated
independently of other models in use. For example, an SNMPv4 message
format could be developed, and such a messaging model could be used in
place of SNMPv3 message format. A new transport-aware security model
could provide comparable capabilities to TSM. It is inappropriate for
one model to require specific other models, but not inappropriate to
recommend/require specific properties for related models. It is up to
administrators to ensure that the models are deployed in appropriate
conbinations (and the specifications should provide deployment
recommendations).

This section should be rewritten to specify the properties expected,
with suggestions for models that provide those properties. I think
this can be compared to security algorithm agility - "here is the
threat, and here is the currently recommended mitigation" vs. "DES is
used to provide security."

Obviously, this specification MUST be used with the VACM model and
RFC5608 since it extends the VACM model with information from RFC5608
attributes. However, it is NOT a requirement that this be used with
only SNMPv3 messages, TSM, or SSH. Section 1 makes it appear this
specification can only work in an environment with those models.

2) section 4.2, paragraph 2 discusses the need to bind the
authenticated principal with the identity used for access control. It
implies SNMP does not provide such a binding. RFC3411 explicitly
provides such a binding - the securityName output of the security
model is expected to be used as the identity in access control
decisions (via the isAccessAllowed ASI). It was a deliberate design
decision to separate the underlying authetication algorithmic
mechanism, e.g. SSH username, from the access control configuration by
passing a security-algorithm-independent securityName from the
security subsystem that could be used to configure the access control
subsystem (using the access-control-model-independent securityName).
securityModel/securityName provides a binding while avoiding
model-specific dependencies.

3) section 4.3 
This is a list of requirements that must be met by transport security
models. Security models SHOULD NOT have these features. These are
secure transport properties, that can be recognized and handled by
associated transport models, but never by security models.

The security subsystem has no notion of session. RFC5990 and 5991 are
quite explicit about this. TSM has no session, so even TSM would not
meet this requirement.

As described in RFC5991, not all secure transports support a notion of
session; some have a notion of channels or something similar.

4) I think you may want to clarify this further. You might want to say
the secure transport used must have a notion of session to which AAA
authentication and authorization can be bound. 

5) a security model should never provide an indication of the end of a
specific transport session. Only the transport model should be aware
of the transport session (unless your design will include a
model-independent indication that gets shared somehow, such as via a
MIB).

6) section 7.1 - I don't understand what this says. I am not certain
what is meant by "The security model SHOULD bind principal identity to
access control policy via an external AAA server, as the Transport
Security Model does." RFC5591 defines TSM, and the only mention of AAA
is a warning not to rely on AAA in times of network stress.

The modularity of RFC3411 actually argues against having the security
model know anything about the access control policies. AC policies are
defined **within** an access control model (see RFC3411 A.4), and the
binding between a securityName and a policy (e.g. groupname) is
**deliberately** done AFTER the isAccessAllowed ASI is called (inside
the access control subsystem). This approach allows for group-based
policies ala the VACM model, and allows models that use other types of
policies, such as a UNIX-style user-group-all rrw hierarchies. In
fact, the security model NEVER communicates directly with the access
control subsystem in the RFC3411 architecture; the security model
passes securityName to the application subsystem, which presumably
passes the same securityName to the access control subsystem via
isAccessAllowed. This was a deliberate decision made by the SNMPv3 WG
in the design of the RFC3411 architecture.

7) section 7.2
it is unclear to me which subsystem is doing the processing involved.
I am not sure any model has all the information at the same time.

8) 7.2.1
s/a new secure transport model session has been established/
s/a new transport session has been established/

I recommend referring to the transport model as the "Transport Model"
rather than "Secure Transport Model", to avoid confusion with
"Transport Security Model".

9) 7.2.3
It is unclear what "the value of an instance of extGroupName is
updated" means. This is in a received communication from RADIUS? How
does one determine what a corresponding entry is?

10) 7.3 
a transport model session never ends; transport sessions do.
"is provided to this function" - what function?
"session ... within the scope of that SecurityModel" - what security
model? sessions do not exist within security models.

11) section 8
I'm not crazy about long object names, but this module has been named
snmpExtVacmMIB; all the objects with an extVacm prefix should be
updated, and text references to them should be updated, to be
consistent with RFC4181 conventions.

I didn't go through the whole MIB looking for grammar and modularity
problems. I spotted grammar issues in the first DESCRIPTION clause
(extVacmSecurityToGroupTable), and modularity in the second
(extVacmSecurityToGroupEntry). Randy, can you please look the
DESCRIPTION clauses over closely?

12) extVacmSecurityToGroupEntry - entries in extVacmTable do not
persist. section 7.3.2 say that the vacmTable entry should be removed
when no extVacmTable entries exist. So do the corresponding vacmTabel
entries also not persist?

13) extVacmSecurityModel - security models don't have sessions.

14) in this case, doesn't this specifally need to come from the RADIUS
Management-Policy-ID? Ergo, this is not really an example; it is a
requirement. If the purpose of saying this is an example is to allow
for other AAA, then other places in the text that mention only RADIUS
need updating.

15) In section 9, I think the first paragraph could be much more
succinct, and clearer:
OLD:
  The algorithms in this memo make heuristic use of the StorageType of
   entries in the vacmSecurityToGroupTable to distinguish those
   provisioned by a security administrator (which would presumably not
   be configured as "volatile") from those dynamically generated.  In
   making this distinction, it assumes that those entries explicitly
   provisioned by a security administrator and given a non-"volatile"
   status are not to be dynamically over-ridden.  Users of this memo
   need to be aware of this operational assumption, which, while
   reasonable, is not necessarily universally valid.  For example,
this
   situation could also occur if the SNMP security administrator had
   mistakenly created these non-volatile entries in error.
NEW:
  The algorithms in this memo make heuristic use of the StorageType of
   entries in the vacmSecurityToGroupTable to distinguish entries
   provisioned by a security administrator from those dynamically
generated.  
   Entries given a status other than "volatile" are assumed to be
deliberately 
   provisioned by a security administrator to override centralized AAA
policy. 
   See 7.2.2 for details.

16) section 9
OLD:
   o  Entries for the vacmSecurityToGroup table corresponding to a
given
      security model are created only through the operation of the
      procedures described in this memo.  A consequence of this would
be
NEW:
   o  In the first approach, entries for the vacmSecurityToGroup table
corresponding to a given
      security model are created only through the operation of the
      procedures described in this memo.  A consequence of this would
be

rationale: it needs to be clear that this is describing only the first
entry-creation approach, not the general case. We need to be clear
that this is a deployment decision, not a REQUIREMENT of the
vacm/radius extension. You might also be able to clarify this by using
numbers rather than symbols for the bullets.

17) I found this section describing the approaches rather confusing.
The langugae is not very tight. For example, what does "inconsistent
re-use of the same name for different entities or individuals
(principals)" mean? I think this could be simplified by using
consistent langauge; we already know what prinisipal standards for, we
don't really need to re-specify the "entities or individuals" again. I
assume the "same name" means the same securityModel/securityName since
that is what we deal with here. But it is an INDEX value, so doesn't
that guarantee uniqueness? If we are talking about the same, for
example, SSH user name, the uniqueness should be provided by the
transport model. So whihc "same name" use cases are we talking about
here?

I think some example tables would be helpful, to show what would
happen when certain new entries are called for by new extVacm fields
to be used to create new extVacmTable entries.

18) 
 o  extVacmGroupName - since this identifies a security policy and
      associates it with a particular user, this is potentially
      sensitive.
No it doesn't; this object only identifies the policy; it is the table
entry that associates it with a principal.

19) RFC5591 should not be normative. I don't think there is anything
specific inside rfc5591 that must be known to understand this
document, and except for the Intro, 5591 and TSM  and "Transport
Security Model" are only mentioned where I argue it is incorrect. 

Again sorry for being slow.
I hope this review helps get the document through the approval process
faster.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, May 27, 2010 2:18 AM
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: [Isms] last call to check the changes of the 
> radius / vacm document
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 27 May 2010 13:51:25 -0400

> with RFC3411 modularity. These need to be corrected.

I'll need a block of time to study and reply to Dave's commentary.  I  
like the opportunity to do that before we make changes to the draft.   
While I'm sympathetic to the notion of maintaining the RFC3411  
modularity, I'm not convinced it's completely possible when it comes  
to the Security Subsystem.  While it may be possible to implement a  
Security Model in a way that honors RFC3411 and would work with a  
session-based AAA system such as RADIUS, I believe that no such models  
exist.  Unfortunately, think that in choosing an "end-around" approach  
to a thorny problem, and simply "outsourcing" security to the  
Transport Subsystem, we've effectively caused many of the modularity  
violations that Dave points out.

Now, I realize that "them's fightin' words", so I'll need some time to  
work through Dave's comments and see where fully general modularity  
can be introduced into this document, and where it simply can't,  
unless we want to revisit the decisions that led to the TM and TSM  
that we are building upon.

While the "last call" is over, I'll need an extension to digest and  
respond to all this material

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 May 2010 14:05:45 -0400

Hi,

Let me be clear. I think most of the problems I cite are not about the
difference between the RADIUS philosophy and the SNMPv3 philosophy.

Many of the problems are actually editorial problems, where the text
says "security model" when it should have said "transport model". and
the text just doesn't keep a clear distinction between them. Often it
is unclear which subsystem is expected to do something that needs
doing. The text just needs to be "tightened".

In some cases, further debate might be needed, but I think we have
consensus about the "in the background" approach. It needs to be
described more accurately.

dbh

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Thursday, May 27, 2010 1:51 PM
> To: David Harrington
> Cc: 'Juergen Schoenwaelder'; 'Randy Presuhn'; [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 27 May 2010 14:14:55 -0400

> doing. The text just needs to be "tightened".

That would be nice.   Since you've suggest that sections be rewritten,  
without supplying the suggested, text, I think some time is needed to  
work out and review suggested text.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 May 2010 07:56:31 +0200

> in the design of the RFC3411 architecture.

David,

you understand very well that the RADIUS AAA exchange happens at a
processing stage where VACM is not yet involved and as a consequence
RFC 3411 purity a la "there is only a model independent securityName"
simply does not work. The WG (and I believe also you) agreed that the
RADIUS supplied group name is passed into VACM via some implementation
specific mechanism. I like to ask you explicitely whether you still
support that concensus.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 28 May 2010 13:29:05 -0400

Hi, 

Executive Summary:
Yes. I **strongly support** an implementation-specific mechanism for
passing authorization and transport session data from the transport
security use of AAA in the transport model into the VACM model. 

When this document goes to IESG Review, I will recuse myself
(http://www.ietf.org/iesg/voting-procedures.html) because I have been
involved in the development of the technology design, have contributed
to the current document, and authored some of the RFC341x and RFC559x
documents with which I find this document in conflict. So if anybody
thinks I am threatening to block this document, you can think again.
If I did not recuse myself, I would vote "YES" because I think this
proposal is very important.

Detailed Response:

I strongly support this approach because using such an approach does
not require that the ASIs be changed to support passing AAA
authorization information in ASI parameters (or caches). I think
requiring such changes in the ASIs would require re-opening almost all
the SNMPv3 documents, which could destabilize SNMPv3, and would make
the updated RFC341x and RFC559x documents very difficult to work with
in the future. When I look at documents developed elsewhere in the
IETF, few are constrained to such a tight architecture as RFC3411, and
many have complained about the tight constraints, including myself. It
is my impression, however, that almost all who gripe (especially
implementers) also reach the conclusion that in the long run the
constraints have actually been very helpful and the RFC3411
architecture should remain as a guiding principle in SNMP standards
design.  

I have significant knowledge in this space, as RFC3411 co-author and
as co-chair of the SNMPv3 WG which had strong consensus to use the
RFC341x modular architecture for the SNMPv3 standard. Most of my
review is about pointing out the discrepancies between SNMPv3 WG
consensus and this document, whose current text I think actually does
NOT do a good job of representing ISMS WG consensus. 

The IESG will certainly look at two major points that they usually
look at. 1) whether the document is consistent with the general design
principles for the protocol being modified, and 2) whether the
document fits within the constraints placed on the WG during IESG
charter approval.

My biggest concern with the current document is that the document is
rather sloppy about maintaining the data hiding aspects of RFC3411
modularity. For example, there are a number of instances where the
document says that the **security model** does something with a piece
of information, when the security model explicitly does not have
access to that information according to RFC341x and RFC559x. I pointed
out a number of other modularity/clarity issues in my review. I think
this "sloppiness" is not a matter of poor work ethic; I think all the
editors have done very good work. However, the original authors are
RADIUS guys, indoctrinated in RADIUS concepts and RADIUS-speak, and
they are not SNMP-guys indoctrinated in the RFC341x concepts and
wordsmithing. So some wordsmithing errors crept in.

If this document were submitted to the IESG in its current form, I
think it would draw many discusses from other IESG members ***because
it is inconsistent with the RFC341x and RFC559x documents***, and with
the charter constraints. I will fight for the right of this WG to
reach consensus to use an implementation-specific approach to
bypassing the ASIs. I will not fight for the right of the WG to
produce documents that are inconsistent with other documents in the
set of SNMP documents.

I have been very busy getting acclimated to my new role and have not
had the time to participate actively in the WG lately, and as a result
was delayed on doing a WGLC review. I apologize for th ekateness o fmy
review. I debated whether to 
do my review now, or during IETF Last Call or during IESG review. I
prefer to use the choice that provides the least amount of late
surprise, the least amount of authority, and the least number of
DISCUSSes to be resolved during IESG Review. I choose to provide this
review as early as possible so you can try to fix the problems BEFORE
submitting the document to the IESG. 

My review is done as a WG member, and I will recuse myself in IESG
balloting for this document. The WG can choose to totally ignore my
review if you want. However, I think the comments have substance, and
I think it likely your AD and the rest of the IESG will not just
ignore the comments, and the WG will have a hard job of getting IESG
Approval for the document as written. 

I think this is an important document, and want to see it approved as
quickly as possible. My review was to alert the WG to issues of
consistency with RFC341x and RFC559x that I believe should be
addressed so that IESG Review will be made easier.

dbh

> From: Juergen Schoenwaelder 
> 
> David,
>