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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 01 Jun 2016 12:32:24 -0700

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?

----------------------------------------------------------------------
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:-)

---

From: [email-masked]
Date: Wed, 1 Jun 2016 15:55:18 -0400

Sent from my iPhone

> On Jun 1, 2016, at 3:32 PM, Stephen Farrell <[email-masked]> wrote:
> 

I had the same trouble and agree with  your discuss point.

Thanks,
Kathleen

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jun 2016 14:18:48 -0700

> On Jun 1, 2016, at 12:32 PM, Stephen Farrell <[email-masked]> wrote:
> 

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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Jun 2016 22:31:45 +0100

Hiya,

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

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 2 Jun 2016 00:45:43 +0200

Hello everybody,

> 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 establi…

Indeed! Your summary looks perfect to me. 

> 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 sendin…

Agreed.

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/