Re: [secdir] Security directorate

[Stephen Kent <[e-mail]>]

SECDIR early review of draft-ietf-i2rs-problem-statement-04

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 with the intent of improving security 
requirements and considerations in IETF drafts. Comments not addressed 
in last call may be included in AD reviews during the IESG 
review.Document editors and WG chairs should treat these comments just 
like any other last call comments.

This is a short document describing the problem being addressed by the 
I2RS WG, and establishing some requirements for solutions.

Section 2 describes the model for I2RS. It calls for using existing 
transport protocols to provide security, a good statement as part of the 
base protocol requirements. Looking at Figure 1, it seems that the only 
paths that are in scope for I2RS are between an I2RS agent and client 
and between clients.

In section 5, authentication, authorization, and integrity are 
explicitly cited as requirements. This is a good statement of 
requirements. It might be nice to state whether confidentiality is also 
perceived as a requirement, or if it explicitly not a requirement.

The Security Considerations section is a single paragraph consisting of 
2 sentences. It opens with a nice statement about the importance of 
security in the I2RS context. I think a back pointer to the “secure 
Control” text would be appropriate. The second sentence says that more 
investigation is needed to fully define security requirements such as 
authorization and authentication levels. I don’t know what this last 
phrase means. Authorization (aka access control) isn’t usually described 
as having levels per se. Do you mean granularity of access control, or 
something else. Also, for authentication, there are various mechanisms 
one can employ, and these may be described as offering varying “levels” 
of security, but that is an oversimplification in many cases. A clearer 
description of what the authors are trying to convey here would be good.


I also looked briefly at draft-hares-i2rs-security-02. That document 
begins with a very good discussion of security terminology based on RFC 
4949. It also proposes very specific security requirements for 
communications in the I2RS model. That document calls for 
confidentiality as a requirement, which further motivates some mention 
of this security service in the problem statement, even if the statement 
is equivocal.

Two typos I noted:

Section 2: measuresments -> measurements

Section 5:

Such communications must also have its integrity protected. ->

Such communications must also be integrity-protected.