Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM

From: "David Harrington" <[email-masked]>
Date: Tue, 5 Feb 2008 16:37:08 -0500

Hi,

RFC3412 forces a binding to exist between the message processing model
and the security model, since one provides the parameters for the
other. 

To make transport models work, we needed to modify the architecture to
create a binding mechanism between transport models and security
models, in the form of tmStateReference, since one provides the
parameters for the other. 

We rechartered to permit us to add the tmStateReference to the ASIs,
whatever its content. We did not have to recharter to add the
securityName, and then to recharter again to add the securityLevel,
and then to recharter again to add the sameSession parameter, and so
on. 

The change that is required to allow transport models to select the
corresaponding security model is to provide that an additional
parameter - the securityModel parameter - be added to
tmStateReference. Why must we recharter to add this parameter?

The charter says "The goal of the ISMS working group is developing a
new security model for SNMP that integrates with widely deployed user
and key management systems, as a supplement to the USM security model"
and we are supposed to "- Specify an architectural extension that
describes how transport mapping security models (TMSMs) fit into the
SNMPv3 architecture." 

The charter does not say we are constrained to supporting only
messages in the SNMPv3MessageSyntax. tmStateReference (and the
modified ASIs) is the architectural extension, and part of describing
how transport model security models fit within the architecture would
include how the securityModel parameter is utilized by the subsystems
that get the tmStateReference.  We are not trying to change any other
aspect of the SNMP architecture (e.g. PDUs). 

dbh

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, February 05, 2008 2:25 PM
> To: David Harrington; [email-masked]
> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for
ACM
> 
> My issues are actually not technical, nor am I in favor of sticking
at
> any price to architectural purity if deployment realities ask
> differently. I cannot convince myself however that binding 
> the security
> model for SNMPv2c is within the current ISMS charter, and I 
> suspect that
> other IESG members will ask the same question. So we either need to
> discuss a re-chartering for this WG or we need to think about 
> making all
> or part of this work Experimental. 
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]] 
> > Sent: Monday, January 28, 2008 11:20 PM
> > To: Romascanu, Dan (Dan); [email-masked]
> > Subject: RE: [Isms] ISMS #8: support of v1/v2c 
> transport-authn for ACM
> > 
> > Hi Dan,
> > 
> > I am curious as to what other issues you do not like in 
> this proposal.
> > 
> > The SNMPv3 architecture was designed to permit various models 
> > to be used together in different combinations. I am trying to 
> > make it possible to use different security models with 
> > different message versions. I think that is very consistent 
> > with the SNMPv3 WG intentions of modularity. 
> > 
> > The one place where the SNMPv3 WG found a need to "bind" 
> > models was between the SNMPv3 message format and the named 
> > security models, because the security parameters that are 
> > needed by the different security models are passed in the 
> > SNMPv3 message header. Unfotunately, we also needed to bind 
> > SNMPv1 and the SNMPv1 security model directly, and the 
> > SNMPv2c message format to the SNMPv2 security model directly, 
> > because the security parameters are extracted from the fields 
> > of the message headers and we had no way to pass 
> > securityModel in the headers.
> > 
> > With secure transports, the security parameters are actually 
> > provided by the transport layer protocol security - all 
> > except the securityModel parameter. The proposal is to make 
> > the transport model responsible for identifying the 
> > securityModel that will know how to properly process the 
> > securityparameters provided. This is equivalent to what the 
> > SNMPv3 message header provides now.
> > 
> > And by doing this in the transport model, we can use RADIUS 
> > to provide during authentication some centralized control 
> > over the securityModel runtime decision that is so important 
> > to data access authorization.
> > 
> > dbh 
> > 
> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > > Sent: Monday, January 28, 2008 1:56 PM
> > > To: Randy Presuhn; [email-masked]
> > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn
for
> > ACM
> > > 
> > > You cannot actually have such a downref. 
> > > 
> > > Of course, this is not the only issue that I do not like in this

> > > proposal.
> > > 
> > > Dan
> > > 
> > > 
> > >  
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Randy Presuhn [mailto:[email-masked]]
> > > > Sent: Saturday, January 26, 2008 2:55 AM
> > > > To: [email-masked]
> > > > Subject: Re: [Isms] ISMS #8: support of v1/v2c
> > > transport-authn for ACM
> > > > 
> > > > Hi -
> > > > 
> > > > Just a procedural question -
> > > > 
> > > > How would having a normative dependency on an experimental
> > > > (SNMPvc) RFC affect this work process-wise?
> > > > 
> > > > Or is the real sub-text of this discussion that SNMPv3 
> should be 
> > > > withdrawn from the standards track?
> > > > 
> > > > Randy
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Isms mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/isms
> > > > 
> > > > This email was protected during delivery to Avaya with TLS
> > > encryption
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > Isms mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/isms
> > > 
> > 
> > 
> > 
> 

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Feb 2008 20:24:55 +0100

My issues are actually not technical, nor am I in favor of sticking at
any price to architectural purity if deployment realities ask
differently. I cannot convince myself however that binding the security
model for SNMPv2c is within the current ISMS charter, and I suspect that
other IESG members will ask the same question. So we either need to
discuss a re-chartering for this WG or we need to think about making all
or part of this work Experimental. 

Dan

> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM
> 
> Hi Dan,
> 
> I am curious as to what other issues you do not like in this proposal.
> 
> > > Or is the real sub-text of this discussion that SNMPv3 should be

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Feb 2008 08:48:40 +0100

OK, I believe that I got it now and I can support this. The references
issue raised by Randy still needs to be solved somehow. Some of the
SNMPv2 documents were Experimental and are now Historic. They can't be
normative references in standards track documents. 

Dan

> Sent: Tuesday, February 05, 2008 11:37 PM
> RFC3412 forces a binding to exist between the message 
> processing model and the security model, since one provides 
> the parameters for the other. 
> 
> To make transport models work, we needed to modify the 
> architecture to create a binding mechanism between transport 
> models and security models, in the form of tmStateReference, 
> since one provides the parameters for the other. 
> 
> We rechartered to permit us to add the tmStateReference to 
> the ASIs, whatever its content. We did not have to recharter 
> to add the securityName, and then to recharter again to add 
> the securityLevel, and then to recharter again to add the 
> sameSession parameter, and so on. 
> 
> The change that is required to allow transport models to 
> select the corresaponding security model is to provide that 
> an additional parameter - the securityModel parameter - be 
> added to tmStateReference. Why must we recharter to add this 
> parameter?
> 
> The charter says "The goal of the ISMS working group is 
> developing a new security model for SNMP that integrates with 
> widely deployed user and key management systems, as a 
> supplement to the USM security model"
> and we are supposed to "- Specify an architectural extension 
> that describes how transport mapping security models (TMSMs) 
> fit into the
> SNMPv3 architecture." 
> 
> The charter does not say we are constrained to supporting 
> only messages in the SNMPv3MessageSyntax. tmStateReference 
> (and the modified ASIs) is the architectural extension, and 
> part of describing how transport model security models fit 
> within the architecture would include how the securityModel 
> parameter is utilized by the subsystems that get the 
> tmStateReference.  We are not trying to change any other 
> > differently. I cannot convince myself however that binding the 
> > security model for SNMPv2c is within the current ISMS 
> charter, and I 
> > suspect that other IESG members will ask the same question. So we 
> > either need to discuss a re-chartering for this WG or we 
> need to think 
> > about making all or part of this work Experimental.
> > 
> > Dan
> > 
> > 
> >  
> >  
> > 
> > > The SNMPv3 architecture was designed to permit various 
> models to be 
> > > used together in different combinations. I am trying to make it 
> > > possible to use different security models with different message 
> > > versions. I think that is very consistent with the SNMPv3 WG 
> > > intentions of modularity.
> > > 
> > > models was between the SNMPv3 message format and the 
> named security 
> > > models, because the security parameters that are needed by the 
> > > different security models are passed in the
> > > SNMPv1 and the SNMPv1 security model directly, and the SNMPv2c 
> > > message format to the SNMPv2 security model directly, because the 
> > > security parameters are extracted from the fields of the message 
> > > headers and we had no way to pass securityModel in the headers.
> > > 
> except the 
> > > securityModel parameter. The proposal is to make the 
> transport model 
> > > responsible for identifying the securityModel that will 
> know how to 
> > > properly process the securityparameters provided. This is 
> equivalent 
> > > to what the
> > > And by doing this in the transport model, we can use RADIUS to 
> > > provide during authentication some centralized control over the 
> > > securityModel runtime decision that is so important to 
> data access 
> > > authorization.
> > > 
> > > dbh
> > >

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Feb 2008 09:34:10 -0500

I don't think the issue ever existed. We do not now, and do not plan
to, have a reference to SNMPv1 or SNMPv2c documents. 

The closest we currently get is referencing RFC3584, which is a BCP,
to explain the security considerations of NOT using the SSH
authentication when doing access control for an operation contained in
an SNMPv1 or SNMPv2c message delivered over an SSH connection.

Hopefully, the proposed change will eliminate that security
vulnerability.

dbh

> Sent: Wednesday, February 06, 2008 2:49 AM
ACM
for

> > > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c
transport-authn