Early Review of draft-hares-i2rs-auth-trans-04
review-hares-i2rs-auth-trans-04-secdir-early-housley-2015-08-27-00

Please fine the requested SecDir reviews.

Russ



I 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 authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Version reviewed: draft-hares-i2rs-auth-trans-04

Summary: Not Ready.


Major Concerns:

In Section 1.1, I do not understand the difference between "data
integrity" as defined in [RFC4949] and "I2RS integrity" as defined
in this section.

In Section 2.1. I was a bit surprised by the wording in SEC-REQ-03.
The text requires the agent to "confirm that the client has a valid
identity."  How is this different than "confirming the I2RS client's
identity"?  If there is a difference, it needs some explanation.  If it
is the same, please use the same words in SEC-REQ-03 and SEC-REQ-04.

In Section 2.2, SEC-REQ-10 says that BCP 107 does not apply.  In my
view, significant justification is needed, and I do not find it here.
Perhaps this justification can go in the Security Considerations.  At
a minimum, the Security Considerations should state the consequences
of selecting pre-shared keys, which I assume means manual key
management.

In section 2.2: s/need to be able to/MUST be able to/

Section 2.4 include data integrity, data authentication, and replay
prevention requirements.

I do not understand why Section 2.4.1 is included in this document.


Minor Concerns:

Section 1 says: "These requirements were initially described in the
[I-D.ietf-i2rs-architecture] document."  However, this is not important
to capture in the RFC.  Instead, it is important to capture the
relationship of the information in this document to the information
that remain in [I-D.ietf-i2rs-architecture].

I find the wording of SEC-REQ-09 a bit confusing.  If I I was able to
get the meaning correct, I think a better wording is:

   SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
   secure transport and optionally be able to transfer data over a
   non-secure transport.  A secure transport MUST provide data
   confidentiality, data integrity, and replay prevention.

I find a great deal of overlap between SEC-REQ-09 and Section 2.4.  It
is possible that I have misunderstood the intent of SEC-REQ-09.

Please consider adding definitions from RFC 4949 for:
  - access control
  - role
  - role-based access control


Nits:

In Section 2.5, please remove this text: "Observers without permission
can refer to other I2RS clients, attackers, or assorted MITM
(man-in-the-middle) monkeys."

In Section 2: s/MUST BE able/MUST be able/
In Section 2.1: s/I2rs client/I2RS client/
In Section 2.2: s/replay attakc/replay attack/
In Section 2.4: s/Message Integrity/Data Integrity/

I 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 authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Version reviewed: draft-mglt-i2rs-security-requirements-00

Summary: Not Ready.

The document is not really ready for review.  Some sections are just
placeholders.  Since this review was requested, I have taken a look
at the sections that seem to be fleshed out.


Major Concerns:

In Section 1, the first sentence says: "This document addresses
security considerations for the I2RS architecture."  This does not
seem like the right way to begin this document.  This document seems
to contain requirements on an implementation or deployment.  They are
not protocol requirements, which is what I expected from the draft
file name.  This context needs to be set in the Abstract and the
first paragraph of the Introduction.

Section 4.1 talks about the I2RS AAA architecture, but it does not
cover authentication, authorization, and accounting.  The section
seems to be talking about roles, privileges, and role-based access
control.  Maybe the title of the section should be changed.

In Section 4.2, REQ 17, I find the use of "origin" unclear.  The
origin is the I2RS Client, not the application, right?

In Section 4.2, REQ 19, I find the use of "component" unclear.  The
component is the I2RS Client, not the application, right?

In section 4.3, 1st paragraph, I think this would be more clear without
the use of "component".  That is, the I2RS client is responsible for
authentication of the applications, managing the privileges for the
applications, and enforcing access control to resources by the
applications.

I do not understand Section 4.4.  If an I2RS Client authenticates to
I2RS Agent 1 and 2, it is possible that these agents will grant
different privileges to this client.  Is a security domain a set of
agents that are expected  grant the same privileges to this client?
What does availability have to do with the definition of a security
domain?  Maybe these two topics should be in separate sections.  DoS
is also talked about in Section 5.2; I think that it would help the
reader if all of the availability discussions are in one place.


Minor Concerns:

In Section 4.2, REQ 20, I think the wording needs to be clarified to
indicate that I2RS Clients cane support multiple applications at the
same time, and each of them needs to be authenticated.

In Section 5.1, REQ 29, It is unclear to me what part of the system is
performing this monitoring.  When an error is detected, what part of the
system takes corrective actions?


Nits:

In Section 4.2: s/On the hand/On the other hand/