On Tue, Jun 24, 2014 at 09:50:24AM -0400, Jeffrey Haas wrote: > > If you were paying specific attention to the security issues, please also > review the security draft. >
I have been trying to read draft-hares-i2rs-security-01.txt and to match it against draft-ietf-i2rs-architecture-04.txt and I have come to the solution that we should - stop work draft-hares-i2rs-security-01.txt and - merge all statements from this I-D that are worth keeping and that are not yet part of draft-ietf-i2rs-architecture-04.txt into draft-ietf-i2rs-architecture-04.txt. There are numerous places where I the documents are inconsistent and this should be avoided if all possible and one way of doing this is make sure there is only one document talking about I2RS security 'architecture'. And I do not see a convincing point why the I2RS security 'architecture' should not be sufficiently defined in the I2RS architecture - in fact I see many good reasons why the whole I2RS architecture should be in one document. To substantiate my position, I will list several examples that make me concerned. But note that this list is not complete. * I am concerned about MUST statements in the security document that I do not find in the architecture document. Or, if these MUST statements are already in the architecture document, then there is no point in repeating them in the security document. * I am concerned about definitions such as Role in the security document that I do not find in the same meaning in the architecture document. Furthermore, I am worried about terms like 'routing tree' that are not well defined in the security document and do not exist in the architecture document. I note that the definition of Role is actually inconsistent even within the security document (e.g., 3.3. and 3.1). * There are concepts in the security document like I2RS identity repositories that I do not find in the I2RS architecture. * The section 3.2 of the security document gives guidelines that on things like that with symmetric keys, "sequence numbers which increase monotonically could be useful to help distinguishing replayed messages". I believe this goes way beyond _architectural_ concerns and worse it kind of implies that I2RS may invent their security protocol instead of using one of the already available and well understood security protocols we have. * Section 3.3. is messing up the separation of communication security and access control. Furthermore, the advice given that data model writers should consider whether a client / agent is valid is IMHO wrong. It is wrong to encode authorization policies into data models. The security policy must be configurable at runtime by a security administrator. There needs to be a separation of policy from mechanism. * Similar as above, the advice in section 3.4. that IM/DM writers "must discuss determine" whether encryption is a recommendation or requirement is wrong. It is the job of the security administrator deploying I2RS to answer those questions. All the IM/DM writer can reasonably do is to provide guidelines what in particular may need protection (this is what we are doing for ~20 years for MIB modules). * My understanding is that so called "stacked I2RS agent-clients in broker topologies" are left out of scope in the architecture. Why do such things pop up in the security architecture? What is the point of having an I2RS architecture with a certain scope and then an I2RS security architecture with a bigger scope? Bottom line is that I strongly prefer if all the security aspects of the I2RS architecture are covered in the document that defines the I2RS architecture. /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
