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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jul 21, 2015 at 04:35:05AM -0400, Susan Hares wrote:
> 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.

I believe NETCONF/RESTCONF cover these two so I did not comment. I only
commented on things where I found the document unclear.
 
> b) On SEC-REQ-03 and SEC-REQ-04, if you feel these are badly worded - can
> you suggest new text or a refinement?

I happy leave this to I2RS people.

> 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
 
I do not consider them critical to address, see above.

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

I think it is up to you to explain to me or the WG why you think 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.

I am not accepting anything. NETCONF and RESTCONF always work over a
secure transport. I do question that running I2RS over an unsecure
transport will fly high in the security area but up to you to figure
this out.

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

I said 'key' is ambiguous. I like you to clarify what you mean with
SEC-REQ-10.
 
> On SEC-REQ-11, can you tell me if you considered or review this requirement?

I read the whole document. I don't see a problem with this except that
I have a hard time to believe a non-secure transport will fly.

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

I have no clue how you measure whether a protocol has DDoS
protection. RESTCONF, for example, is running over HTTP. What is
HTTP's DDoS protection? NETCONF runs over SSH. What is SSHs DDoS
protection? The point is that DDoS protection must happen way before
NETCONF / RESTCONF interactions start.

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

Again, NETCONF and RESTCONF always run over a secure transport and
hence the requirements are met. Having these requirements for a
non-secure transport seems odd to me (because addressing them would
turn the non-secure transport into a secure transport) but this is
I2RS business to work out.

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

I can't provide the reasoning.

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

I said I fail to see why this belongs into the security requirements
document.

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

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