Re: [secdir] Security directorate

[Alia Atlas <[e-mail]>]

Hi Stephen,

Thanks very much for doing this review.

On Thu, Dec 18, 2014 at 10:59 AM, Stephen Kent <[e-mail]> wrote:

>  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 sad answer is that it depends on what data is being sent.  For
instance, I can see counters or events not requiring confidentiality
(depending) but some things being written or responses might require
confidentiality.
I've added in
" Some communications will also require confidentiality."
at the end of the Secure Control bullet.


 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've updated the Security Considerations section to:

"Security is a key aspect of any protocol that allows state
      installation and extracting of detailed router state.  The need
      for secure control is mentioned in Section 5.  More architectural
security
      considerations are discussed in <xref
      target="I-D.ietf-i2rs-architecture"/>.  Briefly, the I2RS Agent
      is assumed to have a separate authentication and authorization
      channel by which it can validate both the identity and the
      permissions associated with an I2RS Client.  Mutual
      authentication between the I2RS Agent and I2RS Client is
      required.  Different levels of integrity, confidentiality, and
      replay protection are relevant for different aspects of
      I2RS."


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.
>

fixed


Thanks again,
Alia