Re: [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12

["David B Harrington" <[e-mail]>]

Hi,

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

David Harrington
[e-mail]
[e-mail]
[e-mail] 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Barry Leiba
> Sent: Saturday, May 02, 2009 4:34 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; 
> [e-mail]
> Subject: [secdir] secdir review 
> ofdraft-ietf-isms-transport-security-model-12
> 
> 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."

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

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.

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

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.

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

fixed.

> 
> 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  ([e-mail])
> http://internetmessagingtechnology.org/
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
>