Subject: [Isms] Attempt at addressing DBH's comments

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 2 Jun 2010 23:05:43 -0700

Hi -

I took a stab at trying to address David Harrington's comments.
I've posted this in the form of an individual i-d.  Please
take a look at draft-presuhn-isms-radius-vacm-alt-00.txt;
I'd appreciate feedback as to whether this might be a step
forward or a step backwards, and whether it addresses your
understanding of David's comments.

http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jun 2010 05:50:07 -0700

>>>>> On Wed, 2 Jun 2010 23:05:43 -0700, "Randy Presuhn" <[email-masked]> said:

RP> I took a stab at trying to address David Harrington's comments.
RP> I've posted this in the form of an individual i-d.  Please
RP> take a look at draft-presuhn-isms-radius-vacm-alt-00.txt;
RP> I'd appreciate feedback as to whether this might be a step
RP> forward or a step backwards, and whether it addresses your
RP> understanding of David's comments.

RP> http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt

Or for those that prefer diffs:

http://tools.ietf.org//rfcdiff?url1=draft-ietf-isms-radius-vacm-06.txt&url2=draft-presuhn-isms-radius-vacm-alt-00.txt
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 3 Jun 2010 14:58:57 -0400

4.2.  Applicability

    Though this memo was motivated to support the use of specific
    Transport Models, such as [RFC5592], it MAY be used with other
    implementation environments satisfying these requirements:

    o  use an AAA service for sign-on service authorization;
DBN:  RFC 5608 describes RADIUS service authorization.  This document  
describes RADIUS data access control authorization.  In point of fact,  
I believe that *both* service authorization and data access control  
authorization are prerequisite properties for applicability.
    o  provide an indication of the start of of a session for a
       particular authenticated principal, identified using a
       SecurityName, and provide the corresponding value of  
vacmGroupName
       to be used, based on information provided by the AAA service in
       use;

    o  provide an indication of the end of the need for being able to
       make access decisions for a particular authenticated principal,  
as
       at the end of a session, whether due to disconnection,  
termination
       due to timeout, or any other reason.

    Likewise, although this memo specifically refers to RADIUS, it MAY  
be
    used with other AAA services satisfying these requirements:

    o  the service provides information semantically equivalent to the
       RADIUS Management-Policy-ID attribute [RFC5607], which  
corresponds
       to a GroupName;
DBN:  s/Management-Policy-ID/Management-Policy-Id/

    o  the service provides information semantically equivalent to the
       RADIUS User-Name Attribute [RFC2865], which corresponds to a
       SecurityName.

7.1.  Sequencing Requirements

    These procedures assume that a transport model, such as [RFC5592],
    coordinates session establishment with AAA authorization.
DBN: s/authorization/authentication and authorization/
    They rely
    critically on the receipt by the AAA client of the RADIUS  
Management-
    Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their
    equivalents) from the RADIUS Access-Accept message (or equivalent).
DBN:  The RADIUS User-Name attribute is not provided in the Access- 
Accept message.  The RADIUS client must remember it from the Access- 
Request message.  In point of fact, this will typically come from some  
user identifier provided by the transport service that utilizes the  
RADIUS client, such as an SSH server. etc.

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Thu, 3 Jun 2010 17:28:26 -0400

Hi,
 
While discussing the RADIUS user name (or equivalent), it may be helpful
to add more information in the description clause of extVacmSecurityName
based on the following information.
 
Section 7.2.1
> extVacmSecurityName = RADIUS User-Name Attribute or equivalent
 
>  DBN:  The RADIUS User-Name attribute is not provided in the
>  Access-Accept message.  The RADIUS client must remember
> it from the Access-Request message.  In point of fact, this will
> typically come from some user identifier provided by the transport
> service that utilizes the RADIUS client, such as an SSH server. etc.
 
Current implementation:
 
 extVacmSecurityName OBJECT-TYPE
      SYNTAX       SnmpAdminString (SIZE(1..32))
      MAX-ACCESS   not-accessible
      STATUS       current
      DESCRIPTION "The Security Name of the principal associated with
                   this session."
      ::= { extVacmSecurityToGroupEntry 2 }

- Andy Donati
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David B. Nelson
Sent: Thursday, June 03, 2010 2:59 PM
To: Randy Presuhn
Cc: [email-masked]
Subject: Re: [Isms] Attempt at addressing DBH's comments

4.2.  Applicability

   o  use an AAA service for sign-on service authorization;
DBN:  RFC 5608 describes RADIUS service authorization.  This document
describes RADIUS data access control authorization.  In point of fact, I
believe that *both* service authorization and data access control
authorization are prerequisite properties for applicability.
   o  provide an indication of the start of of a session for a
      particular authenticated principal, identified using a
      SecurityName, and provide the corresponding value of vacmGroupName
      to be used, based on information provided by the AAA service in
      use;

   o  provide an indication of the end of the need for being able to
      make access decisions for a particular authenticated principal, as
      at the end of a session, whether due to disconnection, termination
      due to timeout, or any other reason.

   Likewise, although this memo specifically refers to RADIUS, it MAY be
   used with other AAA services satisfying these requirements:

   o  the service provides information semantically equivalent to the
      RADIUS Management-Policy-ID attribute [RFC5607], which corresponds
      to a GroupName;
DBN:  s/Management-Policy-ID/Management-Policy-Id/

   These procedures assume that a transport model, such as [RFC5592],
   coordinates session establishment with AAA authorization.
DBN: s/authorization/authentication and authorization/
   They rely
   critically on the receipt by the AAA client of the RADIUS Management-
   Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their
   equivalents) from the RADIUS Access-Accept message (or equivalent).
DBN:  The RADIUS User-Name attribute is not provided in the
Access-Accept message.  The RADIUS client must remember it from the
Access-Request message.  In point of fact, this will typically come from
some user identifier provided by the transport service that utilizes the
RADIUS client, such as an SSH server. etc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Jun 2010 12:06:17 +0200

> http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt

David,

can you take a look at this document and let us know whether this
rewrite addresses your comments? If not, can you please provide
concrete suggestions that help us/Randy to move forward?

/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: "David B Harrington" <[email-masked]>
Date: Tue, 8 Jun 2010 17:25:10 -0400

Hi,

I looked at it, and it is much cleaner, but I have  a real problem
with the use of "session", which is a nebulous thing, and different
references to session seem to refer to different things -  a transport
session, a transport model session (tmSessionID), the authentication
of a principal, a AAA "policy" authorization. The existence and
closing of a "session" triggers behaviors, and if interpretation of
session differs, implementations might behave differently - in an
externally visible way. So it is important to understand just what
"session" means. 

in 4.1:
OLD:
   [RFC5607].  When tracked using a suitable session identifier, such
as
   tmSessionID [RFC5590], these provide sufficient information to
   compute dynamic updates to VACM.  How this information is
NEW:
   [RFC5607].  

   tmSessionID [RFC5590] is considered a suitable identifier of a
AAA-authorized "session", 
   because tmSessionID and tmSecurityName, assigned by a AAA-aware
transport model, identify a 
   specific transport session authorized to offer SNMP service, for
which a principal has been 
   AAA-authenticated. If present, a RADIUS-Management-Policy-ID
attribute is bound to such a 
   transport session and principal authentication. This binding
provides sufficient information to 
   compute dynamic updates to VACM.  How this information is

In 4.1, 
OLD
   o  the service provides information semantically equivalent to the
      RADIUS User-Name Attribute [RFC2865], which corresponds to a
      SecurityName.
NEW:
   o  the service provides an authenticated principal identifier that
can
      be transforned into an equivalent principal identifier in a
SecurityName form.

In 7.1,
OLD:
   These procedures assume that a transport model, such as [RFC5592],
   coordinates session establishment with AAA authorization.  They
rely
   critically on the receipt by the AAA client of the RADIUS
Management-
   Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their
   equivalents) from the RADIUS Access-Accept message (or equivalent).
NEW:
   A transport model, such as [RFC5592], coordinates transport model
session 
   establishment with principal authentication and transport session
authorization. 
   The credentials and services used by a transport model to
authenticate the principal 
   are determined in an implementation-dependent manner. 
   The procedures in this memo rely on implementation-specific use of
AAA
   services to perform the principal authentication, and to provide
AAA authorization 
   policies such as the RADIUS Management-Policy-Id attribute
[RFC5607].

in 7.1:
OLD:
   To ensure correct processing of SNMP PDUs, the handling of the
   indication of the termination of a session in accordance with the
   elements of procedure below MUST NOT be initiated before all
   invocations of the IsAccessAllowed() abstract service interface
have
   completed for all SNMP PDUs from that session.
NEW:
I am not sure how to reword this. The application subsystem processes
the PDUs and calls the
isAccessAllowed() ASI. The processing of a session termination is
handled within the
ACM subsystem. The current text is like saying "a session starts when
you plug your phone into an RJ11 socket, and you cannot unplug the
phone until everybody has finished calling you."
What you really need to say is "if you unplug the phone before
everybody has finished calling you, then any existing and subsequent
calls may fail."
   If the handling of the termination of a session in accordance with
the
   elements of procedure below removes the userToGroup mapping from
the VACM table,
   before all invocations of the IsAccessAllowed() abstract service
interface have completed 
   for all SNMP PDUs from that session, those invocations MAY result
in an access denied error.
You could try to make this "Implementations SHOULD NOT terminate a
session until all PDUs for a session have been processed, but I'm not
sure that's the right AAA security property; it might be better to
have the PDU fail if the authorization is revoked during processing.

in 7.2:
OLD:
   o  the SnmpSecurityModel [RFC3411]
NEW:
   o  the SnmpSecurityModel [RFC3411] used to create the securityName
used in the isAccessAllowed() invocation.

OLD:
   o  a session identifier, such as tmSessionID [RFC5590]
NEW:
   o  a session identifier, such as tmSessionID [RFC5590], that is a
definitive identifier of the transport session that the AAA
authorization is tied to.

OLD:
   o  extVacmSecurityName = RADIUS User-Name Attribute or equivalent
NEW:
   o  extVacmSecurityName = the securityName that will be used with
isAccessAllowed() ASI

in 7.3:
OLD:

   Whenever a RADIUS (or other AAA) authenticated session ends for any
   reason, an indication is provided to this function.  This
indication
   MUST provide means of determining the SnmpSecurityModel and an
   identifier for the session, which MUST be unique at least within
the
   scope of that SnmpSecurityModel.  The manner in which this occurs
is
   implementation dependent.
NEW:

   Whenever a RADIUS (or other AAA) authorized session ends for any
   reason, an indication is provided to this VACM extension.  This
indication
   MUST provide means of determining the SnmpSecurityModel,
securityName, and an
   identifier for the transport session tied to the AAA authorization.
The manner 
   in which this occurs is implementation dependent.
 
in 7.3.1: 
OLD:
   When a session has been terminated, the extVacmSecurityToGroupTable
   is searched for a corresponding entry.  (A "matching" entry is any
   entry for which the SnmpSecurityModel and session ID match the
   information associated with the session termination indication.)
Any
   matching entries are deleted.  It is possible that no entries will
   match; this is not an error, and no special processing is required
in
   this case.
NEW:
   When a session has been terminated, the extVacmSecurityToGroupTable
   is searched for a corresponding entry.  A "matching" entry is any
   entry for which the SnmpSecurityModel, securityName, and session ID

   match the information associated with the session termination
indication. 
   It is possible that no entries will match; this is not an error,
and 
   no special processing is required in this case.

  extVacmSecurityModel OBJECT-TYPE
      SYNTAX       SnmpSecurityModel(1..2147483647)
      MAX-ACCESS   not-accessible
      STATUS       current
      DESCRIPTION "The Security Model to which the session referred
                   to by this entry belongs.
                   This object cannot take the 'any' (0) value."
      ::= { extVacmSecurityToGroupEntry 1 }

A session does not belong to a security model. 
A securityName is created by a security model. 
so I suppose you could say "The Security Model to which the
securityName referred to by this entry belongs."
It's not the way I would normally approach describing it, but I guess
it's accurate.
Maybe "The Security Model associated with the AAA binding represented
by this entry."
If you change this, then you might want to change the securityName and
sessionID descriptions as well.

I think a securityName is specific to the security model that
generates it. USM and TSM can both generate a "dbh" securityname, so
you always need to identify the securityModel associated with a
securityName.

Is tmSessionID specific to a transport model? I think so. If I have an
SSH Transport model and a TLS transport model, can they both generate
the same tmSessionID? RFC5590 requires the tmState to include the
tmTransportDomain (and hence the transport model identifier) and the
tmSessionID. per RFC5590, the tmSessionID "is only ever used by the
Transport Model, so the format and interpretation of this field are
model-specific and implementation-dependent." So I think the
tmSessionID is only unique within a transport model
(tmTransportDomain). It really wasn't designed to be used outside the
cache/transportModel. Ergo, using tmSessionID in the index without a
corresponding tmTransportDomain may not be viable.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, June 08, 2010 6:06 AM
> To: Dave Harrington
> Cc: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jun 2010 22:27:02 +0200

> understanding of David's comments.

There meanwhile have been a number of comments posted to the
list. Randy, do you plan to post an updated version?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Jun 2010 14:38:33 -0700

Hi -

I've made edits corresponding to all of David Nelson's comments.  An updated
I-D should soon appear.

Randy

> From: "David B. Nelson" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 03, 2010 11:58 AM

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Jun 2010 14:42:55 -0700

Hi -

Ok,  I've made corresponding changes.  An updated I-D
should appear shortly.

Randy

----- Original Message ----- 
From: "Donati Andrew-MGIA0477" <[email-masked]>
To: "David B. Nelson" <[email-masked]>; "Randy Presuhn" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 03, 2010 2:28 PM
Subject: RE: [Isms] Attempt at addressing DBH's comments

Hi,

Section 7.2.1

Current implementation:

- Andy Donati

4.2.  Applicability

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 26 Jun 2010 00:42:34 -0700

Hi -

Ok, I've applied most of the edits suggested.
I've commented below on those few cases where I
think what I've done differs in a  significant
way from what David suggested. 

Updated I-D should soon appear.

> From: "David B Harrington" <[email-masked]>
> To: "'Juergen Schoenwaelder'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 08, 2010 2:25 PM

>    compute dynamic updates to VACM.  How this information is

ok

>       be transforned into an equivalent principal identifier in a

ok

>    policies such as the RADIUS Management-Policy-Id attribute

ok

> have the PDU fail if the authorization is revoked during processing.

Ok, though I used different words.  There are several possible
approaches, and the question is just how much need there is to
nail down implementations in this edge case (a session is torn
down while a request is being processed).  The new words actually
permit more variation among implementations than what I had,
but I don't feel any need to push for uniformity here. 
 
>    o  extVacmSecurityName = the securityName that will be used with

ok

>    in which this occurs is implementation dependent.

ok
  
>    no special processing is required in this case.

I KEPT the sentence "Any matching entries are deleted."
Without that sentence, the procedure will not function correctly.
 
> sessionID descriptions as well.

ok
 
> you always need to identify the securityModel associated with a

that's why it's there (as well be being needed to find the right
entries in VACM)
 
> corresponding tmTransportDomain may not be viable.

Sooooooo (and this affects some of the above edits) Here's what I
did on this one:
    - added a  extVacmTransportModel INDEX to the table
    - I gave it a SYNTAX of SnmpAdminString, using as the
      value the 1-4 character transport domain prefix from the
       registry defined in RFC 5590.  This seemed slightly
       less awkward than using the corresponding OID.
    - wherever the session ID was mentioned, I added words
      to make it relative to the transport model.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Jun 2010 16:58:35 -0400

Hi,

I don't think I've replied yet.
These proposed changes look good. 

> 
> Ok, though I used different words.  There are several 
> possible approaches, and the question is just how much need 
> there is to nail down implementations in this edge case (a 
> session is torn down while a request is being processed).  
> The new words actually permit more variation among 
> implementations than what I had, but I don't feel any need to 
> push for uniformity here. 

ok.

> Without that sentence, the procedure will not function correctly.

ooh. typo on my part. good catch.
 
> Sooooooo (and this affects some of the above edits) Here's 
> what I did on this one:
good. thanks.

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