Re: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

> On Jun 1, 2016, at 12:32 PM, Stephen Farrell <[e-mail]> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-clue-data-model-schema-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> There may be no change needed here, but I want to check.
> This draft defines no security mechanisms and doens't say
> how to interoperably use any security mechanisms. For
> example, I don't understand how one might (interoperably)
> do RBAC or other "advanced" security mechanisms that are
> promised in other CLUE documents. [1] Even worse, I don't
> get how one could e.g. use XMLENC to encrypt parts of the
> schema here, as that'd (I think) almost certainty have to
> have been considered in the design of this schema, but
> there's no evidence of that. That seems to end up meaning
> that the only security mechanisms that one can use with
> CLUE and for which one can currently achieve interop are
> transport security mechanisms. That all seems to conflict
> with text in the security consideration of the CLUE
> protocol draft. So my question to discuss is: other than
> transport security, what interoperable security
> mechanisms are expected to be defined in CLUE, and where
> might I find descriptions of those?

Note there was no [1] anywhere else in your ballot, but I’m assuming you are referencing https://tools.ietf.org/html/draft-ietf-clue-protocol-08#section-10 <https://tools.ietf.org/html/draft-ietf-clue-protocol-08#section-10>. If not, please correct me.

So, the text in that section of the protocol draft is quite new and is still under discussion in the WG. One of the points of discussion surrounds whether to take the RBAC paragraph out:

https://www.ietf.org/mail-archive/web/clue/current/msg04859.html <https://www.ietf.org/mail-archive/web/clue/current/msg04859.html>
https://www.ietf.org/mail-archive/web/clue/current/msg04863.html <https://www.ietf.org/mail-archive/web/clue/current/msg04863.html>

In any event, I do not expect there to be any further mechanisms defined in CLUE to support what is written there. The expectation is that implementations can use SIP security mechanisms to establish sessions with other participants authorized to receive CLUE information, and they can use transport encryption to protect CLUE information in flight. WG folks should feel free to correct me but there has been no discussion of any kind of finer-grained protections applied to individual schema elements AFAIK.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - section 25 says: "Indeed, authenticated access is
> strongly advisable, especially if you convey information
> about individuals (<personalInfo>)..." I don't get the
> logic there - it seems incorrect actually. Personal data
> usually implies  a need for confidentiality and not
> authenticated access - what was meant here? Are you using
> the term authenticated access to mean more that it does?
> (to this reader:-)
> 

Perhaps this would have been clearer if it said “authentication” rather than “authenticated access.” I think the point here is that it is advisable to authenticate the remote endpoint before sending a CLUE message containing <personalInfo> to that endpoint, in the same way it’s advisable to authenticate it before sending media to it.

Alissa

>