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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
