Subject: [Isms] status of draft-ietf-isms-transport-security-model-04.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 May 2007 08:24:02 +0200

Hi,

David posted <draft-ietf-isms-transport-security-model-04.txt> a few
days ago.

David, can you summarize where you see this document? Do you think
this document addresses all the comments received during the WG last
call or are there any open issues left on this document?

/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/>

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 May 2007 14:57:18 -0400

I believe the document represents WG consensus on all raised issues.
In a few cases, the consensus was rough, and the chairs might want to
review the discussions on these points. 

1) should the incompatibility of TSM and rfc3584 be mentioned?
2) should an error be generated by TSM if msgSecurityParameters is not
a zero length OCTET STRING?
3) should the prepareResponseMessage ASI include transport parameters?

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 2:24 AM
> To: [email-masked]
> Subject: [Isms] status of 
> draft-ietf-isms-transport-security-model-04.txt
> 
> Hi,
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 May 2007 09:11:03 -0400

Comments inline 

> Sent: Wednesday, May 09, 2007 8:22 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] status 
> ofdraft-ietf-isms-transport-security-model-04.txt
> 
> On Tue, May 08, 2007 at 02:57:18PM -0400, David Harrington wrote:
>  
> There is no incompatibility with RFC 3584 as far as I can tell. I
> understand that people are interested in the transition path from
> SNMPv1/SNMPv2c to an ISMS solution, but this is in my view not bound
> to RFC 3584. The following text in section 2.3
> 
>    The SNMPv1 and SNMPv2c message processing described in RFC3584
(BCP
>    74) [RFC3584] always selects the SNMPv1(1) Security Model for an
>    SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c
>    message.  Since there is no field in the message format 
> that permits
>    specifying a Security Model, RFC3584 message processing does not
>    permit the selection of Security Models other than SNMPv1 
> or SNMPv2.
>    Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1
or
>    SNMPv2 Message Processing Models **as defined in RFC3584** 
> cannot use
>    the Transport Security Model.  (This does not mean an SNMPv1 or
>    SNMPv2 message cannot use a secure transport model, only that the
>    RFC3584 MPM will not invoke this security model.)
> 
> seems to describe the situation in an appropriate way. Perhaps a
note
> can be added that running SNMPv1/SNMPv2c over a secure transport
like
> SSH has some problems, namely that the securityName used for access
> control decisions is then derived from the community string, which
is
> not the authenticated identity. (I can authenticate as guest and
then
> simply claim to be root.)

will add the note.

> > 3) should the prepareResponseMessage ASI include transport 
[...]
> In other words, architecturally it makes sense to include these
> parameters for consistency between the generateRequestMsg() and
> generateResponseMsg() ASIs and added flexibility for future security
> models, but for ISMS to achieve its goals, these parameters are not
> strictly needed for the generateResponseMsg() ASI. Am I correct?

Yes.
> 
> Reading consensus is difficult here since this was mostly a
discussion
> between you and Bert. If my summary above is correct and somewhat
> understandable, then perhaps others can speak up here and help us to
> find concensus (or you and Bert reach agreement ;-).

We can try.

> 
> In any case, the introduction of these parameters should have been
> described in the transport subsystem document <draft-ietf-isms-tmsm>
> and not in the transport security model. At the moment, these
> documents do not seem to be consistent; in fact, section 6.2 of the
> transport subsystem document should probably spell out the
signatures
> of the generateRequestMsg() and generateResponseMsg() ASIs and
> indicate the new elements.

When I submitted the TSM update, I also submitted a TMSM update; I
don't know why that has not been published as well. That had the
requested fix.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 May 2007 14:21:33 +0200

The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP
   74) [RFC3584] always selects the SNMPv1(1) Security Model for an
   SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c
   message.  Since there is no field in the message format that permits
   specifying a Security Model, RFC3584 message processing does not
   permit the selection of Security Models other than SNMPv1 or SNMPv2.
   Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or
   SNMPv2 Message Processing Models **as defined in RFC3584** cannot use
   the Transport Security Model.  (This does not mean an SNMPv1 or
   SNMPv2 message cannot use a secure transport model, only that the
   RFC3584 MPM will not invoke this security model.)

seems to describe the situation in an appropriate way. Perhaps a note
can be added that running SNMPv1/SNMPv2c over a secure transport like
SSH has some problems, namely that the securityName used for access
control decisions is then derived from the community string, which is
not the authenticated identity. (I can authenticate as guest and then
simply claim to be root.)

[Note that on an API level, I believe ISMS can be made to look very
 similar to SNMPv1/SNMPv2c and this I believe addresses the concerns
 people have in practice.]

> a zero length OCTET STRING?

I polled for additional opinions with very little feedback and a
slight preference to treat a non-zero length value as an error, and
this is also what the text currently says in section 5.2:

   2) If the received securityParameters is not a zero-length OCTET
   STRING, then the snmpInASNParseErrs counter [RFC3418] is incremented,
   and an error indication (parseError) is returned to the calling
   module, and Security Model processing stops for this message.

If WG members feel strongly that this should be changed, please speak
up now. I will read silence as agreement to the current text.

> 3) should the prepareResponseMessage ASI include transport parameters?

I assume the question is about the generateResponseMsg() ASI. As far
as I understand, you proposed to add

          IN   transportDomain         -- (NEW) specified by application
          IN   transportAddress        -- (NEW) specified by application

to both generateRequestMsg() and generateResponseMsg(). It is clear
why these parameters are needed in generateRequestMsg(), but it is
less clear why they are needed in generateResponseMsg() (the transport
security model extracts those values from the cache - these parameters
would only be needed in future security models where responses would
be allowed to travel over transports different than the transport used
to receive the request).

Reading consensus is difficult here since this was mostly a discussion
between you and Bert. If my summary above is correct and somewhat
understandable, then perhaps others can speak up here and help us to
find concensus (or you and Bert reach agreement ;-).

transport subsystem document should probably spell out the signatures

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 14 May 2007 11:48:09 +0200

Point 3 in this dialogue leave me confused (1 and 2 are fine by me).

I am clear that I expect to see tmStateReference as an OUT parameter in
prepareResponseMessage ASI ie the call from Dispatcher to MPP.

Juergen's reply said
"I assume the question is about the generateResponseMsg() ASI. "

Nope, I do not assume that; I assume it is about prepareResponseMessage ASI
RFC3411 s4.2.2

David's reply said
"> When I submitted the TSM update, I also submitted a TMSM update; I
> requested fix."

Nope, I saw TMSM update draft-ietf-isms-tmsm-08.txt and TSM update
draft-ietf-isms-transport-security-model-04.txt
But the former does not contain the requested fix (it does contain other fixes
such as the TLS reference); s6.2 still says
"6.2.  Other Outgoing ASIs

   A tmStateReference parameter has been added to the
   prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg
   ASIs as an OUT parameter."

prepareResponseMessage remains conspicuous by its absence.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 09, 2007 3:11 PM
Subject: RE: [Isms] status ofdraft-ietf-isms-transport-security-model-04.txt

> > > review the discussions on these points.

<snip 1) 2) >

---

From: "David Harrington" <[email-masked]>
Date: Mon, 14 May 2007 06:59:38 -0400

Hi,

I apologize. I accepted Juergen;s comment, and just assumed I had made
a typo referencing the ASI. You know what they say about asumming.  

I'll reply later today on this issue - AFTER doing the research I
should have done earlier.

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Monday, May 14, 2007 5:48 AM
> To: David Harrington; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] status