Subject: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 8 Aug 2007 12:17:56 +0200

I am confused by the last 2 paragraphs in sect 6.2

   The prepareOutgoingMessage ASI passes tmStateReference from the
   Message Processing Subsystem to the dispatcher.  How or if the
   Message Processing Subsystem modifies or utilizes the contents of the
   cache is message-processing-model-specific.

   This may sound underspecified, but keep in mind that a message
   processing model might have access to all the information from the
   cache and from the message, and have no need to call a Security Model
   to do any processing; an application might choose a Security Model
   such as USM to authenticate and secure the SNMP message, but also
   utilize a secure transport such as that provided by the SSH Transport
   Model to send the message to its destination.

specifically the wording "an application...".
Applications in our RFC3411 context are CG or CR or NO or NR or such.
I am sure that is not intended here. But then, what is an "application"
in this sentence above?

I am also not sure we should speak about the MPM to "not call a
security model". From our architectural point of view, the MPM
will ALWAYS call a security model. If an implementation does a
shortcut, that is up to them... but should we discuss that here?

I am similarly confused by the "an application..." in section 6.4
last paragraph.

Bert Wijnen 

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 18:06:55 -0400

> I am sure that is not intended here. But then, what is an "application"

Why not?  Is it not these applications which specify a security 
model/name/level and transport domain and address?  If an application 
selects USM security parameters and an SSH transport address, it has 
effectively chosen the use of USM and SSH.

> shortcut, that is up to them... but should we discuss that here?

I agree.  Even if a new MPM were defined in the future, to specify 
situations when using that MPM in which the security model is not called 
would seem to violate the architecture.

-- Jeff

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:44 +0200

Inline

Bert Wijnen  

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 8:17 AM
> To: 'Jeffrey Hutzelman'
> Cc: 'ISMS WG'
> Subject: RE: [Isms] Working Group Last Call - securityName
> 
> Hi, 
> 
> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:[email-masked]]
> > Sent: Wednesday, August 22, 2007 8:32 PM
> > To: David Harrington
> > Cc: 'tom.petch'; 'ISMS WG'
> > Subject: RE: [Isms] Working Group Last Call - securityName
> > 
> > Hrm.  Why does it have to be the security model that saves state 
> > between request and response?
> 
> That's what the architecture demands. 
> 

Mmm... isn't it such that the security model save securityState that it 
needs later when it needs to process a response.?

The trabport model saves tmState that it needs when later
processing a response.

I do not see the wto conflict or cause trouble.
So I do not see why USM over SSH would be a [problem in this respect.

> The transport model doesn't know what the operation in the 
> incoming message is; it doesn't know if the message contains 
> a request or a response. This is because the message has not 
> yet been parsed by the MPM.
> 
Does it need to know?

> The MPM doesn't know what the security parameters are; the 
> securityParmeters in the message are opaque to the MPM; those 
> are only unpacked by the security model. So the security 
> model has to be the one to ave security state.
> 

Right, and so for USM over SSH, the only thing it needs to know is
that the underlying security was indeed at least as high as the 
securityLevel (actually, it may not even need that, does it?).

> > 
> > I actually think it would be acceptable to say you can't 
> use the USM 
> > over SSH combination if the security parameters don't match.
> 
> What security parameters do you want to "match"? These are 
> different protocol parameters at different layers. Can you 
> say that SSH cannot be used over IPsec if the parameters 
> don't match? They are at different layers and use different 
> parameters.
> 
> The MPM selects which security model to use, but the MPM 
> doesn't know what the security parameters are. And once the 
> MPM has selected the USM, the USM has no way to determine the 
> security parameters related to a secure transport. We've done 
> a good job of hiding information ...
> ;-)
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 
>

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:44 +0200

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:44 +0200

Inline

Bert Wijnen  

> Sent: Thursday, August 23, 2007 12:07 AM
> To: Wijnen, Bert (Bert); 
> [email-masked]; David Harrington
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt 
> 
> 
> 
> Why not?  Is it not these applications which specify a 
> security model/name/level and transport domain and address?  
> If an application selects USM security parameters and an SSH 
> transport address, it has effectively chosen the use of USM and SSH.
> 

Mmm... I am less concerned now.. but still have an uneasy feeling.
Need to go lookup details before I can put words around it... or
maybe if I do my concerns go away.

> > security model". From our architectural point of view, the MPM will 
> > ALWAYS call a security model. If an implementation does a shortcut, 
> > that is up to them... but should we discuss that here?
> 
> I agree.  Even if a new MPM were defined in the future, to 
> specify situations when using that MPM in which the security 
> model is not called would seem to violate the architecture.
> 

ack
Bert