Re: [mile] Working group last call for ROLIE

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Hi Nancy,

Thanks for the review! I’ve put my comments inline. We’re also looking for WG feedback in general on our TLS requirement language.

-Stephen

From: mile [mailto:[e-mail]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, April 28, 2017 1:38 PM
To: [e-mail]
Subject: Re: [mile] Working group last call for ROLIE

Hi Steven,
I was able to get thru most of the draft though, I didn’t get to do a thorough review of Section 6 as I wanted to make sure I could get a first pass by today.  Here are some comments and questions based on my review of the ROLIE draft:
Section 1:
“Feeds” has had some errata updated in RFC 5988; it would be useful to reference that as well.

What do you mean by: “Through use of granular authentication and access controls,
   only authorized consumers may be permitted the ability to read or
   write to a given Feed.”
-       I believe that the “granular authentication and access controls” is “granular” as the consumer must authenticate directly to the particular HTTP-server hosting the Feed(s), is that correct?  Based on the example in Appendix B.1, a Feed maps to the availability of extracting a document (or information) type(s) but only from a particular/known resource (e.g. HTTP server).   But then, the consumer has to know all the potential resources to be able to query or “discover” what is available (e.g. Feeds), is that correct?

We had meant granular in the sense that each user could be authenticated on a workspace basis, collection basis, entry basis, etc; any given resource can be restricted.

Given that, I’m not sure the references to “point-to-point” that follow are quite correct….that is, one entity is talking directly to another (e.g. no multicast)


This should be covered along with the Section 4/1 changes.


Section 2:
Information Type definition includes: “…that is the subject of a security
      process that can be automated”
-       Can you clarify what is meant by or describe  what processes are automated beyond being able to interpret the data models as defined by the next set of drafts that further instantiate a ROLIE “Information Types”?

We updated the terminology section, hopefully it should make the definition here a little clearer.


Section 4: I agree with Charles’ that there are claims that am not sure apply.  The biggest benefit I see is that ROLIE instantiates an open model by which security information can be instantiated and shared.  But the transport (HTTPs) use is constrained and so is there a lack of general discovery of the resources available to disseminate security information.

Section 4.1:  I can see the ability to proactively share, but do not see it readily using the HTTPs protocol as it is inherently a client-server model.  While one can poll or block until a request is fulfilled, I don’t view that as really being a proactive model.
I am likely not interpreting the example correctly as it is somewhat vague. The example seems to indicate a level of indirection or inference that there is some overarching methodology by which a “search” to all available resources or feeds thru representation to include all the appropriate links to the resources?

Section 4.2: Is the intent of this section to highlight availability of different types of information that can be correlated (or aggregated)? As implied in the 1st paragraph or is it about the need to Federate information mentioned in the last paragraph?
[nit] The middle paragraph should use either “management system” or “monitoring system”.

Section 4.3: I perceive the intent of this section is to highlight that the architecture enables a producer to disclose information to consumers and potentially “filter” either based on the access control/authorization of the information elements or the particular consumer (or both).  Similarly, a consumer can choose which Feeds to tap into.
That is independent of how the data is stored (e.g. data repository).  My suggestion is to use the notion of “discovering available information” (or information types) vs. “repositories”.


We’ve condensed and refocused this section of the document, I believe that the edits should satisfy most of these comments.


Section 5.1.1: “repository” is really the “collection of security information” and suggest that the term not be used in this context as “repository” has storage implications and considerations which imho are more to an implementation detail.  I believe ROLIE is defining the data organization for carrying security info.
-       The first bullet, if it is private, why disclose it at all?   If the intent is to enable disclosure of some information to authorized parties or based on access controls, then it is really not private.  So, I am not sure why this is needed?
ۍ      The second bullet makes sense, but then is this a recommendation that drafts providing “Information Types” MUST provide these conventions?


On “repository”, we agree that this word has some baggage with it and implies something about the implementation. We’ve gone through and changed the word throughout the document. Workspace (or other resource) disclosure is a choice left up to the implementation/configuration, workspaces (or other resources) that a user does not have access to can be either hidden or just locked away. We’ve made some edits to the second bullet and condensed it, this should hopefully address your concern here.


Section 5.3: Given that TLS just published version 1.3, I am not sure that a MUST to “most recent” is warranted as new versions will be forthcoming and will break this requirement to implementations that may take time to update to “most recent”.  This is a SHOULD, but can mandate minimum version (e.g. 1.2 or 1.3 for now?)

-       Shouldn’t ROLIE enforce a MUST on mutual authentication?  Suggest rewording to one sentence if intent is to “MUST mutually authenticate using x.509 certificates”
-       If the intent is a MUST to use certs, could that be prohibitive as now certificate management could be a barrier for adoption?
-       What if OCSP is used? Is that not allowed given that RFC5280 is


We would like to ensure that a more recent version is used, but we also worry that “most recent” is too strict. Does anybody have some recommendations (or examples from other specs) on dealing with this version issue? Some wording around specifying the minimum version could be helpful.


Section 5.4: Is there a distinction between a (human) user vs. an application wanting to authenticate to a server?


No, they should be treated in the same way.


Section 9:
There should be considerations for the Service Discovery as well.
There should be considerations for the confidentiality and integrity of the information as the data is in motion (no need for storage considerations).
Given that Section 5.3 has a MUST for certificates, I am not connecting the notion of the federation tie?  This paragraph should be placed in its own section but the Security considerations should discuss the security implications of enabling the federation.

General: given the nature of sharing information, there should be a section that speaks to the Privacy considerations for both the act of sharing information as well as the discovery mechanism.


Agreed, I’ll add some text talking about service discovery, and a privacy considerations sections.


Overall I think the draft reads well and is close to shepherding thru ☺

Regards, Nancy

From: mile <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, March 28, 2017 at 4:27 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [mile] Working group last call for ROLIE

Colleagues,

Given the significant changes made to the last draft, we are doing another 30day WGLC for
https://tools.ietf.org/html/draft-ietf-mile-rolie-06

Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Regards, Nancy