Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jan 2010 13:26:22 +0100

Hi,

I just took a look at the RADIUS VACM document and here are number of
editorial issues and some more technical comments.

a) I do not like the structure

   1 Introduction
   1.1 General
   2 The Internet-Standard ...
   3 Conventions

   What is the point of having 1.1 if there is no 1.2? I believe a
   more compact organization is this:

   1 Introduction
   1.1 General
   1.2 The Internet-Standard ...
   1.3 Conventions

   This avoids toplevel sections consisting of just one sentence.

b) The first paragraph does not read well as an introduction. It is
   just a list of concepts that exist in SNMP without giving much clue
   why this list is provided or relevant.

c) s/and interacts/and how it interacts/

d) s/RAIDUS/RADIUS/

e) s/imlementation/implementation

f) s/RADIUS client function in the NAS and the SNMP engine in the NAS/
     RADIUS client function and the SNMP engine/

g) s/extendedVacmSecurityToGroupTable/extVacmSecurityToGroupTable/

h) Remove "These rows are dynamically updated from RADIUS
   authorization data." since this has already been stated in the
   sentence before.

i) s/make not update/make no update/

j) s/cab be/can be/

k) Spell out the complete name of 'rowCreatedBy' and 'rowLifetime'.

l) s/secture/secure/

m) s/basedon/based on/

n) s/user-authenticaed/user-authenticated/

o) In 2.A., I assume secureTransportSecurityModel means Transport
   Security Model (TSM). But I like to raise the question whether this
   really should be hard wired. What happens if we eventually have to
   replace TSM with say TSM++?

p) s/row.If/row. If/

q) s/incerment/increment/

r) s/casues/causes/

s) s/rwo/row/

t) The DESCRIPTION of the MODULE-IDENTITY might need adaptation to
   the legal trust boilerplate of the day.

u) I do not understand why we have extVacmSecurityModel,
   extVacmSecurityName, extVacmGroupName,
   extVacmSecurityToGroupStorageType, and extVacmSecurityToGroupStatus
   since the idea is to create a row in the vacmSecurityToGroupTable.

v) In step 2.E, the 'volatile' obviously belongs to the previous line

w) s/exprires/expires/

x) It is unclear what extVacmRowLifetime reports - is this a ticking
   number running backwards until it reaches zero? Or is this the
   absolute value? In that case, the value is relatively meaningless
   unless someone know the time the entry was created. There probably
   should also be a UNITS clause.

y) The security considerations should be added to the open issues list
   since they need to be filled in and there might be text needed
   concerning trust relationships to RADIUS and the interaction with
   statically configured policy.

/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: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 16:58:06 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, January 20, 2010 4:26 AM
> Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt
...

I'd like to thank Juergen for the detailed comments.  It's been a week
now, and no one has objected to any of his proposals.  As editor I
intend to apply the vast majority of his suggestions and put up an
updated i-d.

I will start a new thread for each of those few comments where
I think further discussion is needed before I make corresponding
changes to the document.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 17:30:30 -0800

Hi -

...
...

While I agree with the thrust of the comment, it puts me in a bit of a bind
with respect to the agreement that the document was to be made to look
more like an SNMP / MIB document.  I think the structure Juergen proposes
makes sense, but, unfortunately, that's not what typical MIB documents look like.
Consequently, I'd like either a ruling from the chair or to hear others voice
their opinions before I make the change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 18:52:41 -0800

Hi -

> Subject: [Isms] js review of draft-ietf-isms-radius-vacm-01.txt
...
These are the items where I've tried to apply Juergen's proposals.

>    why this list is provided or relevant.

Ok, I've added some explanatory text.  I agree that the list seems
excessive, and hope that in the next round of comments we can
trim it down.

> c) s/and interacts/and how it interacts/

Fixed.

> d) s/RAIDUS/RADIUS/

Fixed.

> e) s/imlementation/implementation

Fixed.

>      RADIUS client function and the SNMP engine/

Fixed.

> g) s/extendedVacmSecurityToGroupTable/extVacmSecurityToGroupTable/

Fixed.
 
>    authorization data." since this has already been stated in the

Fixed.

> i) s/make not update/make no update/

Fixed.

> j) s/cab be/can be/

Fixed.

> k) Spell out the complete name of 'rowCreatedBy' and 'rowLifetime'.

Fixed.
Also replaced "radiusextVacmRowLifetime" with "extVacmRowLifetime"
 
> l) s/secture/secure/

Fixed.

> m) s/basedon/based on/

Fixed.

> n) s/user-authenticaed/user-authenticated/

Fixed.

...
> p) s/row.If/row. If/

Fixed.

> q) s/incerment/increment/

Fixed.
 
> r) s/casues/causes/

Fixed.

> s) s/rwo/row/

Fixed.

...
> v) In step 2.E, the 'volatile' obviously belongs to the previous line

Fixed.

> w) s/exprires/expires/

Fixed.

>    should also be a UNITS clause.

Agreed.   I've added what I hope are reasonable words.

>    statically configured policy.

Agreed, added.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 19:02:40 -0800

Hi -

...
...

I think that's the intent.

As a technical contributor, I'd suggest that it should simply use
the value of SnmpSecurityModel that was registered with the
security model in use, rather than specifying the exact value here.
For the reason you describe, I'd prefer to treat TSM as an example,
rather than a normative requirement, throughout this document.
I don't think that doing so would significantly impact the complexity
of this document or of implementations, and would certainly make
it easier to  apply this specification in other contexts.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 19:15:38 -0800

Hi -

...
...

Agreed.  Does anyone know what the correct incantation is now?

The section of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
spelling out what needs to be included in IETF documents leaves me
no wiser than before.  Is there a URL that will always point to the current
sequence of bits that will appease the lawyers?  I think one possible
reading of the TLP document is that since we consider a MIB module
"code", it's automatically covered by the relevant sections of the TLP.
But is such a reading correct?

For the meantime, this has been added to the issues list.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Jan 2010 20:21:06 -0800

Hi -

...
...

Agreed.

The details of what we can get rid of, however, depend on some details
of the use cases we want to support.  I think key questions are:

   (1) does the user->group mapping supplied by RADIUS apply
         (a) only to the specific security model that triggered the retrieval
         (b) only to a specific security model idenitified in the data from RADIUS
         (c) to a *set* of security models identified in the data from RADIUS
         (d) to all security models supported by the implementation

  (2) when a new mapping arriving from RADIUS refers to a (vacmSecurityModel,
        vacmSecurityName) pair for which an entry already exists in the 
        vacmSecurityToGroupTable, do we
        (a) ignore it, and honor the administratively configured settings
        (b) apply the new mapping, and revert to the old one upon expiration
        (c) replace the administratively configured settings with the new mapping

  (3) does it make sense for data delivered by RADIUS to be made
        persistent / nonvolatile?

  (4) Do we provide a way to administratively purge RADIUS-provided data?
        (e.g., force immediate expiration / cleanup of created entries)

  (5) how is the lifetime of information from RADIUS-land managed?
        (a) a lifetime is provided by RADIUS, clean up on expiry
        (b) lifetime is that of corresponding connection(s), clean up
              on termination of last connection using an entry

   (6) how much of the internal processing do we need/want to make
         externally visible?

The answers strongly affect what the tables would look like.
For example, my answers would be
  1: a -or- b,
  2: a,
  3: no,
  4: yes (but I'm not adamant),
  5: b (only because I think the behaviour is non-surprising and very
      easy to implement; I'm not adamantly opposed to a),
  6: very little - I prefer to expose things only when there's a clear
      use case for them being expose via a management interface

With those answers, we'd only need a table indexed by
vacmSecurityModel and vacmSecurityName, and perhaps
by extVacmTransportSessionID if we want to make that
aspect visible, and extVacmSecurityToGroupStatus
to permit administrative termination of a specific entry.

extVacmGroupName is redundant, and I think it leads our thinking down
the path of having RADIUS-supplied entries *temporarily* override
administratively configured VACM policies.  I think such an approach
seriously violates the principle of least surprise.  If a policy has been administratively
configured for a system, I doubt that having dynamic RADIUS data overide
that configuration would be a good thing.  (Though I'm sure answers
will vary depending on how folks feel about question #1)

I think extVacmSecurityToGroupStorageType should be eliminated.
I think having RADIUS-supplied stuff indefinitely surviving reboots/
power outages would be a very bad thing.

I think extVacmSecurityToGroupStatus is only useful for providing
a way for an administrator to kill a specific entry.  I could easily be
convinced that that is not needed, especially if we provided a "clear
the extVacmSecurityToGroupTable" button.

I think we don't need extVacmRowCreatedBy, unless we get really
wild in our answers to (1).

The utility of extVacmRowLifetime depends on the answer to (5) above.

extVacmTransportSessionID makes sense to me only if (a) folks like
to see reference-counting in action if entry lifetimes correspond to session
lifetimes.  If used as an index (and it would have to be, to be useful) it would
work against using extVacmSecurityToGroupStatus as some kind of
single-session policy kill switch, since another entry having the same
model and user would be enough to maintain the group mapping.

It probably would be nice to have a extVacmEnable switch, in order
to enable/disable/shutdown the extension.

As I see it, extVacmSecurityToGroup just needs to be indexed by
security model, user, and perhaps sessionid,
depending on how we want to handle row lifetimes when
there are multiple sessions belonging to the same user / security
model combination.

Anyway, all the above means I agree with Juergen's point, but the
edits will depend heavily on the details we agree to.

Randy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 29 Jan 2010 11:57:50 +0100

Randy

Try the attached e-mail from Jorge to the IETF list in December last.

A new Trust Legal Provisions has come out since then but it, like all of them
and unlike RFC3978, does not include any section on Legends to be Included in
Code Components in an IETF Document.

Perhaps we need to revise the Trust Legal Provisions (again:-).

Tom Petch

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 29, 2010 4:15 AM
Subject: [Isms] JSt: legalese for embedding in MIB modules

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

Subject: need advice on reproducing code (Relax NG) from RFC 4287 (The Atom Syndication Format)
From: Jorge Contreras <[email-masked]>
To: [email-masked], [email-masked], Olaf Kolkman <[email-masked]>
Date: Mon, 21 Dec 2009 19:55:49 -0500
List-Id: IETF-Discussion <ietf.ietf.org>

Julian -- your understanding is consistent with mine.  That seems to be the
right legend.
Regards,
Jorge
 ------------------------------

   - *From*: Julian Reschke <julian.reschke at
gmx.de<[email-masked]>>

   - *To*: IETF Discussion <ietf at ietf.org <[email-masked]>>
   - *Cc*: Paul Hoffman / IMC <phoffman at imc.org <[email-masked]>>

   - *Date*: Sun, 20 Dec 2009 19:53:07 +0100

------------------------------

Hi,

the OASIS CMIS TC would like to ship their spec with an XML Schema describing
the Atom feed syntax. That schema can be produced from Appendix B of RFC
4287 using Jim Clark's "trang".

The license for RFC 4287 is defined by BCP 78, of which RFC 3978 was
the current
version when RFC 4287 was published.

Section 5.6 of RFC 3978 has:

-- snip --
   a. in MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

         "Copyright (C) The Internet Society <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      ...

      For other types of components than "MIB", substitute "MIB module"
      with an appropriate identifier.  In the case of MIB and PIB
      modules this statement should be placed in the DESCRIPTION clause
      of the MODULE-IDENTITY macro.

      Variations of these abbreviated notices are not permitted except
      in cases where the material to be extracted is the product of a
      joint development effort between the IETF and another standards
      development organization or is a republication of the work of
      another standards organization.  Such variations must be approved
      on an individual basis by the IAB.
-- snip --

(<http://tools.ietf.org/html/rfc3978#section-5.6>).

Question: does the Relax NG schema qualify as "code component"? It certainly
does according to <
http://trustee.ietf.org/docs/Code-Components-List-4-23-09.txt>, but that's
data from 2009.

Assuming it does qualify as code component, would the following notice on
the extracted Relaxg NG schema be OK?

         "Copyright (C) The Internet Society 2005.  This version of
         this RelaxNG schema is part of RFC 4287; see the RFC itself for
         full legal notices."

Best regards, Julian
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Jan 2010 08:26:31 -0500

+1

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Randy Presuhn
> Sent: Thursday, January 28, 2010 10:03 PM
> To: [email-masked]
> Subject: [Isms] JSo: hard-wire to TSM?
> 
> Hi -
>

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 29 Jan 2010 08:49:40 -0500

> As a technical contributor, I'd suggest that it should simply
> use the value of SnmpSecurityModel that was registered with the

With caveats, that's probably OK.

> For the reason you describe, I'd prefer to treat TSM as an
> example, rather than a normative requirement, throughout this
> document.

Yes, but not all security models have the same security properties.  Given
that the premise of this document is to bind principal identity to access
control policy via an external AAA server, it makes no sense to apply the
mechanism described in this document to non-AAA-aware security models.  I
agree that tying this usage to a *specific* security model is undesirable,
for all the usual SNMP architectural modularity reasons.  However, I think
there is a normative requirement to tie it to a *class* of security models
that embrace principal authentication via AAA services, such as RADIUS.
Otherwise, I feel we will create a significant security risk.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Jan 2010 08:57:32 -0500

Hi,

I agree the 1.1 numbering and indent is not needed; just promote it to
1.
So you should have:
1.  Introduction
2.  The Internet-Standard Management Framework 
3.  Conventions
4.  Overview

RFC4181 (BCP 111) only says that the MIB boilerplate must be included.
RFC5249 (BCP 139) points to the MIB document templates at
tools.ietf.org. 
The templates show:
--start--
1.  Introduction

   This memo defines a portion of the Management Information Base
(MIB)
   for use with network management protocols.  In particular it
defines
   objects for managing the [TEMPLATE TODO].

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7
of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store,
termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a
MIB
   module that is compliant to the SMIv2, which is described in STD
58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Overview
5.  Structure of the MIB Module
etc.
--end --

dbh

> Sent: Thursday, January 28, 2010 8:31 PM
> To: [email-masked]
> Subject: [Isms] JSa: structure
> 
> Hi -
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jan 2010 16:20:09 +0100

> 5.  Structure of the MIB Module

I personally strongly dislike one sentence top-level sections. And
having this level of document structure prescribed does not really
solve any problem I can think of.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 29 Jan 2010 11:08:00 -0500

On Jan 28, 2010, at 11:21 PM, Randy Presuhn wrote:

>   I think key questions are:
>

It would likely only apply to the security model that triggered the  
retrieval, and certainly would only apply to security models wherein  
the authentication of the principal's identity is obtained via  
RADIUS.  As we are all likely aware, RADIUS doesn't  support the  
separation of authorization from authentication.

>         (b) only to a specific security model idenitified in the  

RADIUS has no way to specifically identify a security model (at least  
via the attributes defined n RFC 5607).

>         (c) to a *set* of security models identified in the data  

Perhaps to a "set" of security models that are known to be RADIUS- 
aware.  There is always the possibility of an inadvertent de-coupling  
of authentication from authorization unless the implementation takes  
some care to keep track of these things, or the system / security  
administrator does so via configuration.

>         (d) to all security models supported by the implementation

I think that would give rise to significant security risks.

>        (a) ignore it, and honor the administratively configured  

Probably yes, on the assumption that the system administrator /  
security administrator intended this local override  I think it is  
important that this increment a counter, as it might equally well be  
the result of a misconfiguration.

>        (b) apply the new mapping, and revert to the old one upon  

That's a reasonable choice in terms of getting the expected behavior  
in a RADIUS environment.  It certainly adds complexity, however.

>        (c) replace the administratively configured settings with the  

I think that would be wrong.

>        persistent / nonvolatile?

No.  I see no valid use case for that approach.

>        (e.g., force immediate expiration / cleanup of created entries)

Umm.. maybe It's called reboot.  :-)  Generally speaking, customers  
will use RADIUS because that's where their user authentication,  
authorization and policy data resides.  I think situations in which  
customer will want to circumvent RADIUS authorization are indeed  
corner cases.  They either use RADIUS in their network infrastructure  
or they don't.  You would need a "back-up" means of AAA, of course,  
for when RADIUS is unreachable, and that might be via USM

>        (a) a lifetime is provided by RADIUS, clean up on expiry

That's what RFC 5607 specifies.

>              on termination of last connection using an entry

If there is a reliable way to determine that the data is no longer in  
use, e;;g. that all "connections" relying on that data have  
terminated, then that might also be considered.

>   (6) how much of the internal processing do we need/want to make

I don't understand.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Jan 2010 11:09:41 -0500

Hi,

I recommend that the current 1.1 General section be the 1. section.
It has more than one sentence.
section 2 has more than one sentence.
section 3 is the only one with a single sentence, but the RFC2119
boilerplate is often in its own section in IETF documents, and the
xml2rfc template published by the EDU team puts this in a separate
section.
section 4 and higher would all have more than one sentence.
So I don't see the issue of one-sentence sections.

BCP 139 went through MIB Doctor and gen-art and secdir reviews, plus
AD, IESG, IETF LC and RFC editor reviews, plus an Alfred Hines review,
and the consensus was to approve the structure used in the template.

I am not promoting this as the best design; nor am I saying it is not
- personally, I don't much care. I am responding to Randy's request
for feedback. As editor, I documented the consensus on the design. The
IETF and its leadership approved this as a BCP.  This is the format
recommended for use in new MIB documents. I think we should have a
solid reason for ignoring the IETF consensus on the BCP, especially
since many of us are recognized as leaders in the MIB domain.

I don't see that your opinion represents the IETF consensus. But
you're the chair, and if you want to impose your personal preference
over the consensus of the rest of the IETF, I suppose that's in your
power.  

I just don't really see an issue here, myself.

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, January 29, 2010 10:20 AM
> To: David Harrington
> Cc: 'Randy Presuhn'; [email-masked]
> Subject: Re: [Isms] JSa: structure
>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 29 Jan 2010 11:14:26 -0500

> That's what RFC 5607 specifies.

Actually, I think this in in RFC 5608 [as well].

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 11:37:04 -0800

Hi -

> From: "tom.petch" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "isms" <[email-masked]>
> Sent: Friday, January 29, 2010 2:57 AM
> Subject: Re: [Isms] JSt: legalese for embedding in MIB modules
...
> Try the attached e-mail from Jorge to the IETF list in December last.

Current text is:
                  Copyright (C) The Internet Society (2009)."

Is the proposal to make it say this?
                  Copyright (C) The Internet Society 2010.  This version of
                  this MIB module is part of RFC XXXX; see the RFC itself for
                  full legal notices."

> Perhaps we need to revise the Trust Legal Provisions (again:-).

But not here, please!

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Jan 2010 11:38:58 -0800

>>>>> On Fri, 29 Jan 2010 11:37:04 -0800, "Randy Presuhn" <[email-masked]> said:

RP> Is the proposal to make it say this?
RP> Copyright (C) The Internet Society 2010.  This version of
RP> this MIB module is part of RFC XXXX; see the RFC itself for
RP> full legal notices."

The wording I was told (by Juergen) was the right wording for the top of
the MIB was the following for the DTLS draft:

        Copyright (c) FILLYEAR IETF Trust and the persons identified as
        the document authors.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        This version of this MIB module is part of RFC XXXX;
        see the RFC itself for full legal notices."

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 11:52:56 -0800

Hi -

Ok, unless someone objects, I'll use the incantation Wes provided.

Randy

> From: "Wes Hardaker" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "isms" <[email-masked]>
> Sent: Friday, January 29, 2010 11:38 AM
> Subject: Re: JSt: legalese for embedding in MIB modules
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 14:33:43 -0800

Hi -

While I very much agree with Juergen's point about excessive number
of "top level" sections, I don't think this is the place to try to change
MIB document practice.  (The complete lack of comments on
draft-presuhn-opsawg-rfc4181bis-03.txt suggests that there is
no groundswell of support for revisiting the issue.)

So, here's what I intend to do as editor: collapse the current 1.1
into section 1. 

Randy

----- Original Message ----- 
> From: "David Harrington" <[email-masked]>
> To: "'Juergen Schoenwaelder'" <[email-masked]>
> Cc: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Friday, January 29, 2010 8:09 AM
> Subject: RE: [Isms] JSa: structure
>
> Hi,
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 14:53:55 -0800

Hi -

Ok,  using some of Dave's words, I'll update the procedural text to
say:

   The value used for vacmSecurityModel is the registered value for
   the security model in use.
   Note that the security model SHOULD be one
   which binds principal identity to access control policy via an
   external AAA server, such as the Transport Security Model.  To
   do otherwise potentially creates a security risk.

I think SHOULD ("if you don't do this, you should have a really really good
reason") is appropriate.  I could be persuaded to say MUST, but I think
that is overkill.  (I could imagine using a service that didn't use an external
AAA server without introducing additional risk.)

Randy

----- Original Message ----- 
> From: "Dave Nelson" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, January 29, 2010 5:49 AM
> Subject: Re: [Isms] JSo: hard-wire to TSM?
>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 29 Jan 2010 18:10:07 -0500

> AAA server without introducing additional risk.)

Could you elaborate on such a use case?

It's true that the mechanisms described in this document could be used  
with something other than RADIUS (or another AAA) to dynamically  
provision access control policy for specific principals.  It seems to  
me, however, that unless that other "something" has a a very solid  
basis to know that principal "foo" as identified via the access  
control system ASI is the same "foo" as has been mapped in the VACM  
tables, there exists the risk of one "foo" impersonating another.  In  
other words, in order to assure that the proper access rights are  
being conferred, it is necessary for the "binding" of the two  
instances of identity to be secure.  That might be obtained in a very  
controlled environment, without making the restriction that the same  
AAA service is involved in the authentication and authorization  
phases, but that seems to be a very special case indeed.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 15:54:49 -0800

Hi -

A few second-level questions emerge, based on these answers.

> From: "David B. Nelson" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, January 29, 2010 8:08 AM
> Subject: Re: [Isms] JSu: table simplification
....
> >         (a) only to the specific security model that triggered the  

It sounds like we're agreed on this as the path for now.
I think this means we can get rid of extVacmRowCreatedBy,
because its redundant with respect to extVacmSecurityModel,
which is redundant with respect to vacmSecurityModel.

> the result of a misconfiguration.

Ok.  For now, let's go with choice (a).  That reduces the need for
extVacmSecurityToGroupStatus.

Making the counter *useful* would be a bit tougher.
A scalar won't tell us which securityModel / securityName pair is
having trouble - the security administrator would have to scan the
vacmSecurityToGroupTable to find possible conflicts.  If we're
really worried about this case, a notification might make more
sense than a counter.  (Though perhaps pathological if the session
in question is one for carrying outbound notifications.  :-)

I'm not convinced that the counters we currently have would
really be terribly useful, even though I do agree that being
able to know when this situation is occurring is important.

...
> No.  I see no valid use case for that approach.

Ok, we can eliminate  extVacmSecurityToGroupStorageType.
 
> for when RADIUS is unreachable, and that might be via USM

Ok, then we can eliminate extVacmSecurityToGroupStatus.

> >   (6) how much of the internal processing do we need/want to make

(5) and (6) go together.  The only reason I can see for making
extVacmTransportSessionID visible would be as an index
as part of a (5b) strategy.  If we go with (5a), AND if we
update extVacmRowLifetime whenever (for this
user/model combination) a Lifetime value arrives which is
greater than the current one, then we can eliminate
extVacmTransportSessionID.

I think I understand the edits.  :-)  Should I go ahead and
post an update?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Jan 2010 16:04:49 -0800

Hi -

> Sent: Friday, January 29, 2010 3:10 PM

I think we're in agreement.  The existence of such a use case,
no matter how razor-thin, makes the absolute "MUST" problematic.
The person who'd be concerned about the SHOULD/MUST
distinction here would be someone developing another security model.
Though health warnings are often appropriate in cases like this,
I'm happy with the implicit warning that comes with every SHOULD.
But if you'd like to supply some more explicit health warnings to
go along with the SHOULD, I'd be happy to include them.

Randy