Re: [secdir] Early SecDir Reviews

[Daniel Migault <[e-mail]>]

Hi Russ, 

Thank you for your comments. We believe the version 01 of the draft have appropriately addressed these comments. Here is a small recap of the comments as well as how the new version addresses them. Feel free to let us know if we missed something.

BR, 

The co-authors

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.

MGLT: Thank you for the feed back. We addressed this comment by starting the introduction (Section 1) with the following sentences :
This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result, the requirements provided in this document are intended to provide good security practise so I2RS can be securely deployed and operated.


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.

MGLT  The title has been changed to "I2RS Access Control for routing system resources"
AAA has been replaced by Access Control. We also completely re-write the section. 

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

MGLT: REQ 17 corresponds to REQ 16 of the draft-mglt-security-environment-reqs-00. It is unclear. I removed the term origin and distinguish two cases one when the access control is made for the I2RS Client and one for the application. The text of the whole section has been updated and hopefully clarified. The term origin and component have been removed and replaced explicitly by Application, I2RS Client or I2RS Agent or identity. 

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

MGLT: component is unclear and has been removed.

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.

MGLT: component is unclear and it has been removed.

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.

MGLT: This section is too redundant with I-D.hares-i2rs-auth-trans. 
The main message was that local policies enforcement is not sufficient, and communications between points should be considered secured. This has been added in the Access Control architecture sub section. In addition, we added how transport and access control interact in the access control section. 
 
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.

MGLT: We explicitly specify the case of multiple applications.


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?

MGLT: The agent and client are expected to monitor, log, and eventually send alerts. The management plane is responsible in collecting and taking the appropriated decisions like updating Access Control policies, reconfiguring routing elements...)

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

-----Original Message-----
From: Daniel Migault 
Sent: Friday, August 21, 2015 9:29 PM
To: Joel Halpern; Russ Housley; [e-mail]; [e-mail]
Cc: Stephen Farrell; Kathleen Moriarty; IETF SecDir
Subject: RE: Early SecDir Reviews

Hi, 

Thank you Russ for the review. We can easily adapt inputs from the review for  draft-mglt-i2rs-security-environment-reqs-00.

BR, 
Daniel



-----Original Message-----
From: Joel Halpern [mailto:[e-mail]] 
Sent: Friday, August 21, 2015 6:13 PM
To: Russ Housley; [e-mail]; [e-mail]
Cc: Stephen Farrell; Kathleen Moriarty; IETF SecDir
Subject: RE: Early SecDir Reviews

There was confusion about the draft targets.  The last call was issued for the wrong name, but with the right URL for the environment document.  

The right environment document is draft-mglt-i2rs-security-environment-reqs-00

I expect that most of your concerns will still apply, but it would be helpful if you could check.

Yours,
Joel

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Friday, August 21, 2015 6:10 PM
To: [e-mail]; [e-mail]
Cc: Stephen Farrell; Kathleen Moriarty; IETF SecDir
Subject: Early SecDir Reviews

Please fine the requested SecDir reviews.

Russ