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

[Stephen Farrell <[e-mail]>]

Hiya,

On 01/06/16 22:18, Alissa Cooper wrote:
> 
>> 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.

Sorry, yes that's the bit.

> 
> 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.

Fair enough. RBAC and selective field confidentiality for bits
of this data model seemed a bit of a stretch goal to me too, but
I can imagine some situations where that would be wanted/needed.
If interop between a randomly chosen clue-device with such things
isn't a priority, that's not crazy. I'll clear the discuss anyway
and make this a comment.

But if folks do want to argue for such interop then we ought chat
about it. The selective field confidentiality thing in particular
would I think require some changes to this schema if one wanted
that kind of interop, so would be something it'd be way better to
talk about now and not punt until later. (Arguably, approving this
schema amounts to saying that selective-field-confidentiality won't
be supported for this version.)

> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
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.

I suppose. My guess was that maybe the authors were using it as
a short-hand for server-auth-TLS. If so, it might be better to
say that, but it's a nit really.

Cheers,
S.


> 
> Alissa
> 
>> 
> 
>