Subject: [secdir] Early SecDir Reviews

From: Russ Housley <[email-masked]>
Date: Fri, 21 Aug 2015 18:09:48 -0400

Please fine the requested SecDir reviews.

Russ

---

From: Joel Halpern <[email-masked]>
Date: Fri, 21 Aug 2015 22:12:53 +0000

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:[email-masked]] 
Sent: Friday, August 21, 2015 6:10 PM
To: [email-masked]; [email-masked]
Cc: Stephen Farrell; Kathleen Moriarty; IETF SecDir
Subject: Early SecDir Reviews

Russ

---

From: Daniel Migault <[email-masked]>
Date: Sat, 22 Aug 2015 01:29:03 +0000

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:[email-masked]] 
Sent: Friday, August 21, 2015 6:13 PM
To: Russ Housley; [email-masked]; [email-masked]
Cc: Stephen Farrell; Kathleen Moriarty; IETF SecDir
Subject: RE: Early SecDir Reviews

Yours,
Joel

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

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 23 Aug 2015 00:15:23 -0400

Russ:

Thank you for the quick action on the sec-dir reviews.  I will see if these
answer the questions.   If not, may I ask you more questions? 

Sue 

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

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 23 Aug 2015 12:19:48 -0400

> answer the questions.   If not, may I ask you more questions?

I'm please to answer your questions.

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Aug 2015 14:10:23 -0400

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:[email-masked]] 
Sent: Friday, August 21, 2015 6:10 PM
To: [email-masked];

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Aug 2015 15:15:26 -0400

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:[email-masked]] 
Sent: Monday, August 24, 2015 2:10 PM
To: 'Russ Housley'; [email-masked]';
[email-masked]'
Cc: 'Stephen Farrell'; 'Kathleen Moriarty'; 'IETF SecDir'
Subject: RE: Early SecDir Reviews

Russ: 

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

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: 

--------------------

in this >document.

-----
These requirements align with the description of the I2RS architecture found
in [I-D.ietf-i2rs-architecture]. 
===========

===============

>(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:[email-masked]]
Sent: Friday, August 21, 2015 6:10 PM
To: [email-masked];

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Aug 2015 15:27:26 -0400

>      applications in the secondary identifier.

Yes, if that identity is going to be used to make the access control decision.

>   mechanisms that mitigate DoS attacks

Yes.  For example, the IKE cookie mechanism is only there to make it much more expensive the an attacker ti implement DDoS.  They can't fire and forget.  They need to keep state and hang around for at least 1.5 round trips.

> multiple messages is not a security issue, but a implementation issue.  If

There might be some protocol issues to assist keep things atomic, but I agree it i not a security issue.

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

The security considerations need to be clear what the consequences are if this option is selected.

Russ

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Aug 2015 21:40:28 +0200

Just a minor note to the draft authors: Identity is an overloaded term
and most likely you mean identifier. If you really believe you mean
identity then check it against the definition in RFC 6973.

---

From: Joel Halpern <[email-masked]>
Date: Mon, 24 Aug 2015 20:05:26 +0000

Hannes is probably correct that we mean identifier, not identity, in almost all cases in the document.

In particular, regarding primary and secondry identifier, the secondary identifier is NOT used for any security decisions.  Access control is based only on the primary identifier.

Yours,
Joel

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 3:27 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Stephen Farrell'; 'Kathleen Moriarty'; 'IETF SecDir'
Subject: Re: Early SecDir Reviews

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

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

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Aug 2015 16:43:21 -0400

Russ:

Thank you for the answers.   NETCONF had asked specifically regarding these
issues. 

On SEC-REQ-09, I2RS WG participants suggested that non-secure transport be
used for publishing telemetry data that was specifically indicated to
non-confidential in the data model.    The configuration of  all aspects of
the I2RS agent from the I2RS client would be done over a secure transport.
The passing of most operational status would be done over a secure
transport.  We even suggested that the data models should clearly annotate
what type of transport the data should be passed over (secure or insecure). 

Where do you think it makes sense to put this type of explanation - near
SEC-REQ-09 or in the security considerations section? 

Sue 

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 3:27 PM
To: Susan Hares
Cc: [email-masked];
[email-masked]; 'Stephen Farrell'; 'Kathleen
Moriarty'; 'IETF SecDir'
Subject: Re: Early SecDir Reviews

>      applications in the secondary identifier.

Yes, if that identity is going to be used to make the access control
decision.

>   mechanisms that mitigate DoS attacks

Yes.  For example, the IKE cookie mechanism is only there to make it much
more expensive the an attacker ti implement DDoS.  They can't fire and
forget.  They need to keep state and hang around for at least 1.5 round
trips.

> implementation issue.  If so, Please let me know.

There might be some protocol issues to assist keep things atomic, but I
agree it i not a security issue.

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

The security considerations need to be clear what the consequences are if
this option is selected.

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Aug 2015 16:45:45 -0400

Russ: 
 
Do think that identifier is a better use like Joel suggested? 

Sue 

-----Original Message-----
From: Joel Halpern [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 4:05 PM
To: Russ Housley; Susan Hares
Cc: [email-masked];

Hannes is probably correct that we mean identifier, not identity, in almost
all cases in the document.

In particular, regarding primary and secondry identifier, the secondary
identifier is NOT used for any security decisions.  Access control is based
only on the primary identifier.

Yours,
Joel

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, August 24, 2015 3:27 PM
To: Susan Hares
Cc: [email-masked];

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Aug 2015 17:42:44 -0400

Russ and sec-dir: 

Thank you for reviewing the drafty-drafts. 

In the review of the I2RS architecture, several security issues were raised.
In order to tie down the I2RS architecture document, I progress forward with
these two drafts to indicate our direction. 

Do the two drafts (in a draft-y-draft) address the necessary security
issues? Or do we still have major points to dig into?  

Thank you, 

Sue Hares

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 6:10 PM
To: [email-masked];

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Aug 2015 17:49:42 -0400

Sue:

I think you are asking if there are additional topics that need to be covered.  I did not notice any.  Although there was question raised in response to my review about the distinction between identity and identifiers.  Sorting that out might raise new things.

Russ

On Aug 27, 2015, at 5:42 PM, Susan Hares wrote:

> Please find the requested SecDir reviews.
> 
> Russ
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Aug 2015 17:54:22 -0400

Russ:

I uploaded a new version of draft-hares-i2rs-auth-trans-05 with the
identities changed to identifiers.  I hope this new draft resolves all the
issues with draft-hares-i2rs-auth-trans-04. 

Sue 

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, August 27, 2015 5:50 PM
To: Susan Hares
Cc: [email-masked];
[email-masked]; 'Stephen Farrell'; 'Kathleen
Moriarty'; 'IETF SecDir'; 'Jeffrey Haas'
Subject: Re: Early SecDir Reviews

Sue:

I think you are asking if there are additional topics that need to be
covered.  I did not notice any.  Although there was question raised in
response to my review about the distinction between identity and
identifiers.  Sorting that out might raise new things.

Russ

On Aug 27, 2015, at 5:42 PM, Susan Hares wrote:

> In order to tie down the I2RS architecture document, I progress 
> forward with these two drafts to indicate our direction.
>