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/