Skip to main content

Last Call Review of draft-ietf-isms-transport-security-model-
review-ietf-isms-transport-security-model-secdir-lc-leiba-2009-05-24-00

Request Review of draft-ietf-isms-transport-security-model
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-05
Requested 2009-04-02
Authors Wes Hardaker , David Harrington
I-D last updated 2009-05-24
Completed reviews Secdir Last Call review of -?? by Barry Leiba
Assignment Reviewer Barry Leiba
State Completed
Request Last Call review on draft-ietf-isms-transport-security-model by Security Area Directorate Assigned
Completed 2009-05-24
review-ietf-isms-transport-security-model-secdir-lc-leiba-2009-05-24-00
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  (barryleiba at computer.org)


http://internetmessagingtechnology.org/