Given the level of maturity of the security draft, that we put into the architecture draft what we think is good guidance without selecting existing mechanisms, and that we are trying to finish the architecture draft, do you really see aspects missing and if so, precisely what, around the security section?
I don't want to confuse cherry-picking the parts that are needed from an immature draft with information that is missing from the architecture. IMHO, we will need a draft that talks about what protocols can meet the requirements, whether there is a mandatory-to-implement, and so on. That draft may or may not be what the efforts at the security draft matures into. Regards, Alia On Wed, Jun 25, 2014 at 9:51 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > 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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
