Subject: [Isms] Review of draft-ietf-isms-transport-security-model-10

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 25 Nov 2008 13:44:05 -0800

This is also an excellent document.  I have a few comments listed below:

1. Section 2 - This section is useful and explicitly stated some things
I was looking for in the transport document about who generates the
tmState is different cases.  This section discusses what happens when
the transport model does not fill in the tmState reference on an
incoming message.  It should also have a brief discussion of what
happens if the security model does not fill in the tmState.  It seems
that this is possible since a secure transport can be used with a
security model other than the transport security model.  

2. It seems that section 3.3.3 conflicts with section 3.2.2.1 of TMSM.
TMSM states that the tmSecurityName is constructed with a prefix and the
security model states that the tmSecurityName does not have a prefix.  I
think it makes more sense if the tmSecurityName does not have the
prefix, but the securiutyName may have the prefix.  

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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 28 Nov 2008 12:09:04 +0100

<inline - murky waters >

Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 25, 2008 10:44 PM
Subject: [Isms] Review of draft-ietf-isms-transport-security-model-10

> prefix, but the securiutyName may have the prefix.
tmsm says a prefix MUST exist but does not say MAY/SHOULD/MUST be used.
s3.2.2.1 could be interpreted as saying that tmSecurityName includes the prefix
but could also not eg where it says that the prefix will be prepended (not that
it has been prepended)

tsm 3.3.3 says the tmSecurityName does not include a prefix.

tsm 4.2 2) says that the securityStateReference (ie this is a outgoing Response)
stores the tmStateReference with the unprefixed tmSecurityName - the use of
'unprefixed' suggests to me that on other occasions tmSecurityName may be
prefixed.

tsm 4.2 2) a says strip the transport-specific prefix from the tmSecurityName
(when snmpTsmConfigurationUsePrefix is true); the tmSecurityName has just been
copied from the securityName so the prefix is presumably there temporarily

tsm 5.2 3) says set the securityName to be the concatenation of the prefix and
the tmSecurityName (when snmpTsmConfigurationUsePrefix is true) implying that
tmSecurityName does not contain the prefix

secshell defines the prefix character string and gives it an SNMP OID.

So my current view is that using TSM, the tmSecurityName may include the prefix
on a temporary basis; whether or not it will do so for other Security Models
(VSM, WSM, XSM etc) will appear as and when they are defined.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 28 Nov 2008 12:35:46 -0500

Hi,

with the exception of the temporary state Tom mentioned, the
tmSecurityName does not include the prefix. It is added by TSM when
defining securityName on input, and removed by TSM when received from
an application.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Friday, November 28, 2008 6:09 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Isms] Review of 
> draft-ietf-isms-transport-security-model-10
> 
> <inline - murky waters >
> 
> Tom Petch
> 
> Subject: [Isms] Review of
draft-ietf-isms-transport-security-model-10

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Nov 2008 20:36:24 +0100

> secshell defines the prefix character string and gives it an SNMP OID.

The text says:

         The securityName prefix to be associated with the
         snmpSSHDomain is 'ssh'.

The fact that this text appears in the snmpSSHDomain definition is not
relevant for the prefix value; the OID is assigned to the snmpSSHDomain
not to the prefix.

/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://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Sat, 29 Nov 2008 13:55:33 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
Sent: Friday, November 28, 2008 6:35 PM
Subject: RE: [Isms] Review of draft-ietf-isms-transport-security-model-10

> defining securityName on input, and removed by TSM when received from
So, following Joe's original comment, should we amend the text in tmsm
s.3.2.2.1?  Not easy, because adding the prefix in TSM is still optional and a
discussion of that seems like a Model issue to me, not an architectural one.

Currently

Documents defining a new transport domain MUST define a prefix that
   will be prepended to all passed tmSecurityNames.  The prefix MUST
   include from one to four ASCII characters, not including a ":" (ASCII
   0x3a) character.  A tmSecurityName is constructed by concatenating
   the prefix and a ":" (ASCII 0x3a) character followed by a non-empty
   identity in an snmpAdminString compatible format.  Transport domains
   and their corresponding prefixes are coordinated via the IANA
   registry "SNMP Transport Domains".

it might become

   Documents defining a new transport domain MUST define a prefix that
   MAY be prepended to a tmSecurityName when converted by a Security
   Model to a securityName.  The prefix MUST
   include from one to four ASCII characters, not including a ":" (ASCII
   0x3a) character.  The conversion is performed by concatenating
   the prefix and a ":" (ASCII 0x3a) character followed by a non-empty
   identity in an snmpAdminString compatible format.  Transport domains
   and their corresponding prefixes are coordinated via the IANA
   registry "SNMP Transport Domains"[RFCXXXX].

   -- NOTE to RFC editor: replace XXXX with actual RFC number
   --                     for this document and remove this note

[I prefer the singular object name tmSecurityName to a false plural]
[my comment about ASCII characters still applies - I would like it restricted,
eg to printable ASCII]

Tom Petch

ps David, everytime I send you a message, Comcast tells me it's 
BL004 Blocked for spam:-(