Re: [secdir] Early SecDir Reviews

["Susan Hares" <[e-mail]>]

Russ: 

I've attached the revised draft-hares-i2rs-auth-trans.txt plus a diff file
to let you see the changes.  I still the following 4 questions answered.  

Thank you, 

Sue 

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Monday, August 24, 2015 2:10 PM
To: 'Russ Housley'; '[e-mail]';
'[e-mail]'
Cc: 'Stephen Farrell'; 'Kathleen Moriarty'; 'IETF SecDir'
Subject: RE: Early SecDir Reviews

Russ: 

Thank you for your excellent review.   Below I've included a description of
the changes to the document.   However, I have a few additional questions: 

1) Is REQ-8 a security requirement? 

   o  SEC-REQ-08: Each Identity is associated with one secondary
      identity during a particular read/write sequence, but the
      secondary identity may vary during the time a connection between
      the I2RS client and I2RS agent is active.  The variance of the
      secondary identity allows the I2rs client to be associated with
      multiple applications and pass along an identifier for these
      applications in the secondary identifier.

2) Is REQ-12 - a security requirement for a protocol?  NETCONF asked this of
I2RS. 

   SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
   mechanisms that mitigate DoS attacks

3) Section 2.4.1 - is a description of the what happens when multiple
changes occur via multiple messages.  

My understanding from your question is that the implementation of how an
I2RS Agent processes the changes (change1, change2, change3) that occur in
multiple messages is not a security issue, but a implementation issue.  If
so, Please let me know. 

4) Are you Ok with REQ-09 specifying a non-secure transport as an option? 

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

Here's the changed text
Added: 
---------
Data Integrity - RFC4949:  states data integrity includes 1. (I)The property
that data has not been changed, destroyed, or 2. (O) "The property that
information has not been modified or  destroyed in an unauthorized manner." 

I2RS protocol data integrity:  The transfer of data via the  I2RS protocol
has the property of data integrity described in [RFC4949].   
--------------

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.

How about this change: 
   o  SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a
      I2RS client, MUST confirm that the I2RS client has a valid identity.

   o  SEC-REQ-04: The I2RS client, upon receiving an I2RS message from an
      I2RS agent, MUST confirm the I2RS agent's identity.

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

Thank you for pointing out BCP107 applies: 
Would this change be acceptable for SEC-REQ-10?  Or should some of this go
into the security considerations? 
===========
SEC-REQ-10: A secure transport MUST be associated with a key management
solution that can guarantee that only the entities having sufficient
privileges can get the keys to encrypt/decrypt the sensitive data.  Per
BCP107, this key management system SHOULD be automatic, but MAY BE manual if
the following constraints from BCP107:
a) environment has limited bandwidth or high round-trip times,
b) the information being protected has a low value and
c)  the total volume over the entire lifetime of the long-
      term session key will be very low,
d)  the scale of the deployment is limited. 

Most I2RS environments (I2RS Client - I2S Agents) will not have this
environment, but a few I2RS use case provide limited non-secure light-weight
telemetry messages that may support manual key management (E.g. pre-shared
keys).    An I2RS data model must indicate which portions can be served by
manual key management versus automatic  key management.  
============

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

I have removed section 2.4.1.  Please see my questions in the introduction. 

================================
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].
-----
These requirements align with the description of the I2RS architecture found
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

I will add these definitions
===========

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."
--done
========
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/ ==== Agreed to change. 

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