Re: [i2rs] WG adoption - draft-hares-i2rs-auth-trans-04 (8/17 to 8/31)

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

NETCONF and I2RS mail group: 

 

http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/

 

Russ Housley, a member of the security directorate, kindly provided reviews
for this document, and the document has been changed in response to this
review to a version -05.   I believe these document addresses all of NETCONF
WG questions from IETF 93.  There are three sections below: 

1)      Specific response to NETCONF questions/concerns, 

2)      Why identity has been changed to Identifier in the draft, 

3)      New text for REQ-03, REQ-04, and REQ-10 which Juergen found was
confusing. 

 

I want to thank Juergen and Russ for their excellent reviews. 

 

Sue Hares 

 

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

NETCONF Concerns at IETF 93  

1)      Requirement 8 - is a security requirement.  

 

>> = Sue  

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

 

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

 

2)      Requirement 12 is a security requirement for the protocol.

 

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

>Yes.  For example, the IKE cookie mechanism is only there to make it much
more

> expensive the an attacker to implement DDoS.  They can't fire and forget.
They need to 

> keep state and hang around for at least 1.5 round trips.

 

3)      Multiple message sequences do not belong in protocols [section
2.4.1] 

 

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

 

4)      Why support an insecure protocol? 

>> [Sue] Are you Ok with REQ-09 specifying a non-secure transport as an
option? 

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

 

Editorial: 

1)      Russ agreed that Requirement 3 and 4 - were unclear, 

2)      Russ agreed that requirement 10 was ambiguous. 

 

These requirement have been rewritten.  (see below).

 

Other changes 

Joel suggested that "identity" is better stated as Identifier, and I agree.
This change has been made through-out the document.

 

 

Changes to requirements 3, 4, and 10 



   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

      identifier.

 

   o  SEC-REQ-04: The I2RS client, upon receiving an I2RS message from

      an I2RS agent, MUST confirm the I2RS agent's identifier .




   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 [RFC4107] 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 have these requirements.  An
   I2RS data model must indicate which portions can be served by manual
   key management.