From nobody Fri May 6 06:55:38 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFE712D55C; Fri, 6 May 2016 06:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506135534.26329.32267.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 06:55:34 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-14.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 13:55:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-14.txt Pages : 73 Date : 2016-05-06 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 6 06:56:31 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281E312D197 for ; Fri, 6 May 2016 06:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vO_lvwGgvh6 for ; Fri, 6 May 2016 06:56:25 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E6312D545 for ; Fri, 6 May 2016 06:56:24 -0700 (PDT) X-ASG-Debug-ID: 1462542980-05f27568a43f3f50001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id foP8ujEO0h089gIF (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 06 May 2016 15:56:20 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.28.74]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u46DuGq5005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2016 15:56:17 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_8A721B22-720F-49D0-9030-647FDB212649" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 In-Reply-To: <142C7249-4732-4066-8A58-F28DD5C25A05@cooperw.in> Date: Fri, 6 May 2016 15:56:15 +0200 Message-Id: References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> <142C7249-4732-4066-8A58-F28DD5C25A05@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1462542980 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29352 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 13:56:29 -0000 --Apple-Mail=_8A721B22-720F-49D0-9030-647FDB212649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alissa, please find below our answers to your latest review (version -13 of the = draft)... > Thanks. I=E2=80=99ve reviewed the -13. Some responses below. >=20 >> On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano = wrote: >>=20 >>> (3) I think the explanation of each of the extensibility points in = the document needs to be clearer. Some of the elements are extensible = when I wouldn=E2=80=99t have expected them to be, and the document often = doesn=E2=80=99t explain why the model=E2=80=99s extensibility is being = specified as it is. For example, it=E2=80=99s not clear to me why the = content type or the capture scene type are extensible, and there=E2=80=99s= no explanation provided. For other types I can intuit why they are = extensible, but it would help to make it explicit.=20 >>=20 >> We wanted to offer people enough flexibility as to define custom (and = perhaps currently unforeseen) extensions to the schema, without losing = compliance with the standard. We did this by leveraging = elemenrts and attributes, which is a common approach = with schemas, still matching the UPA (Unique Particle Attribution) = Constraint. The "XML Schema extensibility=E2=80=9D section was meant to = illustrate the mentioned approach. >>=20 >>> (4) Furthermore, this data model seems to err way on the side of = extensibility, leaving me to wonder just how much it will really = facilitate interoperability. I think the trade-offs the WG is making = here need to be thoroughly justified in the text.=20 >>=20 >> See my answer above to your comment number (3). What would you = suggest to improve the way we deal with extensibility? >=20 > I think it would help to state in Section 14 that extensibility was = purposefully favored as much as possible based on expectations about = custom implementations.=20 OK. We added to section 14 the following couple of sentences: Elements or attributes from unknown namespaces MUST be ignored. = Extensibility was purposefully favored as much as possible based on = expectations about custom implementations. Hence, the schema offers = people enough flexibility as to define custom extensions, without losing = compliance with the standard. This is achieved by leveraging = elements and attributes, which is a common approach = with schemas, still matching the UPA (Unique Particle Attribution) = Constraint. >=20 >>> And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? >>=20 >> They are (or at least should be) indeed identical. I checked version = -06 of the protocol and version -12 of the data model and found the = following: >>=20 >> - Protocol: >>=20 >> CLUE Participant (CP): An entity able to use the CLUE protocol = within a telepresence session. It can be an endpoint or an MCU able to = use the CLUE protocol. >>=20 >> - Data Model: >>=20 >> This term is not imported from the framework terminology. A CLUE = Participant identifies a generic entity (either an Endpoint or a MCU) = making use of the CLUE protocol. >>=20 >> If we decide that such a definition can survive, we might proceed as = follows: (i) introduce it in the protocol draft; (ii) point to it in the = data model draft. What=E2=80=99s your feeling about that? >=20 > Good idea. Done. The CLUE Participant definition has been removed from the data = model and replaced with a reference to the protocol document. >=20 >>> =3D Section 11.2 =3D >>>=20 >>> "Common values are "audio", "video", >>> "text". Other values can be provided. It is assumed that >>> implementations agree on the interpretation of those other = values.=E2=80=9D >>>=20 >>> This seems like an interop problem waiting to happen, since there is = no registry specified for these values. Why not create one so that = independent implementers can at least know what other values may be = supported by other implementations? >>=20 >> I=E2=80=99m not sure I understand this point correctly. The idea here = was to be as generic as possible. That=E2=80=99s why: (i) the basic = media capture type is an abstract one; (ii) =E2=80=9Cconcrete=E2=80=9D = definitions for audio, video and text capture types have been specified; >=20 > Referencing the registry as Roni suggested would help. >=20 >> (iii) a 100% generic =E2=80=9CotherCaptureType=E2=80=9D type has = been defined; (iv) the =E2=80=9CmediaType=E2=80=9D attribute has been = generically defined as a string, with no particular template. >>=20 >> That=E2=80=99s why we assume that if one chooses to rely on a brand = new media type and wants to interoperate with others, an = (application-level) agreement is needed on how to interpret such = information. >=20 > If I=E2=80=99m an implementer and I want to start using some new media = type, it would be helpful for me to know if there are already other = implementations out there using that media type name before I decide = whether I want to risk collisions with however the attribute is already = being interpreted, or whether I want to name mine something different = and go negotiate what its interpretation should be. Not a huge deal and = we can see if anyone else raises this in IETF LC or IESG review, but = just an example where it seems like there could be a significant barrier = to achieving interop if people decide to use this extension point. We tried to summarize all of the above considerations (including = Roni=E2=80=99s suggestion) and arrived at the following re-wording of = Section 11.2. Please let us know what you think about it now: The "mediaType" attribute is a mandatory attribute specifying the media = type of the capture. Common standard values are "audio", "video", = "text", as defined in [RFC6838] = . Other values = can be provided. It is assumed that implementations agree on the = interpretation of those other values. The "mediaType" attribute is as = generic as possible. Here is why: (i) the basic media capture type is an = abstract one; (ii) "concrete" definitions for the standard ([RFC6838] = ) audio, video = and text capture types have been specified; (iii) a generic = "otherCaptureType" type has been defined; (iv) the "mediaType" attribute = has been generically defined as a string, with no particular template. = =46rom the considerations above, it is clear that if one chooses to rely = on a brand new media type and wants to interoperate with others, an = application-level agreement is needed on how to interpret such = information. >>=20 >>> =3D Section 11.23 =3D >>>=20 >>> "When defining new media capture types that are going to be = described >>> by means of the element, spatial properties of >>> such new media capture types SHOULD be defined (e.g., whether or not >>> they are spatially definable, whether or not they should be >>> associated with an area of capture, etc.).=E2=80=9D >>>=20 >>> Are there other spatial properties that should be defined besides = the two that are listed? If this is going to be a normative requirement, = the list should be precise. >>=20 >> What we wanted to state here is that a new media capture might = require the definition of spatial properties. In such a case, the = element would be present and would contain (at = least) either the capture origin, or the capture area, or both. The list = is not exhaustive, since, like all other pieces of information in the = schema, further elements and attributes can be added if needed = (extensibility). >=20 > Ok, I think you need something like > s/etc./or other properties that may be defined/ Done. >=20 >>> =3D Section 15 =3D >>>=20 >>> (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >>=20 >> Nothing meaningful, indeed :-). We meant something like = "full-fledged=E2=80=9D, =E2=80=9Cthoroughly specified=E2=80=9D, or = similar. What would you suggest here? >=20 > Either of those would work. Done (replaced with full-fledged). >=20 >> (2) "Data model information carried within CLUE messages SHOULD be = accessed only by authenticated endpoints.=E2=80=9D The exception cases = to this recommendation should be described. >>=20 >> We tried to highlight the fact that authenticated access is strongly = advisable, especially if you convey information about individuals = () and/or scenes (). There might be more = exceptions, depending on the level of criticality that is associated = with the setup and configuration of a specific session. In principle, = one might even decide that no protection at all is needed for a = particular session; that=E2=80=99s why we did not make this a MUST. >=20 > Ok, please add some text to explain what you explain above. Done. We added a short paragraph to the section, which states the = following: Indeed, authenticated access is strongly advisable, especially if you = convey=20 information about individuals (<personalInfo>) and/or scenes = (<sceneInformation>).=20 There might be more exceptions, depending on the level of criticality = that is associated=20 with the setup and configuration of a specific session. In principle, = one might even decide=20 that no protection at all is needed for a particular session; here is = why authentication has not been identified as a mandatory requirement.=20 > Thanks, > Alissa Thank you! Your feedback was really helpful. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_8A721B22-720F-49D0-9030-647FDB212649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alissa,

please find below our answers to your latest review (version = -13 of the draft)...

Thanks. I=E2=80=99ve reviewed the -13. Some responses = below.

On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano <spromano@unina.it> = wrote:

(3) I think the explanation of each of the extensibility = points in the document needs to be clearer. Some of the elements are = extensible when I wouldn=E2=80=99t have expected them to be, and the = document often doesn=E2=80=99t explain why the model=E2=80=99s = extensibility is being specified as it is. For example, it=E2=80=99s not = clear to me why the content type or the capture scene type are = extensible, and there=E2=80=99s no explanation provided. For other types = I can intuit why they are extensible, but it would help to make it = explicit.

We wanted to offer = people enough flexibility as to define custom (and perhaps currently = unforeseen) extensions to the schema, without losing compliance with the = standard. We did this by leveraging  <xs:any> elemenrts and = <xs:anyAttribute> attributes, which is a common approach with = schemas, still matching the UPA (Unique Particle Attribution) = Constraint. The "XML Schema extensibility=E2=80=9D section was meant to = illustrate the mentioned approach.

(4) Furthermore, this = data model seems to err way on the side of extensibility, leaving me to = wonder just how much it will really facilitate interoperability. I think = the trade-offs the WG is making here need to be thoroughly justified in = the text.

See my answer above = to your comment number (3). What would you suggest to improve the way we = deal with extensibility?

I = think it would help to state in Section 14 that extensibility was = purposefully favored as much as possible based on expectations about = custom implementations.

OK. We added to section 14 the following couple of = sentences:

Elements or = attributes from unknown namespaces MUST be ignored. Extensibility was = purposefully favored as much as possible based on expectations about = custom implementations. Hence, the schema offers people enough = flexibility as to define custom extensions, without losing compliance = with the standard. This is achieved by leveraging <xs:any> = elements and <xs:anyAttribute> attributes, which is a common = approach with schemas, still matching the UPA (Unique Particle = Attribution) Constraint.


And why is it stated differently than how = it=E2=80=99s stated in the protocol doc?

They are (or at least should be) indeed identical. I checked = version -06 of the protocol and version -12 of the data model and found = the following:

- Protocol:

CLUE Participant (CP):  An entity able to use the CLUE = protocol within a telepresence session.  It can be an endpoint or = an MCU able to use the CLUE protocol.

- = Data Model:

This term is not imported from = the framework terminology.  A CLUE Participant identifies a generic = entity (either an Endpoint or a MCU) making use of the CLUE protocol.

If we decide that such a definition can = survive, we might proceed as follows: (i) introduce it in the protocol = draft; (ii) point to it in the data model draft. What=E2=80=99s your = feeling about that?

Good = idea.

Done. = The CLUE Participant definition has been removed from the data model and = replaced with a reference to the protocol document.


=3D Section 11.2 =3D

"Common = values are "audio", "video",
"text".  Other values = can be provided.  It is assumed that
implementations = agree on the interpretation of those other values.=E2=80=9D

This seems like an interop problem waiting to = happen, since there is no registry specified for these values. Why not = create one so that independent implementers can at least know what other = values may be supported by other implementations?

I=E2=80=99m not sure I understand = this point correctly. The idea here was to be as generic as possible. = That=E2=80=99s why: (i) the basic media capture type is an abstract one; = (ii) =E2=80=9Cconcrete=E2=80=9D definitions for audio, video and text = capture types have been specified;

Referencing the registry as Roni suggested would help.

(iii) =  a 100% generic =E2=80=9CotherCaptureType=E2=80=9D type has been = defined; (iv) the =E2=80=9CmediaType=E2=80=9D attribute has been = generically defined as a string, with no particular template.

That=E2=80=99s why we assume that if one = chooses to rely on a brand new media type and wants to interoperate with = others, an (application-level) agreement is needed on how to interpret = such information.

If I=E2=80=99m= an implementer and I want to start using some new media type, it would = be helpful for me to know if there are already other implementations out = there using that media type name before I decide whether I want to risk = collisions with however the attribute is already being interpreted, or = whether I want to name mine something different and go negotiate what = its interpretation should be. Not a huge deal and we can see if anyone = else raises this in IETF LC or IESG review, but just an example where it = seems like there could be a significant barrier to achieving interop if = people decide to use this extension point.

We tried to = summarize all of the above considerations (including Roni=E2=80=99s = suggestion) and arrived at the following re-wording of Section 11.2. = Please let us know what you think about it now:

The "mediaType" = attribute is a mandatory attribute specifying the media type of the = capture. Common standard values are "audio", "video", "text", as defined = in [RFC6838]. Other values can be provided. It is assumed that = implementations agree on the interpretation of those other values. The = "mediaType" attribute is as generic as possible. Here is why: (i) the = basic media capture type is an abstract one; (ii) "concrete" definitions = for the standard ([RFC6838]) audio, video and text capture types have been specified; = (iii) a generic "otherCaptureType" type has been defined; (iv) the = "mediaType" attribute has been generically defined as a string, with no = particular template. =46rom the considerations above, it is clear that = if one chooses to rely on a brand new media type and wants to = interoperate with others, an application-level agreement is needed on = how to interpret such information.



=3D Section 11.23 =3D

"When defining new media capture types that are going to be = described
by means of the <otherMediaCapture> = element, spatial properties of
such new media capture = types SHOULD be defined (e.g., whether or not
they are = spatially definable, whether or not they should be
= associated with an area of capture, etc.).=E2=80=9D

Are there other spatial properties that should be defined = besides the two that are listed? If this is going to be a normative = requirement, the list should be precise.

What we wanted to state here is that a new media capture = might require the definition of spatial properties. In such a case, the = <spatialInformation> element would be present and would contain = (at least) either the capture origin, or the capture area, or both. The = list is not exhaustive, since, like all other pieces of information in = the schema, further elements and attributes can be added if needed = (extensibility).

Ok, I think = you need something like
s/etc./or other properties that = may be defined/

Done.


=3D = Section 15 =3D

(1) What does = =E2=80=9Cfull-optional=E2=80=9D mean?

Nothing meaningful, indeed :-). We meant something like = "full-fledged=E2=80=9D, =E2=80=9Cthoroughly specified=E2=80=9D, or = similar. What would you suggest here?

Either of those would work.

Done (replaced = with full-fledged).


(2) "Data model information carried within CLUE messages = SHOULD be accessed only by authenticated endpoints.=E2=80=9D The = exception cases to this recommendation should be described.

We tried to highlight the fact that = authenticated access is strongly advisable, especially if you convey = information about individuals (<personalInfo>) and/or scenes = (<sceneInformation>). There might be more exceptions, depending on = the level of criticality that is associated with the setup and = configuration of a specific session. In principle, one might even decide = that no protection at all is needed for a particular session; that=E2=80=99= s why we did not make this a MUST.

Ok, please add some text to explain what you explain = above.

Done. = We added a short paragraph to the section, which states the = following:

Indeed, = authenticated access is strongly advisable, especially if you = convey 
information about individuals (&lt;personalInfo&gt;) and/or scenes = (&lt;sceneInformation&gt;). 
There might be more = exceptions, depending on the level of criticality that is = associated 
with the setup and configuration of a = specific session. In principle, one might even decide 
that no protection at all is needed for a particular session; = here is why authentication
has not been identified as a = mandatory requirement. 

Thanks,
Alissa

Thank you! Your = feedback was really helpful.

Cheers,

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: spromano@unina.it

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






= --Apple-Mail=_8A721B22-720F-49D0-9030-647FDB212649-- From nobody Mon May 9 14:03:10 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5F12D0BC for ; Mon, 9 May 2016 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=NcIl6O6L; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=WwIZa6r2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujNZztHh8LG2 for ; Mon, 9 May 2016 14:03:05 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB39012B00A for ; Mon, 9 May 2016 14:03:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6433F20930 for ; Mon, 9 May 2016 17:03:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 09 May 2016 17:03:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=M6bSH DknNn+LMmeCw4L6MJSBoXg=; b=NcIl6O6LFhMx9lcVXF+VUbLI0P4EAjuGfd+5T pMBe/hA4tZ7znz/gZYmuZnc/1K8sdfVZeGIgx/5k1b6WqAuhaM93ioDsP3ac7237 UH/iUGIkzpzO99aG1S0Ky26uQie3CgR8cadBpaGrwIMZEhR+ccO/DmlKsJKtmuXK ulG+Vg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=M6bSHDknNn+LMmeCw4L6MJSBoXg=; b=WwIZa 6r2wM7uTOnNSSaZcY+maigwuWJ7zYjZ2h/mW+zHiGN9y78cBLKUJ4MhgoPH3mjSu sFkTfIXPSdKut6dFPxMeJW3okXEFaNw+si3VCRN1eHyUDMT/Te8mIaL4dbmYxIbN EvAAn6ybjVkY6qHuJVYrO+nKOquc1HbfaKFb9A= X-Sasl-enc: H9iXBEGLNm8GYDljwHXh7kdmh7mCeKrrStABj2vUYoSI 1462827783 Received: from [10.24.55.214] (unknown [128.107.241.188]) by mail.messagingengine.com (Postfix) with ESMTPA id A0C63C00022; Mon, 9 May 2016 17:03:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3193AB11-1802-49C5-944A-0E70CE205AAC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 9 May 2016 14:03:02 -0700 Message-Id: References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> <142C7249-4732-4066-8A58-F28DD5C25A05@cooperw.in> To: Simon Pietro Romano X-Mailer: Apple Mail (2.3124) Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 21:03:08 -0000 --Apple-Mail=_3193AB11-1802-49C5-944A-0E70CE205AAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks! I requested IETF last call. Alissa > On May 6, 2016, at 6:56 AM, Simon Pietro Romano = wrote: >=20 > Hi Alissa, >=20 > please find below our answers to your latest review (version -13 of = the draft)... >=20 >> Thanks. I=E2=80=99ve reviewed the -13. Some responses below. >>=20 >>> On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano > wrote: >>>=20 >>>> (3) I think the explanation of each of the extensibility points in = the document needs to be clearer. Some of the elements are extensible = when I wouldn=E2=80=99t have expected them to be, and the document often = doesn=E2=80=99t explain why the model=E2=80=99s extensibility is being = specified as it is. For example, it=E2=80=99s not clear to me why the = content type or the capture scene type are extensible, and there=E2=80=99s= no explanation provided. For other types I can intuit why they are = extensible, but it would help to make it explicit.=20 >>>=20 >>> We wanted to offer people enough flexibility as to define custom = (and perhaps currently unforeseen) extensions to the schema, without = losing compliance with the standard. We did this by leveraging = elemenrts and attributes, which is a common approach = with schemas, still matching the UPA (Unique Particle Attribution) = Constraint. The "XML Schema extensibility=E2=80=9D section was meant to = illustrate the mentioned approach. >>>=20 >>>> (4) Furthermore, this data model seems to err way on the side of = extensibility, leaving me to wonder just how much it will really = facilitate interoperability. I think the trade-offs the WG is making = here need to be thoroughly justified in the text.=20 >>>=20 >>> See my answer above to your comment number (3). What would you = suggest to improve the way we deal with extensibility? >>=20 >> I think it would help to state in Section 14 that extensibility was = purposefully favored as much as possible based on expectations about = custom implementations.=20 >=20 > OK. We added to section 14 the following couple of sentences: >=20 > Elements or attributes from unknown namespaces MUST be ignored. = Extensibility was purposefully favored as much as possible based on = expectations about custom implementations. Hence, the schema offers = people enough flexibility as to define custom extensions, without losing = compliance with the standard. This is achieved by leveraging = elements and attributes, which is a common approach = with schemas, still matching the UPA (Unique Particle Attribution) = Constraint. >=20 >>=20 >>>> And why is it stated differently than how it=E2=80=99s stated in = the protocol doc? >>>=20 >>> They are (or at least should be) indeed identical. I checked version = -06 of the protocol and version -12 of the data model and found the = following: >>>=20 >>> - Protocol: >>>=20 >>> CLUE Participant (CP): An entity able to use the CLUE protocol = within a telepresence session. It can be an endpoint or an MCU able to = use the CLUE protocol. >>>=20 >>> - Data Model: >>>=20 >>> This term is not imported from the framework terminology. A CLUE = Participant identifies a generic entity (either an Endpoint or a MCU) = making use of the CLUE protocol. >>>=20 >>> If we decide that such a definition can survive, we might proceed as = follows: (i) introduce it in the protocol draft; (ii) point to it in the = data model draft. What=E2=80=99s your feeling about that? >>=20 >> Good idea. >=20 > Done. The CLUE Participant definition has been removed from the data = model and replaced with a reference to the protocol document. >=20 >>=20 >>>> =3D Section 11.2 =3D >>>>=20 >>>> "Common values are "audio", "video", >>>> "text". Other values can be provided. It is assumed that >>>> implementations agree on the interpretation of those other = values.=E2=80=9D >>>>=20 >>>> This seems like an interop problem waiting to happen, since there = is no registry specified for these values. Why not create one so that = independent implementers can at least know what other values may be = supported by other implementations? >>>=20 >>> I=E2=80=99m not sure I understand this point correctly. The idea = here was to be as generic as possible. That=E2=80=99s why: (i) the basic = media capture type is an abstract one; (ii) =E2=80=9Cconcrete=E2=80=9D = definitions for audio, video and text capture types have been specified; >>=20 >> Referencing the registry as Roni suggested would help. >>=20 >>> (iii) a 100% generic =E2=80=9CotherCaptureType=E2=80=9D type has = been defined; (iv) the =E2=80=9CmediaType=E2=80=9D attribute has been = generically defined as a string, with no particular template. >>>=20 >>> That=E2=80=99s why we assume that if one chooses to rely on a brand = new media type and wants to interoperate with others, an = (application-level) agreement is needed on how to interpret such = information. >>=20 >> If I=E2=80=99m an implementer and I want to start using some new = media type, it would be helpful for me to know if there are already = other implementations out there using that media type name before I = decide whether I want to risk collisions with however the attribute is = already being interpreted, or whether I want to name mine something = different and go negotiate what its interpretation should be. Not a huge = deal and we can see if anyone else raises this in IETF LC or IESG = review, but just an example where it seems like there could be a = significant barrier to achieving interop if people decide to use this = extension point. >=20 > We tried to summarize all of the above considerations (including = Roni=E2=80=99s suggestion) and arrived at the following re-wording of = Section 11.2. Please let us know what you think about it now: >=20 > The "mediaType" attribute is a mandatory attribute specifying the = media type of the capture. Common standard values are "audio", "video", = "text", as defined in [RFC6838] = . Other values = can be provided. It is assumed that implementations agree on the = interpretation of those other values. The "mediaType" attribute is as = generic as possible. Here is why: (i) the basic media capture type is an = abstract one; (ii) "concrete" definitions for the standard ([RFC6838] = ) audio, video = and text capture types have been specified; (iii) a generic = "otherCaptureType" type has been defined; (iv) the "mediaType" attribute = has been generically defined as a string, with no particular template. = =46rom the considerations above, it is clear that if one chooses to rely = on a brand new media type and wants to interoperate with others, an = application-level agreement is needed on how to interpret such = information. >=20 >=20 >>>=20 >>>> =3D Section 11.23 =3D >>>>=20 >>>> "When defining new media capture types that are going to be = described >>>> by means of the element, spatial properties of >>>> such new media capture types SHOULD be defined (e.g., whether or = not >>>> they are spatially definable, whether or not they should be >>>> associated with an area of capture, etc.).=E2=80=9D >>>>=20 >>>> Are there other spatial properties that should be defined besides = the two that are listed? If this is going to be a normative requirement, = the list should be precise. >>>=20 >>> What we wanted to state here is that a new media capture might = require the definition of spatial properties. In such a case, the = element would be present and would contain (at = least) either the capture origin, or the capture area, or both. The list = is not exhaustive, since, like all other pieces of information in the = schema, further elements and attributes can be added if needed = (extensibility). >>=20 >> Ok, I think you need something like >> s/etc./or other properties that may be defined/ >=20 > Done. >=20 >>=20 >>>> =3D Section 15 =3D >>>>=20 >>>> (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >>>=20 >>> Nothing meaningful, indeed :-). We meant something like = "full-fledged=E2=80=9D, =E2=80=9Cthoroughly specified=E2=80=9D, or = similar. What would you suggest here? >>=20 >> Either of those would work. >=20 > Done (replaced with full-fledged). >=20 >>=20 >>> (2) "Data model information carried within CLUE messages SHOULD be = accessed only by authenticated endpoints.=E2=80=9D The exception cases = to this recommendation should be described. >>>=20 >>> We tried to highlight the fact that authenticated access is strongly = advisable, especially if you convey information about individuals = () and/or scenes (). There might be more = exceptions, depending on the level of criticality that is associated = with the setup and configuration of a specific session. In principle, = one might even decide that no protection at all is needed for a = particular session; that=E2=80=99s why we did not make this a MUST. >>=20 >> Ok, please add some text to explain what you explain above. >=20 > Done. We added a short paragraph to the section, which states the = following: >=20 > Indeed, authenticated access is strongly advisable, especially if you = convey=20 > information about individuals (<personalInfo>) and/or scenes = (<sceneInformation>).=20 > There might be more exceptions, depending on the level of criticality = that is associated=20 > with the setup and configuration of a specific session. In principle, = one might even decide=20 > that no protection at all is needed for a particular session; here is = why authentication > has not been identified as a mandatory requirement.=20 >=20 >> Thanks, >> Alissa >=20 > Thank you! Your feedback was really helpful. >=20 > Cheers, >=20 > Simon >=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it = >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_3193AB11-1802-49C5-944A-0E70CE205AAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks! I requested IETF last call.

Alissa

On = May 6, 2016, at 6:56 AM, Simon Pietro Romano <spromano@unina.it> = wrote:

Hi Alissa,

please find below our = answers to your latest review (version -13 of the draft)...

Thanks. = I=E2=80=99ve reviewed the -13. Some responses below.

On Mar 7, 2016, at 11:42 = AM, Simon Pietro Romano <spromano@unina.it> wrote:

(3) I think the = explanation of each of the extensibility points in the document needs to = be clearer. Some of the elements are extensible when I wouldn=E2=80=99t = have expected them to be, and the document often doesn=E2=80=99t explain = why the model=E2=80=99s extensibility is being specified as it is. For = example, it=E2=80=99s not clear to me why the content type or the = capture scene type are extensible, and there=E2=80=99s no explanation = provided. For other types I can intuit why they are extensible, but it = would help to make it explicit.

We wanted to offer people enough flexibility as to define = custom (and perhaps currently unforeseen) extensions to the schema, = without losing compliance with the standard. We did this by leveraging =  <xs:any> elemenrts and <xs:anyAttribute> attributes, = which is a common approach with schemas, still matching the UPA (Unique = Particle Attribution) Constraint. The "XML Schema extensibility=E2=80=9D = section was meant to illustrate the mentioned approach.

(4) Furthermore, this = data model seems to err way on the side of extensibility, leaving me to = wonder just how much it will really facilitate interoperability. I think = the trade-offs the WG is making here need to be thoroughly justified in = the text.

See my answer above = to your comment number (3). What would you suggest to improve the way we = deal with extensibility?

I = think it would help to state in Section 14 that extensibility was = purposefully favored as much as possible based on expectations about = custom implementations.

OK. We added to section 14 the following = couple of sentences:

Elements or attributes from unknown = namespaces MUST be ignored. Extensibility was purposefully favored as = much as possible based on expectations about custom implementations. = Hence, the schema offers people enough flexibility as to define custom = extensions, without losing compliance with the standard. This is = achieved by leveraging <xs:any> elements and = <xs:anyAttribute> attributes, which is a common approach with = schemas, still matching the UPA (Unique Particle Attribution) = Constraint.


And why is it stated differently than how = it=E2=80=99s stated in the protocol doc?

They are (or at least should be) indeed identical. I checked = version -06 of the protocol and version -12 of the data model and found = the following:

- Protocol:

CLUE Participant (CP):  An entity able to use the CLUE = protocol within a telepresence session.  It can be an endpoint or = an MCU able to use the CLUE protocol.

- = Data Model:

This term is not imported from = the framework terminology.  A CLUE Participant identifies a generic = entity (either an Endpoint or a MCU) making use of the CLUE protocol.

If we decide that such a definition can = survive, we might proceed as follows: (i) introduce it in the protocol = draft; (ii) point to it in the data model draft. What=E2=80=99s your = feeling about that?

Good = idea.

Done. The CLUE Participant definition has been removed = from the data model and replaced with a reference to the protocol = document.


=3D Section 11.2 =3D

"Common values are "audio", "video",
"text".  Other values can be provided.  It is = assumed that
implementations agree on the interpretation = of those other values.=E2=80=9D

This seems = like an interop problem waiting to happen, since there is no registry = specified for these values. Why not create one so that independent = implementers can at least know what other values may be supported by = other implementations?

I=E2=80=99= m not sure I understand this point correctly. The idea here was to be as = generic as possible. That=E2=80=99s why: (i) the basic media capture = type is an abstract one; (ii) =E2=80=9Cconcrete=E2=80=9D definitions for = audio, video and text capture types have been specified;

Referencing the registry as Roni = suggested would help.

(iii)  a 100% generic = =E2=80=9CotherCaptureType=E2=80=9D type has been defined; (iv) the = =E2=80=9CmediaType=E2=80=9D attribute has been generically defined as a = string, with no particular template.

That=E2=80= =99s why we assume that if one chooses to rely on a brand new media type = and wants to interoperate with others, an (application-level) agreement = is needed on how to interpret such information.

If I=E2=80=99m an implementer and = I want to start using some new media type, it would be helpful for me to = know if there are already other implementations out there using that = media type name before I decide whether I want to risk collisions with = however the attribute is already being interpreted, or whether I want to = name mine something different and go negotiate what its interpretation = should be. Not a huge deal and we can see if anyone else raises this in = IETF LC or IESG review, but just an example where it seems like there = could be a significant barrier to achieving interop if people decide to = use this extension point.

We tried to summarize all of the above = considerations (including Roni=E2=80=99s suggestion) and arrived at the = following re-wording of Section 11.2. Please let us know what you think = about it now:

The "mediaType" attribute is a mandatory = attribute specifying the media type of the capture. Common standard = values are "audio", "video", "text", as defined in [RFC6838]. Other values can be provided. It is assumed that = implementations agree on the interpretation of those other values. The = "mediaType" attribute is as generic as possible. Here is why: (i) the = basic media capture type is an abstract one; (ii) "concrete" definitions = for the standard ([RFC6838]) audio, video and text capture types have been specified; = (iii) a generic "otherCaptureType" type has been defined; (iv) the = "mediaType" attribute has been generically defined as a string, with no = particular template. =46rom the considerations above, it is clear that = if one chooses to rely on a brand new media type and wants to = interoperate with others, an application-level agreement is needed on = how to interpret such information.



=3D Section 11.23 =3D

"When defining new media capture types that are going to be = described
by means of the <otherMediaCapture> = element, spatial properties of
such new media capture = types SHOULD be defined (e.g., whether or not
they are = spatially definable, whether or not they should be
= associated with an area of capture, etc.).=E2=80=9D

Are there other spatial properties that should be defined = besides the two that are listed? If this is going to be a normative = requirement, the list should be precise.

What we wanted to state here is that a new media capture = might require the definition of spatial properties. In such a case, the = <spatialInformation> element would be present and would contain = (at least) either the capture origin, or the capture area, or both. The = list is not exhaustive, since, like all other pieces of information in = the schema, further elements and attributes can be added if needed = (extensibility).

Ok, I think = you need something like
s/etc./or other properties that = may be defined/

Done.


=3D = Section 15 =3D

(1) What does = =E2=80=9Cfull-optional=E2=80=9D mean?

Nothing meaningful, indeed :-). We meant something like = "full-fledged=E2=80=9D, =E2=80=9Cthoroughly specified=E2=80=9D, or = similar. What would you suggest here?

Either of those would work.

Done = (replaced with full-fledged).


(2) "Data model = information carried within CLUE messages SHOULD be accessed only by = authenticated endpoints.=E2=80=9D The exception cases to this = recommendation should be described.

We = tried to highlight the fact that authenticated access is strongly = advisable, especially if you convey information about individuals = (<personalInfo>) and/or scenes (<sceneInformation>). There = might be more exceptions, depending on the level of criticality that is = associated with the setup and configuration of a specific session. In = principle, one might even decide that no protection at all is needed for = a particular session; that=E2=80=99s why we did not make this a MUST.

Ok, please add some text to = explain what you explain above.

Done. We added a short paragraph to the = section, which states the following:

Indeed, authenticated access is = strongly advisable, especially if you convey 
information about individuals (&lt;personalInfo&gt;) and/or scenes (&lt;sceneInformation&gt;). 
There might be = more exceptions, depending on the level of criticality that is = associated 
with the setup and configuration of a = specific session. In principle, one might even decide 
that no protection at all is needed for a particular session; = here is why authentication
has not been identified as a = mandatory requirement. 

Thanks,
Alissa

Thank = you! Your feedback was really helpful.

Cheers,

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: spromano@unina.it

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







= --Apple-Mail=_3193AB11-1802-49C5-944A-0E70CE205AAC-- From nobody Mon May 9 14:18:03 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E02C212B00A; Mon, 9 May 2016 14:17:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160509211758.18401.22455.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 14:17:58 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Last Call: (An XML Schema for the CLUE data model) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 21:17:59 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'An XML Schema for the CLUE data model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-05-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides an XML schema file for the definition of CLUE data model types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 9 22:16:17 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C28E12D0F6 for ; Mon, 9 May 2016 22:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f43sm6Qj8Gks for ; Mon, 9 May 2016 22:16:11 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A5912D0CC for ; Mon, 9 May 2016 22:16:11 -0700 (PDT) X-ASG-Debug-ID: 1462857366-05f27568a6523190001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id TkAlteePjHbqOS8F (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 07:16:06 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from android-1ca95d607d90d7ed.fritz.box ([151.70.29.95]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u4A5G404024733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 07:16:05 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> <142C7249-4732-4066-8A58-F28DD5C25A05@cooperw.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----KKK5NX1MFKKNST38AFAOQ9S89WCUCA" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 Date: Tue, 10 May 2016 07:16:05 +0200 To: Alissa Cooper Message-ID: X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1462857366 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 151.70.29.95 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29448 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 05:16:15 -0000 ------KKK5NX1MFKKNST38AFAOQ9S89WCUCA Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Thank you! Simon Il 09 Maggio 2016 23:03:02 CEST, Alissa Cooper ha scritto: >Thanks! I requested IETF last call. > >Alissa > >> On May 6, 2016, at 6:56 AM, Simon Pietro Romano >wrote: >> >> Hi Alissa, >> >> please find below our answers to your latest review (version -13 of >the draft)... >> >>> Thanks. I’ve reviewed the -13. Some responses below. >>> >>>> On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano > wrote: >>>> >>>>> (3) I think the explanation of each of the extensibility points in >the document needs to be clearer. Some of the elements are extensible >when I wouldn’t have expected them to be, and the document often >doesn’t explain why the model’s extensibility is being specified as it >is. For example, it’s not clear to me why the content type or the >capture scene type are extensible, and there’s no explanation provided. >For other types I can intuit why they are extensible, but it would help >to make it explicit. >>>> >>>> We wanted to offer people enough flexibility as to define custom >(and perhaps currently unforeseen) extensions to the schema, without >losing compliance with the standard. We did this by leveraging > elemenrts and attributes, which is a common >approach with schemas, still matching the UPA (Unique Particle >Attribution) Constraint. The "XML Schema extensibility” section was >meant to illustrate the mentioned approach. >>>> >>>>> (4) Furthermore, this data model seems to err way on the side of >extensibility, leaving me to wonder just how much it will really >facilitate interoperability. I think the trade-offs the WG is making >here need to be thoroughly justified in the text. >>>> >>>> See my answer above to your comment number (3). What would you >suggest to improve the way we deal with extensibility? >>> >>> I think it would help to state in Section 14 that extensibility was >purposefully favored as much as possible based on expectations about >custom implementations. >> >> OK. We added to section 14 the following couple of sentences: >> >> Elements or attributes from unknown namespaces MUST be ignored. >Extensibility was purposefully favored as much as possible based on >expectations about custom implementations. Hence, the schema offers >people enough flexibility as to define custom extensions, without >losing compliance with the standard. This is achieved by leveraging > elements and attributes, which is a common >approach with schemas, still matching the UPA (Unique Particle >Attribution) Constraint. >> >>> >>>>> And why is it stated differently than how it’s stated in the >protocol doc? >>>> >>>> They are (or at least should be) indeed identical. I checked >version -06 of the protocol and version -12 of the data model and found >the following: >>>> >>>> - Protocol: >>>> >>>> CLUE Participant (CP): An entity able to use the CLUE protocol >within a telepresence session. It can be an endpoint or an MCU able to >use the CLUE protocol. >>>> >>>> - Data Model: >>>> >>>> This term is not imported from the framework terminology. A CLUE >Participant identifies a generic entity (either an Endpoint or a MCU) >making use of the CLUE protocol. >>>> >>>> If we decide that such a definition can survive, we might proceed >as follows: (i) introduce it in the protocol draft; (ii) point to it in >the data model draft. What’s your feeling about that? >>> >>> Good idea. >> >> Done. The CLUE Participant definition has been removed from the data >model and replaced with a reference to the protocol document. >> >>> >>>>> = Section 11.2 = >>>>> >>>>> "Common values are "audio", "video", >>>>> "text". Other values can be provided. It is assumed that >>>>> implementations agree on the interpretation of those other >values.” >>>>> >>>>> This seems like an interop problem waiting to happen, since there >is no registry specified for these values. Why not create one so that >independent implementers can at least know what other values may be >supported by other implementations? >>>> >>>> I’m not sure I understand this point correctly. The idea here was >to be as generic as possible. That’s why: (i) the basic media capture >type is an abstract one; (ii) “concrete” definitions for audio, video >and text capture types have been specified; >>> >>> Referencing the registry as Roni suggested would help. >>> >>>> (iii) a 100% generic “otherCaptureType” type has been defined; >(iv) the “mediaType” attribute has been generically defined as a >string, with no particular template. >>>> >>>> That’s why we assume that if one chooses to rely on a brand new >media type and wants to interoperate with others, an >(application-level) agreement is needed on how to interpret such >information. >>> >>> If I’m an implementer and I want to start using some new media type, >it would be helpful for me to know if there are already other >implementations out there using that media type name before I decide >whether I want to risk collisions with however the attribute is already >being interpreted, or whether I want to name mine something different >and go negotiate what its interpretation should be. Not a huge deal and >we can see if anyone else raises this in IETF LC or IESG review, but >just an example where it seems like there could be a significant >barrier to achieving interop if people decide to use this extension >point. >> >> We tried to summarize all of the above considerations (including >Roni’s suggestion) and arrived at the following re-wording of Section >11.2. Please let us know what you think about it now: >> >> The "mediaType" attribute is a mandatory attribute specifying the >media type of the capture. Common standard values are "audio", "video", >"text", as defined in [RFC6838] >. Other values >can be provided. It is assumed that implementations agree on the >interpretation of those other values. The "mediaType" attribute is as >generic as possible. Here is why: (i) the basic media capture type is >an abstract one; (ii) "concrete" definitions for the standard >([RFC6838] ) >audio, video and text capture types have been specified; (iii) a >generic "otherCaptureType" type has been defined; (iv) the "mediaType" >attribute has been generically defined as a string, with no particular >template. From the considerations above, it is clear that if one >chooses to rely on a brand new media type and wants to interoperate >with others, an application-level agreement is needed on how to >interpret such information. >> >> >>>> >>>>> = Section 11.23 = >>>>> >>>>> "When defining new media capture types that are going to be >described >>>>> by means of the element, spatial properties of >>>>> such new media capture types SHOULD be defined (e.g., whether or >not >>>>> they are spatially definable, whether or not they should be >>>>> associated with an area of capture, etc.).” >>>>> >>>>> Are there other spatial properties that should be defined besides >the two that are listed? If this is going to be a normative >requirement, the list should be precise. >>>> >>>> What we wanted to state here is that a new media capture might >require the definition of spatial properties. In such a case, the > element would be present and would contain (at >least) either the capture origin, or the capture area, or both. The >list is not exhaustive, since, like all other pieces of information in >the schema, further elements and attributes can be added if needed >(extensibility). >>> >>> Ok, I think you need something like >>> s/etc./or other properties that may be defined/ >> >> Done. >> >>> >>>>> = Section 15 = >>>>> >>>>> (1) What does “full-optional” mean? >>>> >>>> Nothing meaningful, indeed :-). We meant something like >"full-fledged”, “thoroughly specified”, or similar. What would you >suggest here? >>> >>> Either of those would work. >> >> Done (replaced with full-fledged). >> >>> >>>> (2) "Data model information carried within CLUE messages SHOULD be >accessed only by authenticated endpoints.” The exception cases to this >recommendation should be described. >>>> >>>> We tried to highlight the fact that authenticated access is >strongly advisable, especially if you convey information about >individuals () and/or scenes (). There >might be more exceptions, depending on the level of criticality that is >associated with the setup and configuration of a specific session. In >principle, one might even decide that no protection at all is needed >for a particular session; that’s why we did not make this a MUST. >>> >>> Ok, please add some text to explain what you explain above. >> >> Done. We added a short paragraph to the section, which states the >following: >> >> Indeed, authenticated access is strongly advisable, especially if you >convey >> information about individuals (<personalInfo>) and/or scenes >(<sceneInformation>). >> There might be more exceptions, depending on the level of criticality >that is associated >> with the setup and configuration of a specific session. In principle, >one might even decide >> that no protection at all is needed for a particular session; here is >why authentication >> has not been identified as a mandatory requirement. >> >>> Thanks, >>> Alissa >> >> Thank you! Your feedback was really helpful. >> >> Cheers, >> >> 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: spromano@unina.it > >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> > (_/ >> >> >> >> >> >> ------KKK5NX1MFKKNST38AFAOQ9S89WCUCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you!

Simon

Il 09 Maggio 2016 23:03:02 CEST, Alissa Cooper <alissa@cooperw.in> ha scritto:
Thanks! I requested IETF last call.

Alissa

On May 6, 2016, at 6:56 AM, Simon Pietro Romano <spromano@unina.it> wrote:

Hi Alissa,

please find below our answers to your latest review (version -13 of the draft)...

Thanks. I’ve reviewed the -13. Some responses below.

On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano <spromano@unina.it> wrote:

(3) I think the explanation of each of the extensibility points in the document needs to be clearer. Some of the elements are extensible when I wouldn’t have expected them to be, and the document often doesn’t explain why the model’s extensibility is being specified as it is. For example, it’s not clear to me why the content type or the capture scene type are extensible, and there’s no explanation provided. For other types I can intuit why they are extensible, but it would help to make it explicit.

We wanted to offer people enough flexibility as to define custom (and perhaps currently unforeseen) extensions to the schema, without losing compliance with the standard. We did this by leveraging  <xs:any> elemenrts and <xs:anyAttribute> attributes, which is a common approach with schem as, still matching the UPA (Unique Particle Attribution) Constraint. The "XML Schema extensibility” section was meant to illustrate the mentioned approach.

(4) Furthermore, this data model seems to err way on the side of extensibility, leaving me to wonder just how much it will really facilitate interoperability. I think the trade-offs the WG is making here need to be thoroughly justified in the text.

See my answer above to your comment number (3). What would you suggest to improve the way we deal with extensibility?

I think it would help to state in Section 14 that extensibility was purposefully favored as much as possible based on expectations about custom implementations.

OK. We added to section 14 the following couple of sentences:

Elements or attributes from unknown namespaces MUST be ignored. Extensibility was purposefully favored as much as possible based on expectations about custom implementations. Hence, the schema offers people enough flexibility as to define custom extensions, without losing compliance with the standard. This is achieved by leveraging <xs:any> elements and <xs:anyAttribute> attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) Constraint.


And why is it stated differently than how it’s stated in the protocol doc?

They are (or at least should be) indeed identical. I checked version -06 of the protocol and version -12 of the data model and found the following:

- Protocol:

CLUE Participant (CP):  An entity able to use the CLUE protocol within a telepresence session.  It can be an endpoint or an MCU able to use the CLUE protocol.

- Data Model:

This term is not imported from the framework terminology.  A CLUE Participant identifies a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol.

If we decide that such a definition can survive, we might proceed as follows: (i) introduce it in the protocol draft; (ii) point to it in the data model draft. What’s your feeling about tha t?

Good idea.

Done. The CLUE Participant definition has been removed from the data model and replaced with a reference to the protocol document.


= Section 11.2 =

"Common values are "audio", "video",
"text".  Other values can be provided.  It is assumed that
implementations agree on the interpretation of those other values.”

This seems like an interop problem waiting to happen, since there is no registry specified for these values. Why not create one so that independent implementers can at least know what other values may be supported by other implementations?

I’m not sure I understand this point correct ly. The idea here was to be as generic as possible. That’s why: (i) the basic media capture type is an abstract one; (ii) “concrete” definitions for audio, video and text capture types have been specified;

Referencing the registry as Roni suggested would help.

(iii)  a 100% generic “otherCaptureType” type has been defined; (iv) the “mediaType” attribute has been generically defined as a string, with no particular template.

That’s why we assume that if one chooses to rely on a brand new media type and wants to interoperate with others, an (application-level) agreement is needed on how to interpret such information.

If I’m an implementer and I want to start using some new media type, it would be helpful for me to know if there are already other implementations out there using that media type name before I d ecide whether I want to risk collisions with however the attribute is already being interpreted, or whether I want to name mine something different and go negotiate what its interpretation should be. Not a huge deal and we can see if anyone else raises this in IETF LC or IESG review, but just an example where it seems like there could be a significant barrier to achieving interop if people decide to use this extension point.

We tried to summarize all of the above considerations (including Roni’s suggestion) and arrived at the following re-wording of Section 11.2. Please let us know what you think about it now:

The "mediaType" attribute is a mandatory attribute specifying the media type of the capture. Common standard values are "audio", "video", "text", as defined in [RFC6838]. Other values can be provided. It is assumed that implementations agree on the interpretation of those other values. The "mediaType" attribute is as generic as possible. Here is why: (i) the basic media capture type is an abstract one; (ii) "concrete" definitions for the standard ([RFC6838]) audio, video and text capture types have been specified; (iii) a generic "otherCaptureType" type has been defined; (iv) the "mediaType" attribute has been generically defined as a string, with no particular template. From the considerations above, it is clear that if one chooses to rely on a brand new media type and wants to interoperate with others, an application-level agreement is needed on how to interpret such information.



= Section 11.23 =

"When defining new med ia capture types that are going to be described
by means of the <otherMediaCapture> element, spatial properties of
such new media capture types SHOULD be defined (e.g., whether or not
they are spatially definable, whether or not they should be
associated with an area of capture, etc.).”

Are there other spatial properties that should be defined besides the two that are listed? If this is going to be a normative requirement, the list should be precise.

What we wanted to state here is that a new media capture might require the definition of spatial properties. In such a case, the <spatialInformation> element would be present and would contain (at least) either the capture origin, or the capture area, or both. The list is not exhaustive, since, like all other pieces of information in the schema, further elements and attributes can be added if needed (extensibility).

Ok, I think you need something like
s/etc./or other properties that may be defined/

Done.


= Section 15 =

(1) What does “full-optional” mean?

Nothing meaningful, indeed :-). We meant something like "full-fledged”, “thoroughly specified”, or similar. What would you suggest here?

Either of those would work.

Done (replaced with full-fledged).


(2) "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints.” The exception cases to this recommendation should be described.

We tried to highlight the fact that authenticated access is strongly advisable, especially if you convey information about individuals (<personalInfo>) and/or scenes (<sceneInformation>). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; that’s why we did not make this a MUST.

Ok, please add some text to explain what you explain above.

Done. We added a short paragraph to the section, which states the following:

Indeed, authenticated access is strongly advisable, especially if you convey 
information about individuals (&lt;personalInfo&gt;) and/or scenes (&lt;sceneInformation&gt;). 
There might be more exceptions, depending on the level of criticality that is associated 
with the setup and configuration of a specific session. In principle, one might even decide 
that no protection at all is needed for a particular session; here is why authentication
has not been identified as a mandatory requirement. 

Thanks,
Alissa

Thank you! Your feedback was really helpful.

Cheers,

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: spromano@unina.it

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







------KKK5NX1MFKKNST38AFAOQ9S89WCUCA-- From nobody Thu May 12 08:35:04 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D112D1B2 for ; Thu, 12 May 2016 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VipwGT_4te_a for ; Thu, 12 May 2016 08:34:52 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F242312D09F for ; Thu, 12 May 2016 08:34:50 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id v200so39999862wmv.1 for ; Thu, 12 May 2016 08:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=13dZ5KvijaCIwyqMkebmECUPFZsTiPEJJzif3TpdpaA=; b=bOblTsbIIa9uNkXoo0FMz+gIt8ouFhvLdDb6+LaUww6R8tf2u/ZLjKLtIR6JvwfW9v ZFnoP0StNh48drrh5L9diHeC/fa+hfr8jzrGtzhTFA0IQbaj5gXp4IY9nj2EEyx1f4On MVo+0A5XRNDWhXWXGSHMyTO9JQvxTs+4nhRhZ5+9Ku6At3eQLKZQzyyiKVqKwY/+aldT MwiL1JwW70HzMHERGiOeM3zYr1xnQ4U4bKCZFlR31QzgVH22UDq9drcOyaFRNBRbJK9B P8BNPUUIoT9iafgFVU+Q8gQDt4vsxBmQxTdP1s10SsxFBnGIIXMp8T0jYIroIEuEXa5n uSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=13dZ5KvijaCIwyqMkebmECUPFZsTiPEJJzif3TpdpaA=; b=DhIHvgBEnQn6NZwNrXcngGMlgkCmJKoSWpx49LQRmc/v39Vrt9F5xJZZMBTycx4pT/ uuX4GQQtcKxvWYcz++4JMsIx7qW1rJYMY4LRLancMRQDfi4BBOX3qHWzr57egeP6zk59 KvyP8S5/Fw9eDRUqm9YoEVapo+WG+3Cyn6TotS2qQRg7rcHAn0sA1ticWZtWPjjPDi+1 KMXYfskNkc+GN9iiFQjDZv1JQnf3AekzRV9uxnXxHCIya/BpiL6R8u92+hEBkeONd/3S gyGg3IYH+Rpt/FcHhAIGgaDqHxCC+l4bkzzZLOTZvI1f6QZDBSL5dVlJNN1iproLoRZ8 m9mw== X-Gm-Message-State: AOPr4FUeI2rSzOoiln4t/Iwlk243cDeXG/WU3Ea8ujD1F7b6onoSArWvztn6jzux7ikhgw== X-Received: by 10.28.152.212 with SMTP id a203mr7090986wme.95.1463067289525; Thu, 12 May 2016 08:34:49 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id w77sm41405406wmw.10.2016.05.12.08.34.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 08:34:48 -0700 (PDT) From: "Roni Even" To: "'Simon Pietro Romano'" , References: In-Reply-To: Date: Thu, 12 May 2016 18:34:33 +0300 Message-ID: <089901d1ac63$c9cf97a0$5d6ec6e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyRqhATyze6PpciVH2FXJ9BrlVHKB0OhuA Content-Language: he Archived-At: Cc: clue@ietf.org Subject: [clue] FW: Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:35:02 -0000 -----Original Message----- From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] Sent: Wednesday, May 11, 2016 6:58 PM To: apps-discuss@ietf.org; draft-ietf-clue-data-model-schema.all@ietf.org Cc: iesg@ietf.org Subject: Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 [Argh, fumble-finger -- resending with correct address lines] Document: draft-ietf-clue-data-model-schema Title: An XML Schema for the CLUE data model Reviewer: Henry S. Thompson Review Date: 2016-05-11 IETF Last Call Date: 2016-05-23 ESG Telechat Date: 2016-06-02 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: The XML Schema itself which is included in this draft is conformant to the XML Schema 1.0 spec, and is good to go, subject to a minor correction. There is a minor glitch in one of the XML examples, also easily corrected. Comments: I tested the XML Schema document included as section 4 and it passes as valid against the schema for schemas. The example document in section 17 is schema-valid according to the corresponding schema. See 'Nits' below for a minor problem with the example document in section 18. I briefly reviewed the schema document and it seems straightforward and fit for its intended purpose. Minor Issues: Section 4, lines 13--14: As this stands, it's not actually usable for validation purposes, because no xcard.xsd file is supplied. Furthermore, there is no Appendix A, which is alleged to provide it (see 11.29.1.2). I note further that the xCard RFC (6351) doesn't contain an XSD-format schema document either. The IANA XML Registry [1] schema entry for the urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to such a schema document [2]. I suggest you either a) Edit the draft so the above lines read (this is what I did to do the validity checks I did); or b) Delete the schemaLocation attribute and add a comment identifying possible sources of a schema document for the vcard-4.0 namespace, e.g. the above iana.org URI or the contents of Appendix A (if you fill it in). Nits: Section 18, the XML example has a (copy-paste?) error, which renders that example invalid against the schema. The line EG0 appears twice inside mediaCapture VC7, once on line 204 and once on line 237. The first occurrence should be deleted. [1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Fri May 13 04:55:28 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD712D19F; Fri, 13 May 2016 04:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513115527.10628.77415.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 04:55:27 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-08.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 11:55:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-08.txt Pages : 57 Date : 2016-05-13 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 04:59:58 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A0F12D17B for ; Fri, 13 May 2016 04:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8xIv-2Nb7LQ for ; Fri, 13 May 2016 04:59:53 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24B912D19F for ; Fri, 13 May 2016 04:59:51 -0700 (PDT) X-ASG-Debug-ID: 1463140788-05f27568a773ace0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id RiflvGoQfnN18r7y (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 13:59:48 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u4DBxkSO029925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 13:59:46 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_0EA13DD3-69C3-4DB0-B246-FD0E04B15796" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Finishing up Security Considerations for protocol In-Reply-To: <571673E9.4050005@alum.mit.edu> Date: Fri, 13 May 2016 13:59:51 +0200 Message-Id: <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> References: <571673E9.4050005@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1463140788 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29543 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 11:59:57 -0000 --Apple-Mail=_0EA13DD3-69C3-4DB0-B246-FD0E04B15796 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Paul and others,=20 I just submitted a revised version of the protocol draft, in which I = tried to sketch a thorough Security Considerations section. Please comment on that (the Security Section, which is also copy-pasted = below) and on the document as a whole. Thank you once again for your input and comments, Simon ***************************************** START OF SECURITY = CONSIDERATIONS SECTION ********************************************** As a general consideration, we remark that the CLUE framework (and related protocol) has been conceived at the outset by embracing the security-by-design paradigm. This entails that a number of requirements have been identified and properly standardized as mandatory within the entire set of documents associated with the CLUE architecture. Among such requirements we mention the following: (i) always leave space for criptography and authentication; (ii) get sure that all sensitive fields can be protected; (iii) envisage mutual authentication between CLUE endpoints; (iv) envisage the presence of authorization mechanisms; (v) envisage the presence of native defense mechanisms against malicious activities such as eavesdropping, selective modification, deletion, replay (and related combinations thereof). Hence, security of the single components of the CLUE solution cannot be evaluated independently of the integrated view of the final architecture. Coming to the details of the CLUE protocol, this is an application- level protocol allowing a Media Producer and a Media Consumer to negotiate a variegated set of parameters associated with the establishment of a telepresence session. This unavoidably exposes a CLUE-enabled telepresence system to a number of potential threats, most of which are extensively discussed in the framework document [I-D.ietf-clue-framework]. The security considerations section of the mentioned document actually discusses issues associated with the setup and management of a telepresence session both in the basic case involving two CLUE endpoints acting, respectively, as MP and MC, and in the more advanced scenario envisaging the presence of an MCU. The framework document also mentions that the information carried within CLUE protocol messages might contain sensitive data, which SHOULD hence be accessed only by authenticated endpoints. Security issues associated with the CLUE data model schema are discussed in [I-D.ietf-clue-data-model-schema]. There is indeed some piece of extra information carried by the CLUE protocol which is not associated with the standard data model and which exposes information that might be of concern. This is primarily what gets exchanged during the options negotiation phase. =46rom the Clue Participant state machine, we know that in the = OPTIONS state both parties agree on the version and on the options to be used in the subsequent CLUE messages exchange phase. A malicious participant might either try to retrieve a detailed footprint of a specific CLUE protocol implementation during this initial setup phase, or force the communicating party to stick to a non-up-to-date version of the protocol which they know how to break. Indeed, exposing all of the supported versions and options could conceivably leak a bit of information about the specific implementation of the protocol. In theory an implementation could choose not to announce all of the versions it supports if it wants to avoid such leakage, though at the expenses of interoperability. With respect to the above considerations, we nonetheless remark that the OPTIONS state is only reached after the CLUE data channel has been successfully set up. This ensures that only authenticated parties can exchange OPTIONS and related OPTIONS RESPONSE messages and hence drastically reduces the attack surface which is exposed to malicious parties. Coming to the content of the protocol messages themselves, the CLUE framework clearly states the requirement to protect against threats deriving from the presence of a malicious agent capable to gain access to the CLUE data channel. Such a requirement is met by the CLUE data channel solution described in [I-D.ietf-clue-datachannel], which ensures protection from both message recovery and message tampering. With respect to this last point, we once again remark that any implementation of the CLUE protocol which claims to be compliant with the CLUE specification MUST rely on the exchaning of messages which flow on top of a reliable and ordered SCTP over DTLS transport channel connecting two CLUE Participants. As a final consideration, we remark that policy-based management of a CLUE-compliant telepresence architecture, though not in the scope of the CLUE WG charter, can easily be realized. To the purpose, common Role-Based Access Control (RBAC) approaches can be leveraged. In RBAC, the following elements are identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; (v) Permissions. For all of the above elements, a direct mapping exists onto the main CLUE entities. As an example, RBAC objects map onto CLUE data model objects and RBAC operations map onto CLUE protocol operations. Future documents can define an RBAC framework for CLUE, by first focusing on the definition of roles and then specifying the needed permission policy sets and role policy sets (used to associate policy permission sets with specific roles). With these policies in place, access to information compliant with the CLUE data model can be appropriately controlled. As far as assigning users to roles, the Users in the RBAC model relate directly to the element in the CLUE object. The element is comprised of elements representing a specific user in the telepresence system. Each element contains a 'personID' attribute acting as a unique identifier and a element describing their role in the CLUE session ("presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman") . Thus, each authorized user can be associated with a well-defined role in the RBAC model. ***************************************** END OF SECURITY CONSIDERATIONS = SECTION ********************************************** > On 19/apr/2016, at 20:07, Paul Kyzivat wrote: >=20 > The protocol needs to have a Security Considerations section before it = can progress. That is the main gating item at this point. >=20 > This should be pretty simple. The following are my thoughts about what = should be in it: >=20 > - it should reference the security considerations in the framework. = They cover many important issues and those probably don't need to be = restated as long as they are referenced. >=20 > - it should reference the security considerations in the data model. = That document has most of the critical data to be concerned with. >=20 > - a reference to the security considerations in the clue-datachannel = draft will cover the protection of the content of the protocol messages. >=20 > - There probably should be a brief discussion of the extra data in the = protocol (not in the data model) that exposes information that might be = of concern. I think this is primarily in the options negotiation: = exposing all the versions and options supported could conceivably leak a = bit of info about the specific software. In theory an implementation = could choose not to announce all the versions it supports if it wants to = avoid such leakage, though it would reduce interoperability. And of = course it will only be relevant when there are multiple versions and = options. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_0EA13DD3-69C3-4DB0-B246-FD0E04B15796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Paul and others, 

I just submitted a revised version of = the protocol draft, in which I tried to sketch a thorough Security = Considerations section.
Please comment on that (the = Security Section, which is also copy-pasted below) and on the document = as a whole.

Thank you once again for your input and comments,

Simon

***************************************** START OF SECURITY = CONSIDERATIONS SECTION = **********************************************
As a = general consideration, we remark that the CLUE framework (and
   related protocol) has been conceived at the = outset by embracing the
  =  security-by-design paradigm.  This entails that a number = of
   requirements have been identified = and properly standardized as
   mandatory = within the entire set of documents associated with the CLUE
   architecture.  Among such requirements we = mention the following: (i)
   always = leave space for criptography and authentication; (ii) get sure
   that all sensitive fields can be protected; = (iii) envisage mutual
   authentication = between CLUE endpoints; (iv) envisage the presence of
   authorization mechanisms; (v) envisage the = presence of native defense
   mechanisms = against malicious activities such as eavesdropping,
   selective modification, deletion, replay (and = related combinations
   thereof). =  Hence, security of the single components of the CLUE
   solution cannot be evaluated independently of = the integrated view of
   the final = architecture.

   Coming to the details of the CLUE protocol, this = is an application-
   level protocol = allowing a Media Producer and a Media Consumer to
   negotiate a variegated set of parameters = associated with the
   establishment of a = telepresence session.  This unavoidably exposes a
   CLUE-enabled telepresence system to a number of = potential threats,
   most of which are = extensively discussed in the framework document
   [I-D.ietf-clue-framework].  The security = considerations section of
   the = mentioned document actually discusses issues associated with = the
   setup and management of a = telepresence session both in the basic case
  =  involving two CLUE endpoints acting, respectively, as MP and MC, = and
   in the more advanced scenario = envisaging the presence of an MCU.

   The framework document = also mentions that the information carried
  =  within CLUE protocol messages might contain sensitive data, = which
   SHOULD hence be accessed only by = authenticated endpoints.  Security
  =  issues associated with the CLUE data model schema are discussed = in
  =  [I-D.ietf-clue-data-model-schema].

   There is indeed some piece = of extra information carried by the CLUE
  =  protocol which is not associated with the standard data model = and
   which exposes information that = might be of concern.  This is
  =  primarily what gets exchanged during the options negotiation = phase.
   =46rom the Clue Participant = state machine, we know that in the OPTIONS
  =  state both parties agree on the version and on the options to be = used
   in the subsequent CLUE messages = exchange phase.  A malicious
  =  participant might either try to retrieve a detailed footprint of = a
   specific CLUE protocol = implementation during this initial setup
  =  phase, or force the communicating party to stick to a = non-up-to-date
   version of the protocol = which they know how to break.  Indeed,
  =  exposing all of the supported versions and options could = conceivably
   leak a bit of information = about the specific implementation of the
  =  protocol.  In theory an implementation could choose not to = announce
   all of the versions it = supports if it wants to avoid such leakage,
  =  though at the expenses of interoperability.  With respect to = the
   above considerations, we = nonetheless remark that the OPTIONS state is
  =  only reached after the CLUE data channel has been successfully = set
   up.  This ensures that only = authenticated parties can exchange
  =  OPTIONS and related OPTIONS RESPONSE messages and hence = drastically
   reduces the attack surface = which is exposed to malicious parties.

   Coming to the content of = the protocol messages themselves, the CLUE
  =  framework clearly states the requirement to protect against = threats
   deriving from the presence of = a malicious agent capable to gain
  =  access to the CLUE data channel.  Such a requirement is met = by the
   CLUE data channel solution = described in [I-D.ietf-clue-datachannel],
  =  which ensures protection from both message recovery and = message
   tampering.  With respect = to this last point, we once again remark
  =  that any implementation of the CLUE protocol which claims to = be
   compliant with the CLUE = specification MUST rely on the exchaning of
  =  messages which flow on top of a reliable and ordered SCTP over = DTLS
   transport channel connecting two = CLUE Participants.

   As a final consideration, we remark that = policy-based management of a
  =  CLUE-compliant telepresence architecture, though not in the scope = of
   the CLUE WG charter, can easily be = realized.  To the purpose, common
  =  Role-Based Access Control (RBAC) approaches can be leveraged. =  In
   RBAC, the following elements = are identified: (i) Users; (ii) Roles;
  =  (iii) Objects; (iv) Operations; (v) Permissions.  For all of = the
   above elements, a direct mapping = exists onto the main CLUE entities.
   As = an example, RBAC objects map onto CLUE data model objects and = RBAC
   operations map onto CLUE protocol = operations.  Future documents can
  =  define an RBAC framework for CLUE, by first focusing on = the
   definition of roles and then = specifying the needed permission policy
  =  sets and role policy sets (used to associate policy permission = sets
   with specific roles).  With = these policies in place, access to
  =  information compliant with the CLUE data model can be = appropriately
   controlled.  As far = as assigning users to roles, the Users in the
  =  RBAC model relate directly to the <people> element in the = CLUE
   object.  The <people> = element is comprised of <person> elements
   representing a specific user in the telepresence = system.  Each
   <person> = element contains a 'personID' attribute acting as a unique
   identifier and a <personType> element = describing their role in the
   CLUE = session ("presenter", "timekeeper", "attendee", "minute = taker",
   "translator", "chairman", = "vice-chairman") .  Thus, each authorized
 =  user can be associated with a well-defined role in the RBAC = model.

***************************************** END OF SECURITY = CONSIDERATIONS SECTION = **********************************************





On = 19/apr/2016, at 20:07, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

The protocol needs = to have a Security Considerations section before it can progress. That = is the main gating item at this point.

This = should be pretty simple. The following are my thoughts about what should = be in it:

- it should reference the = security considerations in the framework. They cover many important = issues and those probably don't need to be restated as long as they are = referenced.

- it should reference the = security considerations in the data model. That document has most of the = critical data to be concerned with.

- a = reference to the security considerations in the clue-datachannel draft = will cover the protection of the content of the protocol messages.

- There probably should be a brief discussion = of the extra data in the protocol (not in the data model) that exposes = information that might be of concern. I think this is primarily in the = options negotiation: exposing all the versions and options supported = could conceivably leak a bit of info about the specific software. In = theory an implementation could choose not to announce all the versions = it supports if it wants to avoid such leakage, though it would reduce = interoperability. And of course it will only be relevant when there are = multiple versions and options.

= Thanks,
Paul

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


  =                   =   =        = _\\|//_
            =                 =       ( 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: spromano@unina.it

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






= --Apple-Mail=_0EA13DD3-69C3-4DB0-B246-FD0E04B15796-- From nobody Fri May 13 07:27:34 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33812D545 for ; Fri, 13 May 2016 07:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOZlcEAcF8qD for ; Fri, 13 May 2016 07:27:31 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0932E12D186 for ; Fri, 13 May 2016 07:27:30 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id 1E1obve2cgEHv1E3tbzsJF; Fri, 13 May 2016 14:27:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463149649; bh=LsrswFklNB36whCiCP//REuiSFZSHxhOLaLFCJmgfFA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=o81CTOe/MdP5XRQ7HK7H4qvUjQ+4f/tYhb58M3RPBr5zRUpiSD9CAPOuBbddvkwzE iRttxpOwsazTHS1MXTQDIhjxSMzwgIxjG7oeEhc4AVm6th+lV0JiA9FS/ncKZrufzw mWNNuHXF0yhJt6tPoJcXDsW3JRHyc9GbQ5I4Wu3UVhfz6ThvdIBXDXyov0bZactvJf XEj6uoOkRfjanSHHGEmG+YJObDZrS3DWWK/PjLRHOZX1sgicGFWdWjcip6+DNLufuN hnomiBe7cBQyzQY81CRwOOHnM63vh4PWo3diaqkNI01XDi/2/EKvarU55CVR8nJim5 czWhCfSjyvdUQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id tqTU1s00E3KdFy101qTUfP; Fri, 13 May 2016 14:27:29 +0000 To: Simon Pietro Romano References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> From: Paul Kyzivat Message-ID: Date: Fri, 13 May 2016 10:27:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 14:27:33 -0000 On 5/13/16 7:59 AM, Simon Pietro Romano wrote: > Dear Paul and others, > > I just submitted a revised version of the protocol draft, in which I > tried to sketch a thorough Security Considerations section. > Please comment on that (the Security Section, which is also copy-pasted > below) and on the document as a whole. I saw it. This seems to cover the need to address security in the document. Where did the last paragraph (re RBAC) come from? ISTM that this is speculative - not anything that the WG has discussed. I'd like to hear what others think about this. Thanks, Paul > Thank you once again for your input and comments, > > Simon > > ***************************************** START OF SECURITY > CONSIDERATIONS SECTION ********************************************** > As a general consideration, we remark that the CLUE framework (and > related protocol) has been conceived at the outset by embracing the > security-by-design paradigm. This entails that a number of > requirements have been identified and properly standardized as > mandatory within the entire set of documents associated with the CLUE > architecture. Among such requirements we mention the following: (i) > always leave space for criptography and authentication; (ii) get sure > that all sensitive fields can be protected; (iii) envisage mutual > authentication between CLUE endpoints; (iv) envisage the presence of > authorization mechanisms; (v) envisage the presence of native defense > mechanisms against malicious activities such as eavesdropping, > selective modification, deletion, replay (and related combinations > thereof). Hence, security of the single components of the CLUE > solution cannot be evaluated independently of the integrated view of > the final architecture. > > Coming to the details of the CLUE protocol, this is an application- > level protocol allowing a Media Producer and a Media Consumer to > negotiate a variegated set of parameters associated with the > establishment of a telepresence session. This unavoidably exposes a > CLUE-enabled telepresence system to a number of potential threats, > most of which are extensively discussed in the framework document > [I-D.ietf-clue-framework]. The security considerations section of > the mentioned document actually discusses issues associated with the > setup and management of a telepresence session both in the basic case > involving two CLUE endpoints acting, respectively, as MP and MC, and > in the more advanced scenario envisaging the presence of an MCU. > > The framework document also mentions that the information carried > within CLUE protocol messages might contain sensitive data, which > SHOULD hence be accessed only by authenticated endpoints. Security > issues associated with the CLUE data model schema are discussed in > [I-D.ietf-clue-data-model-schema]. > > There is indeed some piece of extra information carried by the CLUE > protocol which is not associated with the standard data model and > which exposes information that might be of concern. This is > primarily what gets exchanged during the options negotiation phase. > From the Clue Participant state machine, we know that in the OPTIONS > state both parties agree on the version and on the options to be used > in the subsequent CLUE messages exchange phase. A malicious > participant might either try to retrieve a detailed footprint of a > specific CLUE protocol implementation during this initial setup > phase, or force the communicating party to stick to a non-up-to-date > version of the protocol which they know how to break. Indeed, > exposing all of the supported versions and options could conceivably > leak a bit of information about the specific implementation of the > protocol. In theory an implementation could choose not to announce > all of the versions it supports if it wants to avoid such leakage, > though at the expenses of interoperability. With respect to the > above considerations, we nonetheless remark that the OPTIONS state is > only reached after the CLUE data channel has been successfully set > up. This ensures that only authenticated parties can exchange > OPTIONS and related OPTIONS RESPONSE messages and hence drastically > reduces the attack surface which is exposed to malicious parties. > > Coming to the content of the protocol messages themselves, the CLUE > framework clearly states the requirement to protect against threats > deriving from the presence of a malicious agent capable to gain > access to the CLUE data channel. Such a requirement is met by the > CLUE data channel solution described in [I-D.ietf-clue-datachannel], > which ensures protection from both message recovery and message > tampering. With respect to this last point, we once again remark > that any implementation of the CLUE protocol which claims to be > compliant with the CLUE specification MUST rely on the exchaning of > messages which flow on top of a reliable and ordered SCTP over DTLS > transport channel connecting two CLUE Participants. > > As a final consideration, we remark that policy-based management of a > CLUE-compliant telepresence architecture, though not in the scope of > the CLUE WG charter, can easily be realized. To the purpose, common > Role-Based Access Control (RBAC) approaches can be leveraged. In > RBAC, the following elements are identified: (i) Users; (ii) Roles; > (iii) Objects; (iv) Operations; (v) Permissions. For all of the > above elements, a direct mapping exists onto the main CLUE entities. > As an example, RBAC objects map onto CLUE data model objects and RBAC > operations map onto CLUE protocol operations. Future documents can > define an RBAC framework for CLUE, by first focusing on the > definition of roles and then specifying the needed permission policy > sets and role policy sets (used to associate policy permission sets > with specific roles). With these policies in place, access to > information compliant with the CLUE data model can be appropriately > controlled. As far as assigning users to roles, the Users in the > RBAC model relate directly to the element in the CLUE > object. The element is comprised of elements > representing a specific user in the telepresence system. Each > element contains a 'personID' attribute acting as a unique > identifier and a element describing their role in the > CLUE session ("presenter", "timekeeper", "attendee", "minute taker", > "translator", "chairman", "vice-chairman") . Thus, each authorized > user can be associated with a well-defined role in the RBAC model. > > ***************************************** END OF SECURITY CONSIDERATIONS > SECTION ********************************************** > > > > > >> On 19/apr/2016, at 20:07, Paul Kyzivat > > wrote: >> >> The protocol needs to have a Security Considerations section before it >> can progress. That is the main gating item at this point. >> >> This should be pretty simple. The following are my thoughts about what >> should be in it: >> >> - it should reference the security considerations in the framework. >> They cover many important issues and those probably don't need to be >> restated as long as they are referenced. >> >> - it should reference the security considerations in the data model. >> That document has most of the critical data to be concerned with. >> >> - a reference to the security considerations in the clue-datachannel >> draft will cover the protection of the content of the protocol messages. >> >> - There probably should be a brief discussion of the extra data in the >> protocol (not in the data model) that exposes information that might >> be of concern. I think this is primarily in the options negotiation: >> exposing all the versions and options supported could conceivably leak >> a bit of info about the specific software. In theory an implementation >> could choose not to announce all the versions it supports if it wants >> to avoid such leakage, though it would reduce interoperability. And of >> course it will only be relevant when there are multiple versions and >> options. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( 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: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > From nobody Fri May 13 08:33:35 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF2112D584 for ; Fri, 13 May 2016 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRet9RAiFpIt for ; Fri, 13 May 2016 08:33:31 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC38512D583 for ; Fri, 13 May 2016 08:33:30 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id 1F2mbqvcp2R4w1F5mbebtj; Fri, 13 May 2016 15:33:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463153610; bh=pq7/YjFAXXPvEC0kW6S6tHnoTXt9JXcClkJo8VS7xRo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=XVBmw3JW+c5KBuIaYMirVMtBVR8r7J66jy2f28NsDjQ6uOm2AqJuY8Xc00PQ6dvIs 5+ykLer0/Kn2zKM+2lq8CYVni0fezWnydzcr38sSMzfj2WbONN2YApOjRfEXS+lGbb Le23yAAkBFXQDMuQiOmz8qRLFRmnr9t6imFNypR4PV3YdSfk5SObbse85bhvLGxehT IcA9ssvJedSj3xbc5EOlYay9lu2bXXrb8AhbSdhUgaVNhVaM6PqSQLPz56X6C/Z2y6 COFSs9G6gboeQGaHLDUPxFj7yZbY0DRFoRHNsUjyLnIpbISCchHMXD4wzgkXnpxqAF neZNk98jGRePw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id trZV1s00Q3KdFy101rZV9o; Fri, 13 May 2016 15:33:30 +0000 To: Simon Pietro Romano References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> From: Paul Kyzivat Message-ID: <344f76f1-88d3-af46-cbcd-263bf56c9809@alum.mit.edu> Date: Fri, 13 May 2016 11:33:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:33:33 -0000 Simon, idnits returns 4 errors and 8 warnings. Some are bogus, but some are valid. Nothing should be hard to fix. Thanks, Paul On 5/13/16 7:59 AM, Simon Pietro Romano wrote: > Dear Paul and others, > > I just submitted a revised version of the protocol draft, in which I > tried to sketch a thorough Security Considerations section. > Please comment on that (the Security Section, which is also copy-pasted > below) and on the document as a whole. > > Thank you once again for your input and comments, > > Simon > > ***************************************** START OF SECURITY > CONSIDERATIONS SECTION ********************************************** > As a general consideration, we remark that the CLUE framework (and > related protocol) has been conceived at the outset by embracing the > security-by-design paradigm. This entails that a number of > requirements have been identified and properly standardized as > mandatory within the entire set of documents associated with the CLUE > architecture. Among such requirements we mention the following: (i) > always leave space for criptography and authentication; (ii) get sure > that all sensitive fields can be protected; (iii) envisage mutual > authentication between CLUE endpoints; (iv) envisage the presence of > authorization mechanisms; (v) envisage the presence of native defense > mechanisms against malicious activities such as eavesdropping, > selective modification, deletion, replay (and related combinations > thereof). Hence, security of the single components of the CLUE > solution cannot be evaluated independently of the integrated view of > the final architecture. > > Coming to the details of the CLUE protocol, this is an application- > level protocol allowing a Media Producer and a Media Consumer to > negotiate a variegated set of parameters associated with the > establishment of a telepresence session. This unavoidably exposes a > CLUE-enabled telepresence system to a number of potential threats, > most of which are extensively discussed in the framework document > [I-D.ietf-clue-framework]. The security considerations section of > the mentioned document actually discusses issues associated with the > setup and management of a telepresence session both in the basic case > involving two CLUE endpoints acting, respectively, as MP and MC, and > in the more advanced scenario envisaging the presence of an MCU. > > The framework document also mentions that the information carried > within CLUE protocol messages might contain sensitive data, which > SHOULD hence be accessed only by authenticated endpoints. Security > issues associated with the CLUE data model schema are discussed in > [I-D.ietf-clue-data-model-schema]. > > There is indeed some piece of extra information carried by the CLUE > protocol which is not associated with the standard data model and > which exposes information that might be of concern. This is > primarily what gets exchanged during the options negotiation phase. > From the Clue Participant state machine, we know that in the OPTIONS > state both parties agree on the version and on the options to be used > in the subsequent CLUE messages exchange phase. A malicious > participant might either try to retrieve a detailed footprint of a > specific CLUE protocol implementation during this initial setup > phase, or force the communicating party to stick to a non-up-to-date > version of the protocol which they know how to break. Indeed, > exposing all of the supported versions and options could conceivably > leak a bit of information about the specific implementation of the > protocol. In theory an implementation could choose not to announce > all of the versions it supports if it wants to avoid such leakage, > though at the expenses of interoperability. With respect to the > above considerations, we nonetheless remark that the OPTIONS state is > only reached after the CLUE data channel has been successfully set > up. This ensures that only authenticated parties can exchange > OPTIONS and related OPTIONS RESPONSE messages and hence drastically > reduces the attack surface which is exposed to malicious parties. > > Coming to the content of the protocol messages themselves, the CLUE > framework clearly states the requirement to protect against threats > deriving from the presence of a malicious agent capable to gain > access to the CLUE data channel. Such a requirement is met by the > CLUE data channel solution described in [I-D.ietf-clue-datachannel], > which ensures protection from both message recovery and message > tampering. With respect to this last point, we once again remark > that any implementation of the CLUE protocol which claims to be > compliant with the CLUE specification MUST rely on the exchaning of > messages which flow on top of a reliable and ordered SCTP over DTLS > transport channel connecting two CLUE Participants. > > As a final consideration, we remark that policy-based management of a > CLUE-compliant telepresence architecture, though not in the scope of > the CLUE WG charter, can easily be realized. To the purpose, common > Role-Based Access Control (RBAC) approaches can be leveraged. In > RBAC, the following elements are identified: (i) Users; (ii) Roles; > (iii) Objects; (iv) Operations; (v) Permissions. For all of the > above elements, a direct mapping exists onto the main CLUE entities. > As an example, RBAC objects map onto CLUE data model objects and RBAC > operations map onto CLUE protocol operations. Future documents can > define an RBAC framework for CLUE, by first focusing on the > definition of roles and then specifying the needed permission policy > sets and role policy sets (used to associate policy permission sets > with specific roles). With these policies in place, access to > information compliant with the CLUE data model can be appropriately > controlled. As far as assigning users to roles, the Users in the > RBAC model relate directly to the element in the CLUE > object. The element is comprised of elements > representing a specific user in the telepresence system. Each > element contains a 'personID' attribute acting as a unique > identifier and a element describing their role in the > CLUE session ("presenter", "timekeeper", "attendee", "minute taker", > "translator", "chairman", "vice-chairman") . Thus, each authorized > user can be associated with a well-defined role in the RBAC model. > > ***************************************** END OF SECURITY CONSIDERATIONS > SECTION ********************************************** > > > > > >> On 19/apr/2016, at 20:07, Paul Kyzivat > > wrote: >> >> The protocol needs to have a Security Considerations section before it >> can progress. That is the main gating item at this point. >> >> This should be pretty simple. The following are my thoughts about what >> should be in it: >> >> - it should reference the security considerations in the framework. >> They cover many important issues and those probably don't need to be >> restated as long as they are referenced. >> >> - it should reference the security considerations in the data model. >> That document has most of the critical data to be concerned with. >> >> - a reference to the security considerations in the clue-datachannel >> draft will cover the protection of the content of the protocol messages. >> >> - There probably should be a brief discussion of the extra data in the >> protocol (not in the data model) that exposes information that might >> be of concern. I think this is primarily in the options negotiation: >> exposing all the versions and options supported could conceivably leak >> a bit of info about the specific software. In theory an implementation >> could choose not to announce all the versions it supports if it wants >> to avoid such leakage, though it would reduce interoperability. And of >> course it will only be relevant when there are multiple versions and >> options. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( 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: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > From nobody Fri May 13 09:13:31 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777AB12D551 for ; Fri, 13 May 2016 09:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgqwFly0MKu0 for ; Fri, 13 May 2016 09:13:27 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CA012D187 for ; Fri, 13 May 2016 09:13:27 -0700 (PDT) X-ASG-Debug-ID: 1463156004-05ce375c677fa7b0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id LGNYUjvQ2sQTRe99 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 18:13:24 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u4DGDNni003184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 18:13:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Finishing up Security Considerations for protocol In-Reply-To: Date: Fri, 13 May 2016 18:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79B5EFE2-761E-4351-AD73-88A200C0F6E9@unina.it> References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> To: Paul Kyzivat X-Mailer: Apple Mail (2.2098) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1463156004 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29548 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 16:13:30 -0000 > Where did the last paragraph (re RBAC) come from? ISTM that this is = speculative - not anything that the WG has discussed. I'd like to hear = what others think about this. You=E2=80=99re right. This actually comes from far away in the past! It = digs its roots in the disucssions we had at the time of the XCON WG and = is in fact something that I added to the CCMP document, too.=20 I personally bend towards role-based access control when it comes to = policy-based managament and I thought this might be a useful piece of = information for an interested reader. Though, I agree with you that we never discussed this within CLUE (which is btw clearly = stated in the document). If you deem it useless, we can just remove that = paragraph. Thanks, Simon >=20 > Thanks, > Paul >=20 >> Thank you once again for your input and comments, >>=20 >> Simon >>=20 >> ***************************************** START OF SECURITY >> CONSIDERATIONS SECTION ********************************************** >> As a general consideration, we remark that the CLUE framework (and >> related protocol) has been conceived at the outset by embracing the >> security-by-design paradigm. This entails that a number of >> requirements have been identified and properly standardized as >> mandatory within the entire set of documents associated with the = CLUE >> architecture. Among such requirements we mention the following: = (i) >> always leave space for criptography and authentication; (ii) get = sure >> that all sensitive fields can be protected; (iii) envisage mutual >> authentication between CLUE endpoints; (iv) envisage the presence = of >> authorization mechanisms; (v) envisage the presence of native = defense >> mechanisms against malicious activities such as eavesdropping, >> selective modification, deletion, replay (and related combinations >> thereof). Hence, security of the single components of the CLUE >> solution cannot be evaluated independently of the integrated view = of >> the final architecture. >>=20 >> Coming to the details of the CLUE protocol, this is an application- >> level protocol allowing a Media Producer and a Media Consumer to >> negotiate a variegated set of parameters associated with the >> establishment of a telepresence session. This unavoidably exposes = a >> CLUE-enabled telepresence system to a number of potential threats, >> most of which are extensively discussed in the framework document >> [I-D.ietf-clue-framework]. The security considerations section of >> the mentioned document actually discusses issues associated with = the >> setup and management of a telepresence session both in the basic = case >> involving two CLUE endpoints acting, respectively, as MP and MC, = and >> in the more advanced scenario envisaging the presence of an MCU. >>=20 >> The framework document also mentions that the information carried >> within CLUE protocol messages might contain sensitive data, which >> SHOULD hence be accessed only by authenticated endpoints. Security >> issues associated with the CLUE data model schema are discussed in >> [I-D.ietf-clue-data-model-schema]. >>=20 >> There is indeed some piece of extra information carried by the CLUE >> protocol which is not associated with the standard data model and >> which exposes information that might be of concern. This is >> primarily what gets exchanged during the options negotiation phase. >> =46rom the Clue Participant state machine, we know that in the = OPTIONS >> state both parties agree on the version and on the options to be = used >> in the subsequent CLUE messages exchange phase. A malicious >> participant might either try to retrieve a detailed footprint of a >> specific CLUE protocol implementation during this initial setup >> phase, or force the communicating party to stick to a = non-up-to-date >> version of the protocol which they know how to break. Indeed, >> exposing all of the supported versions and options could = conceivably >> leak a bit of information about the specific implementation of the >> protocol. In theory an implementation could choose not to announce >> all of the versions it supports if it wants to avoid such leakage, >> though at the expenses of interoperability. With respect to the >> above considerations, we nonetheless remark that the OPTIONS state = is >> only reached after the CLUE data channel has been successfully set >> up. This ensures that only authenticated parties can exchange >> OPTIONS and related OPTIONS RESPONSE messages and hence drastically >> reduces the attack surface which is exposed to malicious parties. >>=20 >> Coming to the content of the protocol messages themselves, the CLUE >> framework clearly states the requirement to protect against threats >> deriving from the presence of a malicious agent capable to gain >> access to the CLUE data channel. Such a requirement is met by the >> CLUE data channel solution described in = [I-D.ietf-clue-datachannel], >> which ensures protection from both message recovery and message >> tampering. With respect to this last point, we once again remark >> that any implementation of the CLUE protocol which claims to be >> compliant with the CLUE specification MUST rely on the exchaning of >> messages which flow on top of a reliable and ordered SCTP over DTLS >> transport channel connecting two CLUE Participants. >>=20 >> As a final consideration, we remark that policy-based management of = a >> CLUE-compliant telepresence architecture, though not in the scope = of >> the CLUE WG charter, can easily be realized. To the purpose, = common >> Role-Based Access Control (RBAC) approaches can be leveraged. In >> RBAC, the following elements are identified: (i) Users; (ii) Roles; >> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >> above elements, a direct mapping exists onto the main CLUE = entities. >> As an example, RBAC objects map onto CLUE data model objects and = RBAC >> operations map onto CLUE protocol operations. Future documents can >> define an RBAC framework for CLUE, by first focusing on the >> definition of roles and then specifying the needed permission = policy >> sets and role policy sets (used to associate policy permission sets >> with specific roles). With these policies in place, access to >> information compliant with the CLUE data model can be appropriately >> controlled. As far as assigning users to roles, the Users in the >> RBAC model relate directly to the element in the CLUE >> object. The element is comprised of elements >> representing a specific user in the telepresence system. Each >> element contains a 'personID' attribute acting as a unique >> identifier and a element describing their role in the >> CLUE session ("presenter", "timekeeper", "attendee", "minute = taker", >> "translator", "chairman", "vice-chairman") . Thus, each authorized >> user can be associated with a well-defined role in the RBAC model. >>=20 >> ***************************************** END OF SECURITY = CONSIDERATIONS >> SECTION ********************************************** >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 19/apr/2016, at 20:07, Paul Kyzivat >> > wrote: >>>=20 >>> The protocol needs to have a Security Considerations section before = it >>> can progress. That is the main gating item at this point. >>>=20 >>> This should be pretty simple. The following are my thoughts about = what >>> should be in it: >>>=20 >>> - it should reference the security considerations in the framework. >>> They cover many important issues and those probably don't need to be >>> restated as long as they are referenced. >>>=20 >>> - it should reference the security considerations in the data model. >>> That document has most of the critical data to be concerned with. >>>=20 >>> - a reference to the security considerations in the clue-datachannel >>> draft will cover the protection of the content of the protocol = messages. >>>=20 >>> - There probably should be a brief discussion of the extra data in = the >>> protocol (not in the data model) that exposes information that might >>> be of concern. I think this is primarily in the options negotiation: >>> exposing all the versions and options supported could conceivably = leak >>> a bit of info about the specific software. In theory an = implementation >>> could choose not to announce all the versions it supports if it = wants >>> to avoid such leakage, though it would reduce interoperability. And = of >>> course it will only be relevant when there are multiple versions and >>> options. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _\\|//_ >> ( 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: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From nobody Fri May 13 09:15:03 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622E312D187 for ; Fri, 13 May 2016 09:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJtMuFGiZz56 for ; Fri, 13 May 2016 09:14:59 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A212D09F for ; Fri, 13 May 2016 09:14:58 -0700 (PDT) X-ASG-Debug-ID: 1463156095-05f27568a7758420001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id ltIje6xVBrvl42JX (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 18:14:55 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u4DGEsfS024377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 18:14:54 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Finishing up Security Considerations for protocol In-Reply-To: <344f76f1-88d3-af46-cbcd-263bf56c9809@alum.mit.edu> Date: Fri, 13 May 2016 18:13:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B17E9AC-B0C3-4857-B028-6CCCBEE19A59@unina.it> References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> <344f76f1-88d3-af46-cbcd-263bf56c9809@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2098) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1463156095 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29547 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 16:15:02 -0000 You=E2=80=99re right. I=E2=80=99ll make a careful check with idnits = before submitting version -09 of the document (which will happen after = we receive WG comments and suggestions). Cheers, Simon > On 13 May 2016, at 17:33, Paul Kyzivat wrote: >=20 > Simon, >=20 > idnits returns 4 errors and 8 warnings. Some are bogus, but some are = valid. Nothing should be hard to fix. >=20 > Thanks, > Paul >=20 > On 5/13/16 7:59 AM, Simon Pietro Romano wrote: >> Dear Paul and others, >>=20 >> I just submitted a revised version of the protocol draft, in which I >> tried to sketch a thorough Security Considerations section. >> Please comment on that (the Security Section, which is also = copy-pasted >> below) and on the document as a whole. >>=20 >> Thank you once again for your input and comments, >>=20 >> Simon >>=20 >> ***************************************** START OF SECURITY >> CONSIDERATIONS SECTION ********************************************** >> As a general consideration, we remark that the CLUE framework (and >> related protocol) has been conceived at the outset by embracing the >> security-by-design paradigm. This entails that a number of >> requirements have been identified and properly standardized as >> mandatory within the entire set of documents associated with the = CLUE >> architecture. Among such requirements we mention the following: = (i) >> always leave space for criptography and authentication; (ii) get = sure >> that all sensitive fields can be protected; (iii) envisage mutual >> authentication between CLUE endpoints; (iv) envisage the presence = of >> authorization mechanisms; (v) envisage the presence of native = defense >> mechanisms against malicious activities such as eavesdropping, >> selective modification, deletion, replay (and related combinations >> thereof). Hence, security of the single components of the CLUE >> solution cannot be evaluated independently of the integrated view = of >> the final architecture. >>=20 >> Coming to the details of the CLUE protocol, this is an application- >> level protocol allowing a Media Producer and a Media Consumer to >> negotiate a variegated set of parameters associated with the >> establishment of a telepresence session. This unavoidably exposes = a >> CLUE-enabled telepresence system to a number of potential threats, >> most of which are extensively discussed in the framework document >> [I-D.ietf-clue-framework]. The security considerations section of >> the mentioned document actually discusses issues associated with = the >> setup and management of a telepresence session both in the basic = case >> involving two CLUE endpoints acting, respectively, as MP and MC, = and >> in the more advanced scenario envisaging the presence of an MCU. >>=20 >> The framework document also mentions that the information carried >> within CLUE protocol messages might contain sensitive data, which >> SHOULD hence be accessed only by authenticated endpoints. Security >> issues associated with the CLUE data model schema are discussed in >> [I-D.ietf-clue-data-model-schema]. >>=20 >> There is indeed some piece of extra information carried by the CLUE >> protocol which is not associated with the standard data model and >> which exposes information that might be of concern. This is >> primarily what gets exchanged during the options negotiation phase. >> =46rom the Clue Participant state machine, we know that in the = OPTIONS >> state both parties agree on the version and on the options to be = used >> in the subsequent CLUE messages exchange phase. A malicious >> participant might either try to retrieve a detailed footprint of a >> specific CLUE protocol implementation during this initial setup >> phase, or force the communicating party to stick to a = non-up-to-date >> version of the protocol which they know how to break. Indeed, >> exposing all of the supported versions and options could = conceivably >> leak a bit of information about the specific implementation of the >> protocol. In theory an implementation could choose not to announce >> all of the versions it supports if it wants to avoid such leakage, >> though at the expenses of interoperability. With respect to the >> above considerations, we nonetheless remark that the OPTIONS state = is >> only reached after the CLUE data channel has been successfully set >> up. This ensures that only authenticated parties can exchange >> OPTIONS and related OPTIONS RESPONSE messages and hence drastically >> reduces the attack surface which is exposed to malicious parties. >>=20 >> Coming to the content of the protocol messages themselves, the CLUE >> framework clearly states the requirement to protect against threats >> deriving from the presence of a malicious agent capable to gain >> access to the CLUE data channel. Such a requirement is met by the >> CLUE data channel solution described in = [I-D.ietf-clue-datachannel], >> which ensures protection from both message recovery and message >> tampering. With respect to this last point, we once again remark >> that any implementation of the CLUE protocol which claims to be >> compliant with the CLUE specification MUST rely on the exchaning of >> messages which flow on top of a reliable and ordered SCTP over DTLS >> transport channel connecting two CLUE Participants. >>=20 >> As a final consideration, we remark that policy-based management of = a >> CLUE-compliant telepresence architecture, though not in the scope = of >> the CLUE WG charter, can easily be realized. To the purpose, = common >> Role-Based Access Control (RBAC) approaches can be leveraged. In >> RBAC, the following elements are identified: (i) Users; (ii) Roles; >> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >> above elements, a direct mapping exists onto the main CLUE = entities. >> As an example, RBAC objects map onto CLUE data model objects and = RBAC >> operations map onto CLUE protocol operations. Future documents can >> define an RBAC framework for CLUE, by first focusing on the >> definition of roles and then specifying the needed permission = policy >> sets and role policy sets (used to associate policy permission sets >> with specific roles). With these policies in place, access to >> information compliant with the CLUE data model can be appropriately >> controlled. As far as assigning users to roles, the Users in the >> RBAC model relate directly to the element in the CLUE >> object. The element is comprised of elements >> representing a specific user in the telepresence system. Each >> element contains a 'personID' attribute acting as a unique >> identifier and a element describing their role in the >> CLUE session ("presenter", "timekeeper", "attendee", "minute = taker", >> "translator", "chairman", "vice-chairman") . Thus, each authorized >> user can be associated with a well-defined role in the RBAC model. >>=20 >> ***************************************** END OF SECURITY = CONSIDERATIONS >> SECTION ********************************************** >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 19/apr/2016, at 20:07, Paul Kyzivat >> > wrote: >>>=20 >>> The protocol needs to have a Security Considerations section before = it >>> can progress. That is the main gating item at this point. >>>=20 >>> This should be pretty simple. The following are my thoughts about = what >>> should be in it: >>>=20 >>> - it should reference the security considerations in the framework. >>> They cover many important issues and those probably don't need to be >>> restated as long as they are referenced. >>>=20 >>> - it should reference the security considerations in the data model. >>> That document has most of the critical data to be concerned with. >>>=20 >>> - a reference to the security considerations in the clue-datachannel >>> draft will cover the protection of the content of the protocol = messages. >>>=20 >>> - There probably should be a brief discussion of the extra data in = the >>> protocol (not in the data model) that exposes information that might >>> be of concern. I think this is primarily in the options negotiation: >>> exposing all the versions and options supported could conceivably = leak >>> a bit of info about the specific software. In theory an = implementation >>> could choose not to announce all the versions it supports if it = wants >>> to avoid such leakage, though it would reduce interoperability. And = of >>> course it will only be relevant when there are multiple versions and >>> options. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _\\|//_ >> ( 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: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From nobody Fri May 13 09:20:22 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727A712D5C3 for ; Fri, 13 May 2016 09:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFZVRd17gkaP for ; Fri, 13 May 2016 09:20:18 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE4512D190 for ; Fri, 13 May 2016 09:20:18 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by comcast with SMTP id 1FoWbcen6vJlg1Fp3bfroZ; Fri, 13 May 2016 16:20:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463156417; bh=o09z/TCTOk702eqKSmHhTeGMA1Uf9CVBtQgHDwDuNVY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=O96E0Yh/a+gFWnNLXCy2jxORiibqn8QoaqXbhtF8W54SgmMdk0P0WEDEAvJ5+xUsV jUqKOO8Zz5DgwuMX9TR06l056gGdZ4uUcOC/ZwnTVZeozwLzbq/ja3JWZt2/trRWK8 AX1PfT8838kM3KYV0kQabJ8sN4qYjJoESIHDv/yoCkf+8wwrWqNrJ9olRnWPeyFotB CdIlgbVS59xAOhTfd12h3CQvC+gwg8XAbUQj3yaYBVb7Pac7H9a/d0fJM5Ai20rzs8 rvfBxW0oUQvUImvMb3Ajg0MSa7JNhoZmq2BflzbYNz9JFcL5htr2QqKqCvIdgNxQbg w8g5Fi36/xImg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-13v.sys.comcast.net with comcast id tsLF1s00e3KdFy101sLGN8; Fri, 13 May 2016 16:20:16 +0000 To: Simon Pietro Romano References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> <79B5EFE2-761E-4351-AD73-88A200C0F6E9@unina.it> From: Paul Kyzivat Message-ID: Date: Fri, 13 May 2016 12:20:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <79B5EFE2-761E-4351-AD73-88A200C0F6E9@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: CLUE Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 16:20:20 -0000 On 5/13/16 12:12 PM, Simon Pietro Romano wrote: >> Where did the last paragraph (re RBAC) come from? ISTM that this is speculative - not anything that the WG has discussed. I'd like to hear what others think about this. > > You’re right. This actually comes from far away in the past! It digs its roots in the disucssions we had at the time of the XCON WG and is in fact something that I added to the CCMP document, too. > I personally bend towards role-based access control when it comes to policy-based managament and I thought this might be a useful piece of information for an interested reader. Though, I agree with > you that we never discussed this within CLUE (which is btw clearly stated in the document). If you deem it useless, we can just remove that paragraph. Lets wait and see what others (including Alissa) think. Thanks, Paul > Thanks, > > Simon > >> >> Thanks, >> Paul >> >>> Thank you once again for your input and comments, >>> >>> Simon >>> >>> ***************************************** START OF SECURITY >>> CONSIDERATIONS SECTION ********************************************** >>> As a general consideration, we remark that the CLUE framework (and >>> related protocol) has been conceived at the outset by embracing the >>> security-by-design paradigm. This entails that a number of >>> requirements have been identified and properly standardized as >>> mandatory within the entire set of documents associated with the CLUE >>> architecture. Among such requirements we mention the following: (i) >>> always leave space for criptography and authentication; (ii) get sure >>> that all sensitive fields can be protected; (iii) envisage mutual >>> authentication between CLUE endpoints; (iv) envisage the presence of >>> authorization mechanisms; (v) envisage the presence of native defense >>> mechanisms against malicious activities such as eavesdropping, >>> selective modification, deletion, replay (and related combinations >>> thereof). Hence, security of the single components of the CLUE >>> solution cannot be evaluated independently of the integrated view of >>> the final architecture. >>> >>> Coming to the details of the CLUE protocol, this is an application- >>> level protocol allowing a Media Producer and a Media Consumer to >>> negotiate a variegated set of parameters associated with the >>> establishment of a telepresence session. This unavoidably exposes a >>> CLUE-enabled telepresence system to a number of potential threats, >>> most of which are extensively discussed in the framework document >>> [I-D.ietf-clue-framework]. The security considerations section of >>> the mentioned document actually discusses issues associated with the >>> setup and management of a telepresence session both in the basic case >>> involving two CLUE endpoints acting, respectively, as MP and MC, and >>> in the more advanced scenario envisaging the presence of an MCU. >>> >>> The framework document also mentions that the information carried >>> within CLUE protocol messages might contain sensitive data, which >>> SHOULD hence be accessed only by authenticated endpoints. Security >>> issues associated with the CLUE data model schema are discussed in >>> [I-D.ietf-clue-data-model-schema]. >>> >>> There is indeed some piece of extra information carried by the CLUE >>> protocol which is not associated with the standard data model and >>> which exposes information that might be of concern. This is >>> primarily what gets exchanged during the options negotiation phase. >>> From the Clue Participant state machine, we know that in the OPTIONS >>> state both parties agree on the version and on the options to be used >>> in the subsequent CLUE messages exchange phase. A malicious >>> participant might either try to retrieve a detailed footprint of a >>> specific CLUE protocol implementation during this initial setup >>> phase, or force the communicating party to stick to a non-up-to-date >>> version of the protocol which they know how to break. Indeed, >>> exposing all of the supported versions and options could conceivably >>> leak a bit of information about the specific implementation of the >>> protocol. In theory an implementation could choose not to announce >>> all of the versions it supports if it wants to avoid such leakage, >>> though at the expenses of interoperability. With respect to the >>> above considerations, we nonetheless remark that the OPTIONS state is >>> only reached after the CLUE data channel has been successfully set >>> up. This ensures that only authenticated parties can exchange >>> OPTIONS and related OPTIONS RESPONSE messages and hence drastically >>> reduces the attack surface which is exposed to malicious parties. >>> >>> Coming to the content of the protocol messages themselves, the CLUE >>> framework clearly states the requirement to protect against threats >>> deriving from the presence of a malicious agent capable to gain >>> access to the CLUE data channel. Such a requirement is met by the >>> CLUE data channel solution described in [I-D.ietf-clue-datachannel], >>> which ensures protection from both message recovery and message >>> tampering. With respect to this last point, we once again remark >>> that any implementation of the CLUE protocol which claims to be >>> compliant with the CLUE specification MUST rely on the exchaning of >>> messages which flow on top of a reliable and ordered SCTP over DTLS >>> transport channel connecting two CLUE Participants. >>> >>> As a final consideration, we remark that policy-based management of a >>> CLUE-compliant telepresence architecture, though not in the scope of >>> the CLUE WG charter, can easily be realized. To the purpose, common >>> Role-Based Access Control (RBAC) approaches can be leveraged. In >>> RBAC, the following elements are identified: (i) Users; (ii) Roles; >>> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >>> above elements, a direct mapping exists onto the main CLUE entities. >>> As an example, RBAC objects map onto CLUE data model objects and RBAC >>> operations map onto CLUE protocol operations. Future documents can >>> define an RBAC framework for CLUE, by first focusing on the >>> definition of roles and then specifying the needed permission policy >>> sets and role policy sets (used to associate policy permission sets >>> with specific roles). With these policies in place, access to >>> information compliant with the CLUE data model can be appropriately >>> controlled. As far as assigning users to roles, the Users in the >>> RBAC model relate directly to the element in the CLUE >>> object. The element is comprised of elements >>> representing a specific user in the telepresence system. Each >>> element contains a 'personID' attribute acting as a unique >>> identifier and a element describing their role in the >>> CLUE session ("presenter", "timekeeper", "attendee", "minute taker", >>> "translator", "chairman", "vice-chairman") . Thus, each authorized >>> user can be associated with a well-defined role in the RBAC model. >>> >>> ***************************************** END OF SECURITY CONSIDERATIONS >>> SECTION ********************************************** >>> >>> >>> >>> >>> >>>> On 19/apr/2016, at 20:07, Paul Kyzivat >>> > wrote: >>>> >>>> The protocol needs to have a Security Considerations section before it >>>> can progress. That is the main gating item at this point. >>>> >>>> This should be pretty simple. The following are my thoughts about what >>>> should be in it: >>>> >>>> - it should reference the security considerations in the framework. >>>> They cover many important issues and those probably don't need to be >>>> restated as long as they are referenced. >>>> >>>> - it should reference the security considerations in the data model. >>>> That document has most of the critical data to be concerned with. >>>> >>>> - a reference to the security considerations in the clue-datachannel >>>> draft will cover the protection of the content of the protocol messages. >>>> >>>> - There probably should be a brief discussion of the extra data in the >>>> protocol (not in the data model) that exposes information that might >>>> be of concern. I think this is primarily in the options negotiation: >>>> exposing all the versions and options supported could conceivably leak >>>> a bit of info about the specific software. In theory an implementation >>>> could choose not to announce all the versions it supports if it wants >>>> to avoid such leakage, though it would reduce interoperability. And of >>>> course it will only be relevant when there are multiple versions and >>>> options. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _\\|//_ >>> ( 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: spromano@unina.it >>> >>> >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>> >>> >>> >>> >>> >>> >> >> > > _\\|//_ > ( 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: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > From nobody Sat May 14 23:38:43 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BD412B00D; Sat, 14 May 2016 23:38:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160515063842.2475.51056.idtracker@ietfa.amsl.com> Date: Sat, 14 May 2016 23:38:42 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 06:38:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-07.txt Pages : 18 Date : 2016-05-14 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 17 17:51:09 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2D12DA66 for ; Tue, 17 May 2016 17:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7W9LODtFi6z for ; Tue, 17 May 2016 17:51:04 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD6C12D54B for ; Tue, 17 May 2016 17:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r0H76eRkVxs5F2JWPEz7407ZtE2RWee/7PfXGUuyBzc=; b=MvqlhC2wfE/TwF9MU7A1/7AptE +s8GCWgIh/ComNXiG/JIZsYpoJfm3jGxyaDylx/BtpdV5WAljMoFso07L7ztcuZjfzSPvf1+EayG0 5RXSBdCjBiaZU05JCTX+ceIyrZ4+rNqQDjHVyaalJyQLWv6MX6P5JqFFVe+r9gHpB/lkWSzCA+Fif ELHGHMNhhsEMRlhIYpQScJeeb7E7bA9uollqYStDDXTbz28M2uxr2ELr0owbfnDEssRz9LMh6H+xh RsYctnWSzTJtV9XV92aM6rjJz7fDFvFKsEiwzIbkmh4WuPbahnxroHVCLUg/2VPpRwYDgfzyUu4lR 8QG16LkQ==; Received: from ppp118-209-55-253.lns20.mel4.internode.on.net ([118.209.55.253]:50179 helo=[192.168.1.126]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b2phV-000t61-K5 for clue@ietf.org; Wed, 18 May 2016 10:51:01 +1000 To: clue@ietf.org References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> From: Christian Groves Message-ID: <174cc59a-2d87-31a1-6d4d-61f38c712325@nteczone.com> Date: Wed, 18 May 2016 10:50:58 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 00:51:07 -0000 Hello Simon and Paul, In general the text looks OK to me. I've proposed some editorial updates below mainly to remove things like "we". 1st Paragraph replace sentence starting with "Among such requirements..." with "Requirements include: (i) the use of cryptography and authentication; (ii) protection of all sensitive fields; (iii) mutual authentication between CLUE endpoints; (iv) the presence of authorization mechanisms; (v) the presence of native defence mechanisms against malicious activities such as eavesdropping, selective modification, deletion, replay (and related combinations thereof). 2nd paragraph 1st sentence reword: "The CLUE protocol is an application-level protocol allowing a Media Producer and a Media Consumer ..." 4th paragraph proposed reword: There is extra information carried by the CLUE protocol which is not associated with the CLUE data model schema and which exposes information that might be of concern. This information is primarily exchanged during the options negotiation phase. In the Clue Participant state machine "Option State", both parties agree on the version and on the options to be used in the subsequent CLUE messages exchange phase. A malicious participant might either try to retrieve a detailed footprint of a specific CLUE protocol implementation during this initial setup phase, or force the communicating party to use a non-up-to-date version of the protocol which they know how to break. Indeed, exposing all of the supported versions and options could conceivably leak information about the specific implementation of the protocol. In theory an implementation could choose not to announce all of the versions it supports if it wants to avoid such leakage, though at the expenses of interoperability. With respect to the above considerations, it is noted that the OPTIONS state is only reached after the CLUE data channel has been successfully set up. This ensures that only authenticated parties can exchange OPTIONS and related OPTIONS RESPONSE messages and hence drastically reduces the attack surface which is exposed to malicious parties. 5th paragraph proposed reword: The CLUE framework clearly states the requirement to protect CLUE protocol messages against threats deriving from the presence of a malicious agent capable to gain access to the CLUE data channel. Such a requirement is met by the CLUE data channel solution described in [I-D.ietf-clue-datachannel], which ensures protection from both message recovery and message tampering. With respect to this last point, any implementation of the CLUE protocol compliant with the CLUE specification MUST rely on the exchange of messages which flow on top of a reliable and ordered SCTP over DTLS transport channel connecting two CLUE Participants. Last paragraph: With respect to the last paragraph I'm abit ambivalent on it. It doesn't seem to hurt but if we do leave it in then we should probably add something about the aspect of an endpoint. I assume that its the endpoint generating protocol messages not a user. The owner of an endpoint may in fact not be one of the in a conference. Regards, Christian On 14/05/2016 12:27 AM, Paul Kyzivat wrote: > On 5/13/16 7:59 AM, Simon Pietro Romano wrote: >> Dear Paul and others, >> >> I just submitted a revised version of the protocol draft, in which I >> tried to sketch a thorough Security Considerations section. >> Please comment on that (the Security Section, which is also copy-pasted >> below) and on the document as a whole. > > I saw it. This seems to cover the need to address security in the > document. > > Where did the last paragraph (re RBAC) come from? ISTM that this is > speculative - not anything that the WG has discussed. I'd like to hear > what others think about this. > > Thanks, > Paul > >> Thank you once again for your input and comments, >> >> Simon >> >> ***************************************** START OF SECURITY >> CONSIDERATIONS SECTION ********************************************** >> As a general consideration, we remark that the CLUE framework (and >> related protocol) has been conceived at the outset by embracing the >> security-by-design paradigm. This entails that a number of >> requirements have been identified and properly standardized as >> mandatory within the entire set of documents associated with the CLUE >> architecture. Among such requirements we mention the following: (i) >> always leave space for criptography and authentication; (ii) get sure >> that all sensitive fields can be protected; (iii) envisage mutual >> authentication between CLUE endpoints; (iv) envisage the presence of >> authorization mechanisms; (v) envisage the presence of native defense >> mechanisms against malicious activities such as eavesdropping, >> selective modification, deletion, replay (and related combinations >> thereof). Hence, security of the single components of the CLUE >> solution cannot be evaluated independently of the integrated view of >> the final architecture. >> >> Coming to the details of the CLUE protocol, this is an application- >> level protocol allowing a Media Producer and a Media Consumer to >> negotiate a variegated set of parameters associated with the >> establishment of a telepresence session. This unavoidably exposes a >> CLUE-enabled telepresence system to a number of potential threats, >> most of which are extensively discussed in the framework document >> [I-D.ietf-clue-framework]. The security considerations section of >> the mentioned document actually discusses issues associated with the >> setup and management of a telepresence session both in the basic case >> involving two CLUE endpoints acting, respectively, as MP and MC, and >> in the more advanced scenario envisaging the presence of an MCU. >> >> The framework document also mentions that the information carried >> within CLUE protocol messages might contain sensitive data, which >> SHOULD hence be accessed only by authenticated endpoints. Security >> issues associated with the CLUE data model schema are discussed in >> [I-D.ietf-clue-data-model-schema]. >> >> There is indeed some piece of extra information carried by the CLUE >> protocol which is not associated with the standard data model and >> which exposes information that might be of concern. This is >> primarily what gets exchanged during the options negotiation phase. >> From the Clue Participant state machine, we know that in the OPTIONS >> state both parties agree on the version and on the options to be used >> in the subsequent CLUE messages exchange phase. A malicious >> participant might either try to retrieve a detailed footprint of a >> specific CLUE protocol implementation during this initial setup >> phase, or force the communicating party to stick to a non-up-to-date >> version of the protocol which they know how to break. Indeed, >> exposing all of the supported versions and options could conceivably >> leak a bit of information about the specific implementation of the >> protocol. In theory an implementation could choose not to announce >> all of the versions it supports if it wants to avoid such leakage, >> though at the expenses of interoperability. With respect to the >> above considerations, we nonetheless remark that the OPTIONS state is >> only reached after the CLUE data channel has been successfully set >> up. This ensures that only authenticated parties can exchange >> OPTIONS and related OPTIONS RESPONSE messages and hence drastically >> reduces the attack surface which is exposed to malicious parties. >> >> Coming to the content of the protocol messages themselves, the CLUE >> framework clearly states the requirement to protect against threats >> deriving from the presence of a malicious agent capable to gain >> access to the CLUE data channel. Such a requirement is met by the >> CLUE data channel solution described in [I-D.ietf-clue-datachannel], >> which ensures protection from both message recovery and message >> tampering. With respect to this last point, we once again remark >> that any implementation of the CLUE protocol which claims to be >> compliant with the CLUE specification MUST rely on the exchaning of >> messages which flow on top of a reliable and ordered SCTP over DTLS >> transport channel connecting two CLUE Participants. >> >> As a final consideration, we remark that policy-based management of a >> CLUE-compliant telepresence architecture, though not in the scope of >> the CLUE WG charter, can easily be realized. To the purpose, common >> Role-Based Access Control (RBAC) approaches can be leveraged. In >> RBAC, the following elements are identified: (i) Users; (ii) Roles; >> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >> above elements, a direct mapping exists onto the main CLUE entities. >> As an example, RBAC objects map onto CLUE data model objects and RBAC >> operations map onto CLUE protocol operations. Future documents can >> define an RBAC framework for CLUE, by first focusing on the >> definition of roles and then specifying the needed permission policy >> sets and role policy sets (used to associate policy permission sets >> with specific roles). With these policies in place, access to >> information compliant with the CLUE data model can be appropriately >> controlled. As far as assigning users to roles, the Users in the >> RBAC model relate directly to the element in the CLUE >> object. The element is comprised of elements >> representing a specific user in the telepresence system. Each >> element contains a 'personID' attribute acting as a unique >> identifier and a element describing their role in the >> CLUE session ("presenter", "timekeeper", "attendee", "minute taker", >> "translator", "chairman", "vice-chairman") . Thus, each authorized >> user can be associated with a well-defined role in the RBAC model. >> >> ***************************************** END OF SECURITY CONSIDERATIONS >> SECTION ********************************************** >> >> >> >> >> >>> On 19/apr/2016, at 20:07, Paul Kyzivat >> > wrote: >>> >>> The protocol needs to have a Security Considerations section before it >>> can progress. That is the main gating item at this point. >>> >>> This should be pretty simple. The following are my thoughts about what >>> should be in it: >>> >>> - it should reference the security considerations in the framework. >>> They cover many important issues and those probably don't need to be >>> restated as long as they are referenced. >>> >>> - it should reference the security considerations in the data model. >>> That document has most of the critical data to be concerned with. >>> >>> - a reference to the security considerations in the clue-datachannel >>> draft will cover the protection of the content of the protocol >>> messages. >>> >>> - There probably should be a brief discussion of the extra data in the >>> protocol (not in the data model) that exposes information that might >>> be of concern. I think this is primarily in the options negotiation: >>> exposing all the versions and options supported could conceivably leak >>> a bit of info about the specific software. In theory an implementation >>> could choose not to announce all the versions it supports if it wants >>> to avoid such leakage, though it would reduce interoperability. And of >>> course it will only be relevant when there are multiple versions and >>> options. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _\\|//_ >> ( 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: spromano@unina.it >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sat May 21 13:20:55 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0412B03B for ; Sat, 21 May 2016 13:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWXa7ilOdQqv for ; Sat, 21 May 2016 13:20:53 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E604D12B007 for ; Sat, 21 May 2016 13:20:52 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x201so227005981oif.3 for ; Sat, 21 May 2016 13:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=C1DMGHcAge6K3jNQLtz2Lcu4dmJlbohJS9u/su6JqBs=; b=DMc6aJ5Y+e3JgeoeHdr/oMPXh5gtaeFdcKxFJKv4iFIoJfFzT9sFpmLO9xHzAAsABP /+EzvwUvrS9mHqrile39apQIIzBL9UMFq4lyKpFlgwNyEqP4WQrFiBYt/L3nlfAxv1PC wMFy8tDNiA/uEvof0MJhUr6bz4f1gx4L25Ki9WRIm4Ig6uNnXSQ4jmoAF0SNKSWC+On/ UIQeBZEy/voyn61HDvWoXg27q1TqRDR+XO/6niiV6kG9Wc7OdcHc30bhgKkUkMWrOE7i 2eu2NxfLFWX+wKF8smHR41NqPOAXGHbIdx8KvY0l1Mid3o5Uw4B0YRlg91NvHMb4PzId shxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=C1DMGHcAge6K3jNQLtz2Lcu4dmJlbohJS9u/su6JqBs=; b=it7Cu8mLs5U1+uuS+Kd6LL53jxau+Ea0zOOh93yZaVN4MGe2RqbvM4E/EigcD0X0bC 3Immdyp7q8uV/+pFyZ/gl+WQFUuJJiwLjn4XIJi3WYi+JCErLUh1i9IGa2Z0VBagxwmZ VfDs1kZtNuqx4//5TI7gJm+5WHhBUFK/46NCMdVh26EkPgGRgB/H/vsF6LwpVhtOpmZh kep2LfbANsONmR8l0Syh7ECQLVFFmNJh+DlPiIvMGspaV1BMwXahXx4j2/iw8ex5jHyo f0SiIPFUKK0hf1cpLb+pCtApWz4sX6QJ0KKK+UL2XvGgxGWujvJgO2piiFPoCVCe0JPp 8SYg== X-Gm-Message-State: AOPr4FUPj9ZYazxeJOBY0Qm9W9ptipSKZ0kEyMWosnVyaiUuyJdNGMYvQ4fijFNwVgWCPdTDyU+o4c23FFo0zA== MIME-Version: 1.0 X-Received: by 10.157.25.137 with SMTP id k9mr5890027otk.131.1463862052309; Sat, 21 May 2016 13:20:52 -0700 (PDT) Received: by 10.202.204.1 with HTTP; Sat, 21 May 2016 13:20:52 -0700 (PDT) Date: Sat, 21 May 2016 16:20:52 -0400 Message-ID: From: Daniel Burnett To: "clue@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c09b194a0ef2505335ff10f Archived-At: Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 20:20:54 -0000 --94eb2c09b194a0ef2505335ff10f Content-Type: text/plain; charset=UTF-8 This message announces the start of a 2 week WGLC for draft-ietf-clue-rtp-mapping to review the updated draft. The last call will end at midnight on Saturday, 4 June 2016. PLEASE REVIEW NOW. -- Dan (for the Chairs) --94eb2c09b194a0ef2505335ff10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This message announces th= e start of a 2 week=C2=A0WGLC=C2=A0for draft-ietf-clue-rtp-mapping to review the updated d= raft. The last call will end at=C2= =A0midnight=C2=A0on Saturday,= =C2=A04 June 2016.

PLEASE REVIEW NOW.

-- Dan (= for the Chairs)
--94eb2c09b194a0ef2505335ff10f-- From nobody Tue May 24 21:43:07 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DC512D5A5 for ; Tue, 24 May 2016 21:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYyZsCJEKAsm for ; Tue, 24 May 2016 21:43:03 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BBF12D0F7 for ; Tue, 24 May 2016 21:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U/DTRlgwQcevotQXNW2Nzhzzqv+/LWulL8VWs8VX/Hw=; b=QrjzmMHM3FhZIzF29d6pUa2NyV bEWan8taZtygoWVzPiGWjppx22LbUlKqf1AbzIjbiL+ofo1dB6zl1lM2RyeBzszKVU5jaHBLQ4L55 db96yMZu+giIGuQcdKP6ZqFWF1RSAf3HOq92tXD/mVWD/rKHJd2kJmG0lnlH9zMgwgRVXXu165sJY nN26hrH+yd681wGOWuq3hycP9iXhiX/1VB45kPcnobvLT4qqRzRym9eKN0dRc/ienctroUogPcYHl DxKxSE1iYOb1RLfFEy//365yg97/wwmn4chbpl9Fsub1FM5lrJv1r0MmO57Bg1nDiFiwHfYXuszYp IakgWixg==; Received: from ppp118-209-151-97.lns20.mel8.internode.on.net ([118.209.151.97]:52430 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b5Qeq-00209g-Ap for clue@ietf.org; Wed, 25 May 2016 14:43:00 +1000 To: clue@ietf.org References: From: Christian Groves Message-ID: Date: Wed, 25 May 2016 14:42:55 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 04:43:05 -0000 Hello Dan, List version picks up my comments to the previous WGLC so I don't have any further comments. I support this moving forward. Christian On 22/05/2016 6:20 AM, Daniel Burnett wrote: > This message announces the start of a 2 week WGLC for > draft-ietf-clue-rtp-mapping to review the updated draft. The last call > will end at midnight on Saturday, 4 June 2016. > > PLEASE REVIEW NOW. > > -- Dan (for the Chairs) > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue May 31 14:38:03 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F52612D15A; Tue, 31 May 2016 14:38:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 14:38:00 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 21:38:00 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-clue-data-model-schema-14: 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: ---------------------------------------------------------------------- The document looks good, I just have a couple of items on the security considerations to discuss as they are not mentioned and I'm not sure if they have a good reason to be excluded. 1. Session encryption to prevent active (tampering) or passive (information gathering for example) attacks. Integrity protection and authentication are mentioned, but without looking through a few documents, I don't know if that means encryption or some hash value comparisons or something else. 2. Schema drafts tend to cover the need for well-formed schemas as part of the security considerations. Can you add something in about that (not much is required, but it's good for implementers to know this is important)? You can see two recent examples for guidance: YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ From nobody Tue May 31 15:25:42 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF5D12D0AB; Tue, 31 May 2016 15:25:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531222537.20224.79673.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 15:25:37 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 22:25:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-15.txt Pages : 74 Date : 2016-05-31 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/