Subject: [Isms] Review of draft-ietf-isms-tmsm-15

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 24 Nov 2008 23:28:42 -0800

I have review the transport subsystem document.  I think the document is
excellent. I have a few comments and questions below.  I have not been
able to keep up with the discussion so if I am bringing up old news let
me know and I'll go back through the archives.  

1. Denial of service

Section 3.1 states "It is not required to protect against denial of
service or traffic analysis, but it should not make those threats
significantly worse."   While I think this is a fine statement, I
believe the DOS characteristics of some transport subsystems will be
different than USM.  There should be a section in the security
considerations section that indicates that the DOS characteristics of
various transports will vary and should be evaluated when determining
the applicability to a particular deployment situation.  

2. (editorial) Section 3.2.2.1 comma instead of period at end of
paragraph

3. Security name

Is it possible for the security name in 3.2.2.1 to be ambiguous.  For
example is it possible for a ":" to exist in a security name from
another model?  I think the answer is that this is the tmSecurityName so
it always has the ":" form.  Mapping to the securityName takes this into
account. 

4. 5.2.2. when is the tmSecurityName Different than the transport
principal?

5. I had some trouble visualizing the flow of information in the ASIs.
In particular I wasn't sure who was going to fill in the tmState fields.
I think on an out going message the transport security model populates
the cache and on an incoming message the transport model does.  I think
one can probably get this from the ASIs, but it might help to explicitly
state this (if it is indeed accurate).  

6. security considerations section should indicate that DOS
characteristics of transport models may vary and deployments should
consider this.  

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

---

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

<inline>
Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 25, 2008 8:28 AM
Subject: [Isms] Review of draft-ietf-isms-tmsm-15

> 4. 5.2.2. when is the tmSecurityName Different than the transport
When it needs to be:-)

The idea of a mapping between the identity used in a secure transport and the
identity in the securityName has been around a long time but the justification
for it has varied.

eg
ssh has different restrictions on character set and length to SNMP and that
might force a mapping.

ssh users might be using one security domain and tls users another with
different identities in each with a need for the identities to be mapped to a
common identity for securityName purposes.

SNMP as it stands has a securityName for a transaction, common to Notification
Originator/Notification Receiver etc; ssh has distinct client and server
identities so one might need mapping

etc etc

and this has then led to two or more identities - currently three - with various
proposals for where mapping between them takes place.

(My own personal view is that we MUST allow for a mapping and that this is only
possible if it happens in the Transport Model but this is only a personal view).

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 30 Nov 2008 22:18:03 -0800

> The idea of a mapping between the identity used in a secure 
> transport and the identity in the securityName has been 
> around a long time but the justification for it has varied.
> 
> eg
> ssh has different restrictions on character set and length to 
> SNMP and that might force a mapping.
> 
> ssh users might be using one security domain and tls users 
> another with different identities in each with a need for the 
> identities to be mapped to a common identity for securityName 
> purposes.
> 
> SNMP as it stands has a securityName for a transaction, 
> common to Notification Originator/Notification Receiver etc; 
> ssh has distinct client and server identities so one might 
> need mapping
> 
> etc etc
> 
[Joe] I had trouble reading the text first time through.   I definitely
thing there needs to be allowance for a mapping between the transport
name for the principal and the securityName. 

> and this has then led to two or more identities - currently 
> three - with various proposals for where mapping between them 
> takes place.
> 
[Joe] I think I understand the three identities now.  

> (My own personal view is that we MUST allow for a mapping and 
> that this is only possible if it happens in the Transport 
> Model but this is only a personal view).
> 
> > the cache and on an incoming message the transport model does.  I 
> > think one can probably get this from the ASIs, but it might help to 
> > explicitly state this (if it is indeed accurate).
> >