Subject: [Isms] FW: New Version Notification for draft-pejaver-isms-kerberos-01

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 25 Oct 2010 19:53:27 +0000

Sorry for the delay. The new revision has been posted. In this revision,
we added Ken Hardaker and Wes Hardaker who are the original SNMP KSM
authors. We also revised the document organization.

This is the link: http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01

We would like to present this in the IETF beijing meeting.

Comments and questions are welcome.

http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01

On 10/25/10 2:26 PM, "IETF I-D Submission Tool" <[email-masked]>
wrote:

>
>A new version of I-D, draft-pejaver-isms-kerberos-01.txt has been
>successfully submitted by Rajaram Pejaver and posted to the IETF
>repository.
>
>Filename:     draft-pejaver-isms-kerberos
>Revision:     01
>Title:         Kerberos Security Model for SNMPv3
>Creation_date:     2010-10-25
>WG ID:         Independent Submission
>Number_of_pages: 20
>
>Abstract:
>This memo describes the use of Kerberos service with Simple Network
>Management Protocol (SNMP) to authenticate users, authorize them to
>access specific MIB objects, and to protect SNMP messages by using
>integrity protection and encryption.  User authorization information
>is securely encapsulated inside the AuthorizationData field in a
>Kerberos ticket.
>                  
>        
>
>
>The IETF Secretariat.
>
>

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Wed, 27 Oct 2010 08:49:11 -0400

Hi,

Here are a few quick comments on draft -01

Section 2.1.  
>This memo defines a Kerberos-based Security Model (KSM) ... for SNMPv3
[RFC3411].  
If using the [RFC3411] designation with SNMP, the term 'architecture'
should probably be included.  The reference to RFC3411 can otherwise be
left out when mentioning SNMP in general. 

>The first security models, USM [RFC3414] and VACM [RFC3415]...
(Others have previously brought up this topic)
The latter is an access control model which can be used within a
security model as discussed in section 2.6.  Are you proposing the use
of VACM or some other access control model to be used within the KSM
security model?

Section 2.4 
>authPriv - with both authentication and privacy...scopedPDU will be
further protected for confidentiality.
'Further protected' could stand for encryption for privacy.  Draft 00
discussed using the PAC (Privilege Attribute Certificate) for defining
encryption requirements.  Perhaps a section can be added discussing an
encryption protocol and the possible use of the PAC if it's still chosen
to be used.

Section 3.4
>securityModel: Must be Kerberos Security Model (KSM).
The KSM security model needs a defined enumeration.  Should this be 4 ?

General comment:
Will if be helpful to define a MIB module for visibility in monitoring
KSM transactions?
Error definitions defined in RFC4120 section 3.2.3 can be used as a
basis for counters.  The following are some examples. 
KRB_AP_ERR_BADKEYVER 
KRB_AP_ERR_NOKEY 
KRB_AP_ERR_BAD_INTEGRITY 
KRB_AP_ERR_BADADDR  
KRB_AP_ERR_SKEW 
KRB_AP_ERR_REPEAT
KRB_AP_ERR_TKT_NYV 
KRB_AP_ERR_TKT_EXPIRED

-- Andy Donati

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lee, Yiu
Sent: Monday, October 25, 2010 3:53 PM
To: [email-masked]
Subject: [Isms] FW: New Version Notification
fordraft-pejaver-isms-kerberos-01

This is the link:

On 10/25/10 2:26 PM, "IETF I-D Submission Tool" <[email-masked]>
wrote:

>integrity protection and encryption.  User authorization information is

>securely encapsulated inside the AuthorizationData field in a Kerberos 
>ticket.
>                  
>        
>
>
>The IETF Secretariat.
>
>

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

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 27 Oct 2010 13:42:38 +0000

In response to Andy Donati:

[AD] Here are a few quick comments on draft -01

Thanks.  Yiu may chime in with his own responses as well.

[AD] If using the [RFC3411] designation with SNMP, the term 'architecture'
[AD] should probably be included.  The reference to RFC3411 can otherwise be
[AD] left out when mentioning SNMP in general. 

Are you suggesting adding the word 'architecture' after SNMPv3?
Pls restate.

[AD] >The first security models, USM [RFC3414] and VACM [RFC3415]...
[AD] (Others have previously brought up this topic)
[AD] The latter is an access control model which can be used within a
[AD] security model as discussed in section 2.6.  Are you proposing the use
[AD] of VACM or some other access control model to be used within the KSM
[AD] security model?

KSM will use VACM as described in the RFC 3415 standard.
VACM, as originally envisioned, had a username -> group mapping that was
implicitly local to each managed device.  Since that is hard to manage on most
large networks, we envision this mapping to be done centrally.
The recent radius-vacm work found a way to deal with this issue and
KSM follows exactly the same path.

[AD] Section 2.4 
[AD] >authPriv - with both authentication and privacy...scopedPDU will be
[AD] further protected for confidentiality.
[AD] 'Further protected' could stand for encryption for privacy.  Draft 00
[AD] discussed using the PAC (Privilege Attribute Certificate) for defining
[AD] encryption requirements.  Perhaps a section can be added discussing an
[AD] encryption protocol and the possible use of the PAC if it's still chosen
[AD] to be used.

Version -01 matured beyond -00 in many ways.  (Or perhaps I did :-)
Yes, the scopedPDU must be encrypted as stated in s4.1.
Kerberos has a prescribed way to encrypt data, and KSM must use that way.

We replaced the term PAC with 'authorization information'.
PAC implies a certificate, which implies a signature, which we don't need.
I was initially imagining more flexible (complicated) encryption requirements.
The correct (simpler) way is to just use securityLevel.

[AD] Section 3.4
[AD] >securityModel: Must be Kerberos Security Model (KSM).
[AD] The KSM security model needs a defined enumeration.  Should this be 4 ?

Don't know yet.  We need a lucky number.

[AD] General comment:
[AD] Will if be helpful to define a MIB module for visibility in monitoring
[AD] KSM transactions?
[AD] Error definitions defined in RFC4120 section 3.2.3 can be used as a
[AD] basis for counters.  The following are some examples. 

Agreed.  TBD in upcoming revisions.

Thanks again.

--raj
Rajaram Pejaver
Comcast

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Wed, 27 Oct 2010 10:10:38 -0400

>>[AD] should probably be included.  The reference to RFC3411 can
otherwise
>>[AD] be left out when mentioning SNMP in general. 

>Are you suggesting adding the word 'architecture' after SNMPv3?

SNMPv3 in the context of the following sentence seems to be referring to
SNMP in general as opposed to the SNMP architecture [RFC3411].

"This memo defines a Kerberos-based Security Model (KSM) that supports
centralized administration of user authentication and authorization
for SNMPv3 [RFC3411]."

Perhaps it can be restated as the following:

"This memo defines a Kerberos-based Security Model (KSM) that supports
centralized administration of user authentication and authorization
for the Simple Network Management Protocol (SNMP)."

-- Andy

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Oct 2010 14:13:21 +0000

Andy,

Thanks for the input. We will rewrite that sentence based on your
suggestion.

Yiu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 16:33:54 +0200

> for the Simple Network Management Protocol (SNMP)."

But it will only work for SNMPv3, so probably being more explicit
about this is not a bad thing.

/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: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Oct 2010 14:37:41 +0000

Agreed and noted. We will revise this in next version.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 27 Oct 2010 11:48:03 -0400

> KSM follows exactly the same path.

Will you be using the same MIB module that was introduced in the AAA-VACM work?  It seems like introducing a similar (or nearly identical) one with a different set of OIDs would be less than optimal.

If you are indeed reusing the mechanisms of the AAA-VACM work, perhaps all you need to do is reference that (pending) RFC and explain the translation of terms in your draft, e.g. what the equivalents of "User-Name" and ""Management-Policy-Id" are in the Kerberos framework.  Duplicating the elements of procedure and MIB module in the KSM document would serve no useful purpose if the mechanism is indeed the same.  Some effort went into word-smithing the AAA-VACM document to make it re-useable for other AAA services, which could certainly include Kerberos.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Oct 2010 16:32:04 +0000

Hi Dave,

We are indeed trying to use the AAA-VACM model. We are still investigating
it. If this is workable, we will suggest some text in the AAA-VACM draft.
Trust me, we don't want to invent a wheel if we don't have to.

Thanks,
Yiu

On 10/27/10 11:48 AM, "David B. Nelson" <[email-masked]> wrote:

>Will you be using the same MIB module that was introduced in the AAA-VACM
>work?  It seems like introducing a similar (or nearly identical) one with
>a different set of OIDs would be less than optimal.
>
>If you are indeed reusing the mechanisms of the AAA-VACM work, perhaps
>all you need to do is reference that (pending) RFC and explain the
>translation of terms in your draft, e.g. what the equivalents of
>"User-Name" and ""Management-Policy-Id" are in the Kerberos framework.
>Duplicating the elements of procedure and MIB module in the KSM document
>would serve no useful purpose if the mechanism is indeed the same.  Some
>effort went into word-smithing the AAA-VACM document to make it
>re-useable for other AAA services, which could certainly include Kerberos.
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Oct 2010 12:32:24 -0700

Hi -

> From: "Lee, Yiu" <[email-masked]>
> To: "David B. Nelson" <[email-masked]>; "Pejaver, Rajaram" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 27, 2010 9:32 AM
> Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01
...
> it. If this is workable, we will suggest some text in the AAA-VACM draft.
...

I asked for input specifically with respect to the Kerberos work quite some
time ago.

The AAA-VACM document is now in the RFC editor queue, so it's
really too late for change proposals.  If you think a change would be
necessary, then I guess the path to take would be to add a bis
effort to this WG's charter.

Randy

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Oct 2010 19:37:56 +0000

Hi Randy,

I feel sorry that we missed the train. I guess we can put some text in the
KSM draft. I don't think this will be a very urgent deal.

Thanks,
Yiu

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Oct 2010 02:30:29 -0400

Hi,

The RFC3411 architecture and the 5590 update are very specific about
which subsystem has knowledge of what data. The ASIs identify the
expected input/output and processing of each subsystem (and specific
models within those subsystems).
If you are developing a model or models to fit into the RFC3411
architecture, you should go study RFC3411 (and 5590) to make sure you
understand the way data flows between subsystems.  
Your current language shows a lack of understanding of the modularity
of the system.
The RFC3411 architecture is hard to master, but you will probably need
to master it to specify a model correctly.

The handling of authentication, authroization of a transport session,
and authorization of data access can be split across different
susbsystems/models. You need to understand how they are handled within
an RFC3411 architecture. The conceptual handling can be very different
than that of Kerberos, and you need to find the correct way to map
them to the conceptual handling of RFC3411-compatible models.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pejaver, Rajaram
> Sent: Wednesday, October 27, 2010 9:43 AM
> To: Donati Andrew-MGIA0477; Lee, Yiu; [email-masked]
> Subject: Re: [Isms] FW: New VersionNotification

---

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Oct 2010 02:30:29 -0400

Hi,

dbh