Subject: [Isms] ISMS charter discussion

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Aug 2005 12:57:04 +0200

Dear all,

In order to make progress concerning the charter, I suggest we agree
on an outline in form of bullet items first and discuss elaborated
text after we have consensus on the bullets.

Below please find a summary of the recent charter discussion.
Please note that the discussion assumes that the WG will achieve
consensus on using SSH for transport.

Items with questions marks were discussed without a clear result
so far.

Comments are highly appreciated, particularly if they constructively
suggest concrete text modifications, such as replace bullet item A
by bullet item B or replace text "..." by text ",,,".

Thanks,

    Juergen

-----------------------
ISMS WG charter outline
-----------------------

Background
  - USM has limited deployment
  - no standard for integrating key and user management into
    deployed authentication infrastructures
  - SSH is widely deployed
  - SSH integration into AAA, e.g., Redius, is available

WG goals
  - define a new SNMP security model that utilzes the SSH protocol
    to provide message security services for SNMP
  - compliancy with SNMPv3, no modification of SNMPv3
  - work on new access control models and VACM mappings out of scope
  - open to further transport mappings, such as BEEP, TLS, ...
  ? mentions session concept ?
  ? mention user->group mapping via AAA ?
  ? authenticate user or command generator ?

Work Items:
  - specify how transport mapping security models (TMSMs)
    fit into the SNMPv3 architecture
  - specify RADIUS attributes used to populate
    securityname and other SNMP parameters
  - define how to use SSH between the two snmp engines
  - specify the SSH security model for SNMP

Documents
  - A document that specifies how transport mapping security models
    (TMSMs) fit into the SNMPv3 architecture and which defines the
    requirements for transport mapping security models.
  - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?)
  - A document specifying the SSH security model for SNMP.
    This specification must comply with the TMSM requirements.
  - An Applicability statement that sets up reasonable mandatory to
    implement methods.
  ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it
    with the SSH transport model (or move RFC 3430 to historic) ?

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 19 Aug 2005 12:59:02 +0200

Inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Juergen Quittek
> Sent: Friday, August 19, 2005 10:19
> To: [email-masked]
> Subject: RE: [Isms] ISMS charter discussion
> 
> 
> Dear all,
> 
> Please have a look at the outline of our new charter.
> You will find the current outline below.
> 
> Particularly, I would like you to express your opinion about
> 
>   - explicitly mentioning securityName and securityGroup

We do have a concept of "securityName" in SNMPv3.
So mentioning that is fine.

We do not have the concept of "securityGroup" in SNMPv3 (I did 
not recal we have one, but a "grep securityGroup RFC341*"
also does not find a hit.
I guess what you mean is that you want to be able to map
the SSH credentials (not sure I use the right term here)
into a groupName (this term is used in SNMP documents).

In SNMP we control access based on the groupName or the "who"
(among otehr things). See RFC3415 page 8.

In the case of USM we use the securityModel (USM) and the
userName in the msgSecurityParameters (securityModel-specific
parameters inside a SNMPv3 Message) which gets mapped (1-1)
into the security-model-independent securityName.
The securityModel and securityName are used to map to a
groupName, which is then one of the keys to find out
if access can be granted.

If the securityModel is gonna be (for example) 
SSM (SSH-based Security Model), then we have the securityModel.
We then need to decide how we map the SSH identity (correct term)
into a securityName. Once we have those two, I think it is
a matter of populating an entry (entries) in the 
vacmSecurityToGroupTable and bingo, we're all set.

So for me, it seems we can explicitly mention securityName
but for me it seems that the securityModel and securityName
should map (via vacmSecurityToGroupTable) into a groupName.

Or have I missed some discussion as to why this would
be done in a different way (which then in my view is
not compliant with the SNMPv3 architecture, or at least
it is not yet obvious to me how it would be compliant).

>   - having a revision RFC 3430 as one of our work items
> 

RFC3430 is experimental.
I'd say that once we have completed our initial work, we
could then see if we have time/energy to update 3430 or
just declare it HISTORIC. I would not worry too much
about it at this point in time.

More below

> Ken and I will turn the outline into a text version and post
> it on Monday.  Then we will have next week for discussing wordings.
> 
> Thanks,
> 
>     Juergen
> 
> -----------------------
> ISMS WG charter outline
> -----------------------
> 
> Background
>   - SSH integration into AAA, e.g., RADIUS, is available
> 
> WG goals
>   - compliancy with SNMPv3 architecture, no modification of SNMPv3
>     (except for mapping via securityName or securityGroup)
I would move this to the end of this list (i.e. list the things 
that are in-scope first). May I suggest rewording into

    - work on new access control models and new VACM mappings out of scope
      (except for mapping from SSH identity into securityName, which
       together with the new securityModel will map into the VACM
       groupName)

>   - open to further transport mappings, such as BEEP, TLS, ...

I would move this to position it as the last item of in-scope work items
I am also not sure about the wording. It makes the WG charter pretty
much open ended and so it can bite us back since it opens us up for
all sorts of ideas to come to our WG. We were going to try and come to
a focused WG charter that we can finish in a reasonable amount of 
time. Once we finish it we can entertain the idea of 
"close WG or recharter" and so the at that time we'd be "open to 
consider to charter additional transport mappings". 
If the WG decides now that they want to add (at lower priority in my view)
an additional (optional) mapping onto BEEP, then I could live with that,
but let us not list several (and certainly not "...." that makes it
far too open ended).

>   - following a session-based approach
>   - define a standard method for mapping from AAA-provisioned
>     authorization parameter(s) to SNMP securityName and securityGroup
> 
> Work Items:

As far as I know, the RADEXT WG has an overloaded plate already.
I have seen at least one RADEXT WG chair participate in these
discussions, so maybe he can estimate how much room/energy that
WG has to work on this. 
So I would rather keep it in ISMS and instead change
"(in RADEXT WG?)" into "(in consultancy with RADEXT WG)" or
some such.

>   ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it

See my comment on 3430 above

Bert

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 19 Aug 2005 10:58:31 -0400

Bert Wijnen writes...

> We do not have the concept of "securityGroup" in SNMPv3 ...

So I've clearly picked up an incorrect term from another thread in on
this list.

> (among other things). See RFC3415 page 8.

I believe I should have said groupName.  The intent was to re-use an
existing mechanism.

> if access can be granted.

I am suggesting, however, that we allow the AAA-provisioned
authorization attributes to map into groupName.  That may require a
modification to the API between the access control module and the
security module.  It would certainly not affect the SNMP over-the-wire
protocol definition.

> vacmSecurityToGroupTable and bingo, we're all set.

I agree that operators will continue to populate the VACM table as they
do (or do not) today.  Today the mapping from securityName to groupName
is stored in the local non-volatile storage of the managed entity.  I
think that constitutes an impediment to deployment and a scalability
issue that ISMS needs to address.

It seems to me that are three choices:

(a) In practice, the securityName will be limited to a small number of
values that describe roles within and organization structure (e.g.
help-desk, network-admin), and not individual identities (e.g. dnelson).
Then, securityName can that be a simple 1:1 mapping into groupName
(perhaps the equality mapping).

(b) The mapping between securityName and groupName remains to be
provisioned as it is done today.

(c) We allow the AAA server to provision the groupName, centralizing the
mapping of securityName to groupName in the AAA server, along with other
access rights information.

I think that (a) is simple, but has the potential disadvantage of losing
the individual identity of the user (or command generator).  It may be
interesting to keep that for auditing purposes, e.g. syslog.

I think that (b) perpetuates an impediment to deployment.

I think that (c) is almost a simple as (a) and is the best choice.