Subject: [Isms] working group last call on draft-ietf-isms-transport-security-model-03

From: Juergen Quittek <[email-masked]>
Date: Sat, 10 Mar 2007 00:13:39 +0100

Dear all,

This is the working group last call on the
    "Transport Security Model for SNMP"
to be found at
<http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-03.txt>.

The authors and the chairs think that this document is mature enough
for last call.

Please do review the document and post your comments on this list until
March 25, 2007.  Of course it would be great to get your comments already
before our next meeting on March 22.

Please also post to the list if you have read the document and are fine
with it as it is.  It is very useful to know how many people have read
the document.

Thanks,

    Juergen Q.
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 15 Mar 2007 17:25:49 +0100

s.2

  "The Transport Model of an SNMP engine will perform the translation
   between transport-specific security parameters

**only if it is a secure Transport Model - for UDP over IPv6, there are no
security parameters.
                                                    " and the SNMP-specific,
   model-independent parameters securityName and securityLevel.

**only if the Security Model decides to use them; the Transport Model only puts
putatative values in a cache which the SM may or may not use.  The obvious case
is v2c over ssh when the cache will be ignored
  "To
   maintain the RFC3411 modularity, the Transport Model does not know
   which securityModel will be used for an incoming message;
**true!
                                                                        " the
Message
   Processing Model will determine the securityModel to be used, in a
   Message Processing Model dependent manner.  In an SNMPv3 message
   [RFC3412], the Transport Security Model should be specified in the
   message header.
**should be specified?  to the exclusion of all else:-)  I suggest
 "In an SNMPv3 message, the Security Model is specified in the
   message header.
**and you might want to add which object and which value of that object is
intended to invoke the Transport Security Model
**and what about v1 and v2c MPP? can they invoke Transport Security Model; read
hard between the lines and my conclusion is not, but I think it should be
specified.

Tom Petch

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 10, 2007 12:13 AM
Subject: [Isms] working group last call
ondraft-ietf-isms-transport-security-model-03

>     "Transport Security Model for SNMP"
<http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-03
.txt>.

---

From: "tom.petch" <[email-masked]>
Date: Mon, 19 Mar 2007 10:36:48 +0100

I think that this I-D uses securityModel in two different senses and as such,
may confuse, mislead even.  (securityLevel seems to be used as a class of object
of which there are multiple instances).

There is an object in the message which describes the security requested by the
application, say application.securityLevel; and there is the security achieved
by the transport, which is then placed in the tmStateReference cache by the
Transport Model and used by the Transport Security Model for comparison, say
transport.securityLevel.

s2.4 last paragraph and s3.1.1 differentiate the two usages while using  the
same
term for both; in other cases, I find this less clear.

s2.1.2 I find unclear, perhaps incorrect.  I believe that, as s3.1.1 states,
application.securityLevel is used in the request but that
transport.securityLevel
is then used by TSM, but not to assert the level of security achieved but to
check
that the level achieved is not less than application.securityLevel as described
s2.4.  But I do not think that that is what these words say.

s2.2 I assume that this is application.securityLevel

s2.5 I assume that both uses refer to application.securityLevel

s.4 which securityLevel is returned?

s.4.2 2) which securityLevel is intended?  Should the search in the LCD be for a
cache entry whose transport.securityLevel is not less than
application.securityLevel
or for an exact match?  Does this vary depending on whether this is a Response
message/NO or a Request?
And if an LCD entry is created, then which securityLevel is put into it?  for an
outoing message, transport.securityLevel is most likely unknown; on the other
hand, the tsms i-d s3.2.3 talks of
"The security parameters include  ... which authentication and privacy
   services were (should be) applied to the message (securityLevel)."
The use of 'were' suggests that transport.securityLevel is intended.

I don't think this has been discussed and see problems with either alternative.

s.5 which securityLevel is returned?

s 5.2 2) by implication this is transport.securityLevel but is open to
misinterpretation

s 5.2 9) which securityLevel is cached?  I think that both need to be.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Mon, 19 Mar 2007 08:33:08 -0400

Hi, 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 5:37 AM
> To: Juergen Quittek; [email-masked]
> Subject: Re: [Isms] working group last 
> callondraft-ietf-isms-transport-security-model-03
> 

I concur. I think the securityName and securityLevel in tmSatteRef
cache should be called tmSecurityName and tmSecurityLevel. The names
used in the ASI (extracted from the message presumably) are previosuly
defined, and should remain the same, IMO.

I will review the rest of these comments later.

dbh

---

From: "tom.petch" <[email-masked]>
Date: Tue, 20 Mar 2007 19:19:11 +0100

I commented before that I do not find s.2 clear.  I also think that this is a
crucial section for the document as a whole, especially for those who have not
lived with these ideas for the past two years, as it provides the framework into
which the details will fit.  I believe it should be explicit, as in the
following,
with ** marking changes, of sentences or word

 " The Transport Security Model is designed to fit into the RFC3411
   architecture as a Security Model in the Security Subsystem, and to
   utilize the services of a secure Transport Model.

**The secure Transport Model maintains a cache, referenced by tmStateReference,
which is used to pass information between the Transport Security Model and the
secure Transport Model, and vice versa.

**If the Transport Security Model is used with an insecure Transport Model, then
the cache is unlikely to be populated with security parameters, which will cause
the Transport Security Model to return an error (see section 5.2)

**If another Security Model (eg Community-based Security Model) is used with a
secure Transport Model, then the cache will be populated but the other Security
Model may be unaware of the cache and ignore its contents (eg deriving the
securityName from the Community name in the message instead of deriving it from
the cache).

**When the Transport Security Model is used with a secure Transport Model, as
is intended to be the case, then the information in the cache is used by
the Transport Security Model to translate between the security model-independent
securityName and any identity used by the secure transport; and to record the
tmSecurityLevel provided for the message by the transport (a level of security
which may exceed the securityLevel requested for the message by the
application).

                   To
   maintain the RFC3411 modularity, the Transport Model does not know
   which securityModel will be used for an incoming message; the Message
   Processing Model will determine the securityModel to be used, in a
   Message Processing Model dependent manner.  In an SNMPv3 message
   [RFC3412], the Transport Security Model **s/should/can/ be specified in the
   message header using the object securityModel.
**The use of the Transport Security Model with other message types is outside
the scope of this document."

This is intended to be a rewording of what has been agreed and not to introduce
changes.

Tom Petch