Re: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt

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

Juergen: 

Thank you for your review.  In order to make progress on this review, would
you kindly tell me: 

a) Why you did not make any comment on REQ 01 and REQ 02?  Did you consider
these to not have any relationship to the NETCONF/RESTCONF? 

SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least
one unique identifier that uniquely identifies each party.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
mutual identification of the I2RS client and I2RS agent.

b) On SEC-REQ-03 and SEC-REQ-04, if you feel these are badly worded - can
you suggest new text or a refinement? 

c) On SEC-REQ-05, SEC-REQ-06, SEC-REQ-07 why you did not make any comment?
Did you consider these outside the NETCONF? 

SEC-REQ-05: Identity distribution and the loading of these
identities into I2RS agent and I2RS Client SHOULD occur outside
the I2RS protocol.
o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
or private) will distribute or load identities so that the I2RS
client/agent has these identities prior to the I2RS protocol
establishing a connection between I2RS client and I2RS agent.

o SEC-REQ-07: Each Identity MUST be linked to one priority

d) On SEC-REQ-08: Can you explain why you do not feel this is a security
requirement? 

e) On SEC-REQ-09: Did you accept this requirement? 

SEC-REQ-09: The data security of the I2RS protocol MUST be able to
support transfer of the data over a secure transport and optionally
be able to support a non-security transport. A security transport is
defined to have the qualities of confidentiality, has message
integrity, prevents replay attack, and supports end-to-end integrity
of the I2RS client-agent session.

On SEC-REQ-10: There are many ways to key between two entities.  These
include pre-shared keys and master-key.   Is there better language you wish
to suggest?  Would you like an list of these key algorithms.  What
specifically are you stating regarding the key? 

On SEC-REQ-11, can you tell me if you considered or review this requirement?


On SEC-REQ-12, can you tell me why you felt the requirement to have a
protocol that mitigated DDoS attacks was not a valuable requirement?  Does
NETCONF not provide DDoS attacks?  Is there a reason why you felt this
requirement was not useful? 

On SEC-REQ-13, SEC-REQ-14, SEQ-REQ-15, SEC-REQ-16, SEC-REQ-18, SEQ-REQ-19,
SEC-REQ-20, 
Can you tell me if as a NETCONF Expert - what your review is? 

On the allowing of an insecure connection, one of the requirements which I
inherited from my previous chairs - was the requirement for an insecure
connection for some transport.   Would you be willing to share your wisdom
as a past NETCONF advisor why the past chairs felt they should allow this
insecure connection. 

Section 2.4.1 was insert to address Andy Bierman's concerns regarding the
architecture document.  The SEC-REQ-17 for this section was removed so that
we could engage in a more substantive discussion.  So, can you provide any
more details to your comments other than "this is a mistake. 

Thank you again for your review of this document.  I look forward to
learning more about your thoughts regarding the security requirements for
the I2RS protocol.   If you did not review other sections of this document
and if you do not have time to review the other sections of this document
(see above), can you recommend someone else to review these sections. 

Any wording would aid me in providing this document.  I will revise the
document and do a WG adoption call. 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, July 20, 2015 6:19 PM
To: [e-mail]
Subject: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt

Hi,

I looked at this document from the perspective of NETCONF/RESTCONF and here
are some comments I wrote down while reading the document:

a) I assume the following two requirements are simply a bit badly
   worded but not harmful:

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

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

b) The point here is that for protocols that use a secure transport,
   authentication typically takes place when a secure transport is
   established and not when I2RS messages are received.

   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.

   Not really a security requirement I would say. Not sure it needs to
   stay in the security requirements document.

c) This part of SEC-REQ-10 is somewhat unclear:

      [...] In addition, the key management
      mechanisms need to be able to update the keys before they have lost
      sufficient security strengths, without breaking the connection
      between the agents and clients.

   It is unclear which keys are meant. Security protocols usually have
   keys to authenticate communicating parties, they typically generate
   a session master key and they usually derive the currently used
   encryption key from the session master key and they usually perform
   automated rekeying. If this refers to authentication keys, then key
   updates usually do not impact existing sessions.

d) It remains unclear what that following means in practice:

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

e) I find it kind of surprising that the security requirements
   document allows for non-secure channels. This should be checked
   with the security directorate.

f) Section 2.4.1 seems to be a misplaced protocol requirement - this
  is pretty much unrelated to security from what I can tell.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs