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/