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

Hi,

IN sechell-17, its says:

"It is expected that an entity implementing this MIB will
   also support the Transport Security Model
   [I-D.ietf-isms-transport-security-model], and therefore implement
the
   SNMP-TSM-MIB."

"   To have SNMP properly utilize the security services provided by
SSH,
   the SSH Transport Model MUST be used with a Security Model that
knows
   how to process a tmStateReference, such as the Transport Security
   Model for SNMP [I-D.ietf-isms-transport-security-model]."

In transport-model-14, 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]."

By keeping the reference to an example using "such as", we avoid hard
bindings between the models, and we avoid normative references between
the documents, so as to not defeat the goal of the RFC3411 modular
architecture of allowing the models to advance on the standards track
independently.

dbh

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