Subject: [Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12

From: Barry Leiba <[email-masked]>
Date: Sat, 2 May 2009 22:33:38 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines a type of Security Model, as defined in RFC
3411, designed to go with a Transport Model, as defined in
draft-ietf-isms-tmsm.  I have no expertise in MIBs, and must presume
that people who do have reviewed this.

For that matter, I don't have expertise in SNMP, so please take these
comments with that in mind.  I've briefly gone through the associated
documents, and I think I understand how the pieces fit into the
architecture, but my understanding isn't thorough.

My comments:

Section 1.5: bullets 1 & 2 use normative RFC 2119 language.  Should
bullets 4 & 5 do so also?  E.g., "A Security Model SHOULD NOT require
changes to the SNMP architecture."

Section 2.1.1: I'm confused by this.  RFC 3411 section 3.1.1.4.1 says
that a Security Model specifies "the security protocols used to
provide security services such as authentication and privacy."  Yet
this section says that the Transport Security Model does NOT provide
these things.

And if it doesn't provide them, how can the admonition to use it "with
a Transport Model that provides appropriate security" be a SHOULD, and
not a MUST (noting that "appropriate" security could include no
authentication, if that's appropriate to the system in question)?
Some component has to take responsibility for the security, even if
it's to determine that no authentication or no privacy controls are
needed.

The same goes for the discussion of this in section 8, Security
Considerations.  "The security threats and how these threats are
mitigated should be covered in detail in the specifications of the
Transport Models and the underlying secure transports."  It looks like
this needs to be stronger than plain-English "should", or RFC 2119
"SHOULD", no?

I think this is a key point to make clear, so it's well understood
where the responsibility lies for the assurance of "appropriate"
security in the Transport Model, and what happens when a system uses
multiple Security Models, one of which is this one.

Again, my confusion here might simply be due to my understanding of
the architecture being only superficial.

Barry
-- 
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 May 2009 13:50:46 -0400

Hi,

Thanks fo rthe review.
I am updating the sources.
comments inline

David Harrington
[email-masked]
[email-masked]
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Saturday, May 02, 2009 4:34 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: [secdir] secdir review 
> ofdraft-ietf-isms-transport-security-model-12
> 

fixed.
> this section says that the Transport Security Model does NOT provide

Hmmm. two parts to this answer:
1) RFC3411 says the security model **specifies**; it does not say it
must provide the security services itself. This section says this
security model "does not provide security mechanisms such as
authentication and encryption itself."
So they are consistent.

2) They are slightly inconsistent, because the WG realized that the
interface to different security protocols would require much the same
thing, so we made the Transport Security Model capable of working with
multiple underlying security-providing security protocols, and rather
than **specifying** each possible protocol, we specify how an
administrator can specify the protocol as a parameter used by the
Security Model.

> it's to determine that no authentication or no privacy controls are

That is a deployment decision made by an administrator who has an
understanding of what is appropriate to the system in question. MUST
is for implementers and SHOULD is for deployers.

> this needs to be stronger than plain-English "should", or RFC 2119

fixed.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 15:10:17 -0400

> is for implementers and SHOULD is for deployers.

Nononono.  When we say "MUST is for implementors", we mean that our 
specifications give requirements for implementations which claim to comply; 
RFC2119 requirements language is generally inappropriate for deployment 
advice.

It is appropriate to say TSM MUST be use with a TM that provides 
appropriate security; that is equivalent to saying that implementations 
MUST NOT use TSM together with an inappropriate TM, such as UDP.

That said, selection of transport and security models generally is an 
operational decision.  TSM itself is really architectural glue to allow us 
to push some of the security infrastructure down into a transport below 
SNMP, such as SSH or TLS.  You'd never say "I want to use TSM, now which 
transport should I use"; you'd say "I want to use SSH -- oh, for that to 
work, I have to use it with TSM".

-- Jeff

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 May 2009 15:28:34 -0400

OK, I'll change my answer. 

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?

dbh

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Tuesday, May 05, 2009 3:10 PM
> To: David B Harrington; 'Barry Leiba'; [email-masked];
[email-masked]
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isms] [secdir] secdir review

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 15:42:05 -0400

> What is the correct non-RFC2119 phrase in which to couch our

I don't know, but as I said, I don't think it would be inappropriate to 
simply say TSM MUST be used with a secure transport, placing the onus on 
implementors to prevent inappropriate combinations from being used.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 May 2009 16:43:59 -0400

Hi Barry,

your formulation is "MUST ... use", where "use" is a deployment
decision, and MUST is inappropriate for deployment advice.
We currently use "SHOULD ... use", but Jeff thinks that in
inappropriate as well.

How about:
    by the RFC 3411 architecture.  However, the Transport Security
Model
    does not provide security mechanisms such as authentication and
    encryption itself, so operators are advised to always use this
    with a Transport Model
    that provides appropriate security, where "appropriate" for a
particular
    deployment is an administrative decision.  Which threats are
addressed
    and how they are mitigated depends on the Transport Model.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Barry Leiba
> Sent: Tuesday, May 05, 2009 4:04 PM
> To: David B Harrington
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> 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.
> 
> Barry
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 May 2009 23:37:25 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Jeffrey Hutzelman'" <[email-masked]>; "'Barry Leiba'" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Tuesday, May 05, 2009 12:28 PM
> Subject: Re: [Isms] [secdir] secdirreview ofdraft-ietf-isms-transport-security-model-12
...
> What is the correct non-RFC2119 phrase in which to couch our
...

Sounds like what RFC 2026 calls an "Applicability Statement".

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 May 2009 11:30:21 +0200

> implementors to prevent inappropriate combinations from being used.

I think the only interesting case here is the sending of messages
where a combination of TSM with say UDP/TCP leads to maybe surprising
results. (Note that the existing EoPs take care of dropping incoming
messages received by a non-secure transport model that does not
provide an appropriate cache entry.) I believe changing to MUST is
actually fine and it will be very implementation specific how one
prevents a combination such as TSM with UDP - so having this not
spelled out in the EoP seems to be fine.

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 5 May 2009 16:03:52 -0400

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.

Barry

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 6 May 2009 17:16:53 +0900

How about just losing the capitalization?

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David B Harrington
> Sent: Wednesday, May 06, 2009 5:44 AM
> To: 'Barry Leiba'
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-
> security-model-12
> 
> Hi Barry,
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 May 2009 21:15:47 -0400

>>>>> "David" == David B Nelson <[email-masked]> writes:

    David> David B Harrington writes...
    >> What is the correct non-RFC2119 phrase in which to couch our

    David> One suitable strategy would be to include any "advice to
    David> operators" in a non-normative section or appendix, clearly
    David> labeled as non-normative.  I don't think the "keyword
    David> police" will bother with non-normative text.  :-)

8
    David> _______________________________________________ secdir
    David> mailing list [email-masked]
    David> https://www.ietf.org/mailman/listinfo/secdir

Or just use lower case should.  I think the advice is important enough
it does not belong in an appendix.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 8 May 2009 18:56:27 +0200

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 05, 2009 10:03 PM

>    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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Fri, 8 May 2009 22:35:38 +0200

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 May 2009 23:43:46 +0200

On Fri, May 08, 2009 at 06:56:27PM +0200, tom.petch wrote:
 
> 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.

Not sure I understand why. Can you explain?

> Thus TLS has session cache and resumption. Will that work with TSM?

Yes, this will just work fine since it is transparent. You can add
session resumption to SSH and it will work just fine with sshtm.

Of course, sometimes we design for extensibility and when we need it,
we realize the shortcomings of the design. But there are also things
that just work fine - you are painting a picture here with black
colors. Even though it is difficult to get exensibility right, I think
not trying to be extensible is not an alternative.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 8 May 2009 18:09:46 -0400

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Friday, May 08, 2009 4:36 PM
> To: Barry Leiba
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isms] [secdir] 
> secdirreviewofdraft-ietf-isms-transport-security-model-12
> 
Model
Model
Model
> > ssh just hit problems with AES-GCM, that the architecture 
> of ssh does not
> allow
> > know - and as it has taken the last two years to come up 
> with an agreed form
> of
> > Or we may have another secure Transport Model that turns 
> out to be insecure
> with

---

From: "David Harrington" <[email-masked]>
Date: Fri, 8 May 2009 18:24:05 -0400

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
[email-masked]
[email-masked]
[email-masked]

Model
Model
Model

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 09 May 2009 06:50:49 -0700

>>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen Schoenwaelder <[email-masked]> said:

>> regardless of whether it is secure or not.

JS> Not sure I understand why. Can you explain?

The way it's worded right now in the SSH document is that there must be
a tmStateReference for outgoing messages or the SSHTM will drop the
message:

   1.  If tmStateReference does not refer to a cache containing values
       for tmTransportDomain, tmTransportAddress, tmSecurityName,
       tmRequestedSecurityLevel, and tmSameSecurity, then increment the
       sshtmSessionInvalidCaches counter, discard the message and return
       the error indication in the statusInformation.  Processing of
       this message stops.

USM won't generate a tmStateReference so it can't be used as an
upper-level security protocol.  This was discussed (I'm fairly certain)
on the list at some point and it was decided this was ok as doing
something to try and recover at that point would really be adding words
and complexity for a situation that didn't really need to be supported.

[that being said, note that there isn't a MUST drop it in the text]
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Sat, 9 May 2009 12:31:38 -0400

Hi,

I agree we didn't use the word "MUST" in this text, but we do not seem
to allow any alternative approach:

"then [...] discard the message and return
       the error indication in the statusInformation." 

For compliance to this model, this is a required step.
Where we do NOT specify a MUST is in the **architecture** document,
because other models might choose to do something other than discard
the message.

Wes, are you suggestiong we should rwwrite all the elements of
procedure to use MUST every place where there is a definite step to be
followed? Would this be clearer?

>        tmRequestedSecurityLevel, and tmSameSecurity, then the
implementation MUST 
> increment the
>        sshtmSessionInvalidCaches counter, MUST discard the message 
> and MUST return
>        this message MUST stop.

is that what you want to see?

dbh

> Behalf Of Wes Hardaker
> Sent: Saturday, May 09, 2009 9:51 AM
> To: tom.petch
> Cc: Barry Leiba; [email-masked]; [email-masked]
> Subject: Re: [Isms] [secdir]secdir 
> reviewofdraft-ietf-isms-transport-security-model-12
> 
> >>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
>

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 09 May 2009 15:20:16 -0700

>>>>> On Sat, 9 May 2009 12:31:38 -0400, "David Harrington" <[email-masked]> said:

DH> Wes, are you suggestiong we should rwwrite all the elements of
DH> procedure to use MUST every place where there is a definite step to be
DH> followed? Would this be clearer?

David, stop leaping.

---

From: "tom.petch" <[email-masked]>
Date: Mon, 11 May 2009 18:49:02 +0200

Juergen

Apologies for the delayed response.  Happily, I think that Wes's post last
Saturday covered it very well.

The text as it stands tells me that with sshTM but without TSM, conformance to
the three I-Ds will cause outbound messages to be discarded (although inbound
can be received - a potential attack surface?)

But again as Wes says, this topic has occurred on the list, more than once I
seem to recall.  I believe it was Bert who first commented - sadly - that it did
not seem possible to use sshTM with eg CSM.  But that is what we have come up
with.

Tom Petch

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 May 2009 22:10:30 -0400

Sam says...
> it does not belong in an appendix.

Indeed.

I didn't mean for my comment to cause a big stir; I think it's easy to sort out.

I like my first suggestion, repeated here:

...but I'd also be happy with something like this, if you don't want
to use 2119 language:

  by the RFC 3411 architecture.  However, the Transport Security Model
  does not provide security mechanisms such as authentication and
  encryption itself, so deployments should [or "must"] use it with a
Transport Model
  that provides appropriate security.  Which threats are addressed
  and how they are mitigated depends on the Transport Model.

In any case, let's not spend any more time on this one.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 May 2009 14:05:15 -0400

(Top post only...)

Barry