Subject: Re: [Isms] status and future of the isms working group

From: "t.petch" <[email-masked]>
Date: Fri, 1 Oct 2010 09:39:01 +0200

Just a final thought, a restatement of the problem I see, lest it not yet be
clear to some.

The currently defined secure Transport Models require tmStateReference to be
set, else a Command Responder does not know where to send a Response.  The 'UDP
Transport Model' is undefined, and so tmStateReference must, I think, be
indeterminate.  A new Security Model, XSM, which wants to be Transport Model
independent has a challenge; it must set tmStateReference, to work with secure
Transport Models, and ignore it, to work with UTM, without knowing what
Transport Model is in use.  I see this as problematic.

This issue arose with RFC5591 and was found by (me) working through the section
fives (and fours) to check what information was available to what when.  So any
I-D for a new, XSM which lacks a section five will need one creating to
establish whether or not it works with existing models.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "isms" <[email-masked]>; "Lee, Yiu" <[email-masked]>
Sent: Wednesday, September 29, 2010 8:47 PM
Subject: Re: status and future of the isms working group

> >>>>> On Wed, 29 Sep 2010 18:47:07 +0200, "t.petch" <[email-masked]>
said:
>
> tp> I am saying that at the least, a KSM I-D has to parallel RFC5591
> tp> (not USM), covering all the topics that that covers.  It will
> tp> probably specify that all the additional parameters introduced by
> tp> RFC5590 are ignored, but if it says anything else, then I think we
> tp> will need a UDP Transport Model.
>
> Sounds like a one bullet incoming request saying "ignore the
> tmStateReference" solves all your problems then.  (and the outgoing
> doesn't need anything since by not creating a tmStateReference on the
> outgoing path, you're already ignoring it).
>
> tp> And then there are the interactions with Kerberos; shades of VACM
> tp> and RADIUS perhaps, in that the Command Responder is setting up a
> tp> connection(/session/transport) to a third party, which needs
> tp> specifying?
>
> I think I'll stop suggesting solutions as we haven't agreed to do the
> work.  That being said, all of the above have already been accomplished
> by two independent sets of folks so I know they can be worked out.
> --
> Wes Hardaker
> Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Oct 2010 11:19:06 +0200

On Fri, Oct 01, 2010 at 09:39:01AM +0200, t.petch wrote:
> The currently defined secure Transport Models require
> tmStateReference to be set, else a Command Responder does not know
> where to send a Response.  The 'UDP Transport Model' is undefined,
> and so tmStateReference must, I think, be indeterminate.  A new
> Security Model, XSM, which wants to be Transport Model independent
> has a challenge; it must set tmStateReference, to work with secure
> Transport Models, and ignore it, to work with UTM, without knowing
> what Transport Model is in use.  I see this as problematic.

As far as I understand things, we have two types of security models -
those that outsource the security processing to a secure transport
model (i.e. TSM) and those that don't because the provide security
services within the security model itself (i.e. USM and CSM). I am not
sure how useful a security model will be that combines both types. For
the sake of this discussion, I believe people what a kerberos security
model (lets call it KSM) that does security processing within the
security model, so it falls into the same class as USM and CSM.

So even if there would be a problem, it will not be any worse than
what we have with USM and CSM.

> This issue arose with RFC5591 and was found by (me) working through
> the section fives (and fours) to check what information was
> available to what when.  So any I-D for a new, XSM which lacks a
> section five will need one creating to establish whether or not it
> works with existing models.

I still do not see where the problem is. For a secure transport model,
the tmStateReference needs to be available. For other transports, I
believe you can ignore it.

/js

PS: The SNMP code I have seen always knows how to send a response back
    to where the request came from. The RFC3411 architecture decoupled
    things to a very large degree while most implementations are much
    tighter integrated.

-- 
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: Fri, 1 Oct 2010 11:31:52 +0200

On Wed, Sep 29, 2010 at 03:13:17PM +0200, Yiu L. Lee wrote:

> Raj and I will continue to work hard to make sure to address all the
> questions and issues in the mailing list. Please don't stop giving
> us feedback!

Section 3.2 talks about the PAC and I think some discussion is needed
how that relates to SNMP's notion of a securityLevel and any other
information that goes into the isAccessAllowed() ASI.

I also like to better understand the structure of the resulting
exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP
are the exchange to establish a Kerberos session key. My reading of
the ID is that you are not really interested in the session key but
you only want to use it for a single SNMP request/response
interaction. If my reading is correct, I would like to know what
Kerberos people think about such an approach. I would also like to
know the crypto performance impact of this if you have to walk a
longer table using multiple SNMP request/response interactions.

I am also missing a discussion how unconfirmed notifications (traps)
are handled.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 Oct 2010 09:15:22 -0400

I concur.

You need security parameters (security name, security level, etc.)
established between two SNMP security model instances, and currently
can do that 
1) by including the information in the SNMP message, so a
message-aware security model can generate the security parameters
itself (USM, CSM) or 
2) getting information from a security-providing transport (SSH, TLS),
having a transport-security-aware transport model algothmically
convert the transport security parameters into SNMP security
parameters in tmStateReference form, and passing them to a
transport-security-aware (tmStateReference-aware) SNMP security model.

I haven't studied the KSM(?) proposal to see whether the data will be
passed through a tmStateReference or in the message itself. 

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Friday, October 01, 2010 5:19 AM
> To: t.petch
> Cc: isms; Lee, Yiu
> Subject: Re: [Isms] status and future of the isms working group
> 
> > Just a final thought, a restatement of the problem I see, 
> lest it not 
> > yet be clear to some.
> > 
> tmStateReference 
> > to be set, else a Command Responder does not know where to send a 
> > Response.  The 'UDP Transport Model' is undefined, and so 
> > tmStateReference must, I think, be indeterminate.  A new Security 
> > Model, XSM, which wants to be Transport Model independent has a 
> > challenge; it must set tmStateReference, to work with 
> secure Transport 
> > Models, and ignore it, to work with UTM, without knowing what 
> As far as I understand things, we have two types of security 
> models - those that outsource the security processing to a 
> secure transport model (i.e. TSM) and those that don't 
> because the provide security services within the security 
> model itself (i.e. USM and CSM). I am not sure how useful a 
> security model will be that combines both types. For the sake 
> of this discussion, I believe people what a kerberos security 
> model (lets call it KSM) that does security processing within 
> the security model, so it falls into the same class as USM and CSM.
> 
> So even if there would be a problem, it will not be any worse 
> than what we have with USM and CSM.
> 
> available 
> > to what when.  So any I-D for a new, XSM which lacks a section
five 
> > will need one creating to establish whether or not it works with 
> > existing models.
> 
> I still do not see where the problem is. For a secure 
> transport model, the tmStateReference needs to be available. 
> For other transports, I believe you can ignore it.
> 
> /js
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 1 Oct 2010 12:50:40 -0400

Section 2 in http://datatracker.ietf.org/doc/rfc5590/ presents a good
discussion on using either of these approaches.

An important question to consider is which method will be the easiest
for operators to implement.  If operators can easily leverage their
existing Kerberos infrastructure using the approach described in item 1,
it can certainly be considered a viable option. 

-- Andy Donati

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Harrington
Sent: Friday, October 01, 2010 9:15 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'isms'; 'Lee, Yiu'
Subject: Re: [Isms] status and future of the isms working group

can do that
> 1) by including the information in the SNMP message, so a
message-aware security
> model can generate the security parameters itself (USM, CSM) or
having
> a transport-security-aware transport model algothmically convert the
transport
> security parameters into SNMP security parameters in tmStateReference
form,
> and passing them to a transport-security-aware
(tmStateReference-aware) SNMP security model.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 01 Oct 2010 17:03:14 -0400

> longer table using multiple SNMP request/response interactions.

I haven't read this document yet, so I can't comment on its use of 
Kerberos.  However, if the WG decides to adopt the work, I'll be happy to 
review it with that in mind.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Oct 2010 23:30:57 +0200

> review it with that in mind.

Jeff,

it might help us and the authors to get some early feedback whether
the approach itself is leading into the right direction. So if you
have some time available now... The core of the proposal is section 3,
about 3 pages of text to read:

      draft-pejaver-ismi-kerberos-00

(The name is confusing since they misspelled isms.)

/js

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 1 Oct 2010 17:37:21 -0400

Sorry for mis-spelled the WG name. We will fix it in next revision. We are working on the new revision which tries to capture all the questions posting on the list. Mostly importantly, we would like to listen to the group and make sure we are heading to the right direction.

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Mon, 4 Oct 2010 14:38:20 -0400

> information that goes into the isAccessAllowed() ASI.

The PAC can be thought of as having exactly the same syntax & semantics
as the role information retrieved from RADIUS in
draft-ietf-isms-radius-vacm.
The managed device should handle it in exactly the same way.
I called it a PAC only because of where it is placed in the Kerberos
ticket.
It probably comes from RADIUS, though it takes a different path:
  - in draft-ietf-isms-radius-vacm, RADIUS delivers this directly to the

    managed device.
  - in the proposed ID, RADIUS delivers it to Kerberos, which
encapsulates
    it securely in a ticket, which is given to the NMS, who presents it
to
    the managed device.

The semantics of securityLevel should remain unchanged:
  - authNoPriv = PDU not encrypted
  - authPriv = PDU is encrypted

All this should be explained better in the next revision of the ID.

> longer table using multiple SNMP request/response interactions.

We are interested in the session key as it is needed to encrypt the SNMP
PDU.
The same ticket+sessionkey will be used if there are multiple SNMP
interactions
between the NMS (Manager) & the managed device.

> I am also missing a discussion how unconfirmed notifications (traps)

If the managed device needs to send traps securely, it would need to
get a Kerberos ticket and a session key for each destination NMS
(typically
one).  This can be done when the device initializes.

Thanks for your comments.  We will incorporate all the questions and
suggestions
into the next version of the draft.  

Regards

Rajaram Pejaver

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Oct 2010 21:41:36 +0200

> All this should be explained better in the next revision of the ID.

The text needs to be more concrete and precise. Right now, the text in
3.2 consists of an acronym (PAC) and it says that "its structure and
semantics may vary depending on the authorization model of the managed
device". SNMP has a very clear authorization model so it should not be
hard to be precise.
 
> between the NMS (Manager) & the managed device.

So do you establish session state? To me, it seems you do not but
instead you pull the session key out of the ticket in each
request/reply interaction. If my understanding is correct, I like to
hear from Kerberos people whether they think this is a good approach.

> (typically one).  This can be done when the device initializes.
> 
> suggestions into the next version of the draft.

I am looking forward to the next revision. Please be reminded of the
upcoming deadlines:

2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00)
	   	     submission by 17:00 PT (24:00 UTC)

2010-10-25 (Monday): Internet Draft final submission cut-off
	   	     by 17:00 PT (24:00 UTC)

/js

---

From: "Yiu L. Lee" <[email-masked]>
Date: Mon, 4 Oct 2010 15:44:08 -0400

Hi Juergen,

Thanks for the date reminder. I will submit the old one with the right WG
name. Then we will submit the revision sometime next week.

Thanks,
Yiu