Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms-transport-security-model-12

Hi,

transport-security-model-14 says, in the discussion of threats,:

"   The Transport Security Model is compatible with the RFC3411
   architecture, and provides protection against the threats
identified
   by the RFC 3411 architecture.  However, the Transport Security
Model
   does not provide security mechanisms such as authentication and
   encryption itself.  Which threats are addressed and how they are
   mitigated depends on the Transport Model used.  To avoid creating
   potential security vulnerabilities, operators should configure
their
   system so this Security Model is always used with a Transport Model
   that provides appropriate security, where "appropriate" for a
   particular deployment is an administrative decision."

Whether SSHTM is appropriate in the network being managed is an
administrative decision, so we do not cite it specifically at this
point.  

and, under Coexistence with Transport Models, it says:
"    To have SNMP properly utilize the security services coordinated
by
   the Transport Security Model, this Security Model MUST only be used
   with Transport Models that know how to process a tmStateReference,
   such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]."

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On 
> Behalf Of tom.petch
> Sent: Friday, May 08, 2009 4:36 PM
> To: Barry Leiba
> Cc: isms@ietf.org; secdir@ietf.org
> Subject: Re: [Isms] [secdir] 
> secdirreviewofdraft-ietf-isms-transport-security-model-12
> 
> ----- Original Message -----
> From: "Barry Leiba" <barryleiba@computer.org>
> To: "tom.petch" <cfinss@dial.pipex.com>
> Cc: <isms@ietf.org>; <secdir@ietf.org>
> Sent: Friday, May 08, 2009 8:05 PM
> 
> (Top post only...)
> I get what you're saying, Tom, but I'm not sure where it's going.
Are
> you saying that the text should be changed to allow *less*
> flexibility?  That may be right, but then what text do you suggest
> instead?
> 
> Barry
> 
> I would like the idea of 'in conjunction with' to hint at the 
> co-dependence of
> xSM and xTM eg
> 
> "However, the Transport Security Model
> does not by itself provide security mechanisms such as 
> authentication and
> encryption, so it MUST always be used in conjunction with a 
> Transport Model that
> together with it provides appropriate security"
> 
> Tom Petch
> 
> Barry
> 
> >> > That is a deployment decision made by an administrator who has
an
> >> > understanding of what is appropriate to the system in question.
> >> >
> >> > What is the correct non-RFC2119 phrase in which to couch our
> >> > deployment advice?
> >>
> >> Well, this would make me happy; would it work for you (and 
> others)?:
> >>
> >> OLD:
> >> by the RFC 3411 architecture. However, the Transport Security
Model
> >> does not provide security mechanisms such as authentication and
> >> encryption itself, so it SHOULD always be used with a 
> Transport Model
> >> that provides appropriate security. Which threats are addressed
and
> >> how they are mitigated depends on the Transport Model.
> >>
> >> NEW:
> >> by the RFC 3411 architecture. However, the Transport Security
Model
> >> does not provide security mechanisms such as authentication and
> >> encryption itself, so it MUST always be used with a Transport
Model
> >> that provides appropriate security. What is "appropriate" 
> for a particular
> >> deployment is an administrative decision. Which threats 
> are addressed
> >> and how they are mitigated depends on the Transport Model.
> >
> > I have reservations about this, about the optimism that it 
> may generate in
> > readers.
> >
> > The idea of Models in SNMP is to be able to mix and match. 
> In practice, this
> > has not worked - USM with sshTM will not function, 
> regardless of whether it is
> > secure or not. Do not underestimate the labour it has taken 
> to get TSM working
> > with sshTM.
> >
> > If we have got TSM right, then it will work with eg TLSTM 
> or DTLSTM, an idea
> > that is being mooted now. But it may not. In a similar 
> vein, I am mindful that
> > ssh just hit problems with AES-GCM, that the architecture 
> of ssh does not
> allow
> > for this new cryptography or that the discussions leading 
> to TLS 1.2 of how to
> > introduce (or not) algorithm agility, just as SNMP has 
> problems (and has given
> > up) trying to use USM with sshTM.
> >
> > Thus TLS has session cache and resumption. Will that work 
> with TSM? I do not
> > know - and as it has taken the last two years to come up 
> with an agreed form
> of
> > words that allows just TSM to work with just sshTM, so I am 
> not going
> > to try and work out the ramifications of TLSTM just yet:-( 
> We may find we got
> > TSM wrong and that it needs changing.
> >
> > Or we may have another secure Transport Model that turns 
> out to be insecure
> with
> > TSM and needs an xSM to make it secure. The proposed 
> amendment seems to me
> > rather optimistic.
> >
> > Tom Petch
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 