Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 17 May 2018 18:04 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706EC12D941 for <rtcweb@ietfa.amsl.com>; Thu, 17 May 2018 11:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 52CO4McFOBdj for <rtcweb@ietfa.amsl.com>; Thu, 17 May 2018 11:04:56 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 B5712126CD8 for <rtcweb@ietf.org>; Thu, 17 May 2018 11:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526580293; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/d2ho8QffhVWBIPvMoY6Ehjeac9DonnggCVcJEby3Sc=; b=d/pOEk1V+RdO+wVK5RlmhYTMG8YKP4XMdmKzg5Db+7QYKh6/QHpOE9mxjdrMTpQi ccXmm6FRFTLPv+zFSOYoKzLrnti5mShj/EZCR4o6sl2M0lY+ujn5q2aXxNGN4yvX sn+tHcqYM6mcDPC3u8D3Dr3KWpSvrDWr1I93OsK8MZ0=;
X-AuditID: c1b4fb25-f8bff700000079fb-f3-5afdc4451fa3
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.49.31227.544CDFA5; Thu, 17 May 2018 20:04:53 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0382.000; Thu, 17 May 2018 20:03:45 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Cullen Jennings <fluffy@iii.ca>
CC: RTCWeb IETF <rtcweb@ietf.org>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute
Thread-Index: AQHT6RGfenU2OZxm10q2tYkeSmM/qKQ0G04AgAAiMMA=
Date: Thu, 17 May 2018 18:03:44 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se>
References: <D71B49BA.2F885%christer.holmberg@ericsson.com> <C3E953BF-3C77-4ABF-B1C8-DD487D814293@iii.ca>
In-Reply-To: <C3E953BF-3C77-4ABF-B1C8-DD487D814293@iii.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.169]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72EEFB16ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7rq7rkb9RBtPWyFh8WP+D0WLtv3Z2 ByaPJUt+MnlcPv+RMYApissmJTUnsyy1SN8ugStj1YRT7AXLFjJWPJt+l62BsWEuYxcjJ4eE gIlE/7VnrF2MXBxCAkcYJba+ucwM4SxmlNizcjuQw8HBJmAh0f1PG6RBREBZ4tyOu8wgNrOA osSX5fPZQGxhgRiJxbuXMkPUxErc378NyraS+DT3AhvIGBYBVYl1z0xBwrwCvhIdE/rASoQE siVO9cwGszmByp/sfg82klFATOL7qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sULYShIn uzezQNTnS+x9N5UJYpegxMmZT1gmMIrMQjJqFpKyWUjKZgFdyiygKbF+l/4sqCendD9kh7A1 JFrnzGVHFl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCuDm75rbqD8fIbx0OMAhyM Sjy8wvv+RgmxJpYVV+YeYpTgYFYS4fWrBArxpiRWVqUW5ccXleakFh9ilOZgURLnfWi+OUpI ID2xJDU7NbUgtQgmy8TBKdXAqF79S1ln1cl/Qi635k/4nFPqsM93gqPBFpbSpAtz/A6ebg2b zVGWbL7RedFrB1utoz2pb55uKS05lp3tNnfm37pfV8pVX54+EvjSQmSL67eAxbfOizFwm1ed DtW6tPlJ+I5l+f5rp31ov/f5a2zXgUBBxfiwG+Gh05dNks+w9ZKpj16ZtEVVRImlOCPRUIu5 qDgRAK6z0cmnAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/HvS6fgCg8yF3ayWvwivzpmYDFJM>
Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 18:04:59 -0000

Hi,

A few questions/comments on the SDP identity attribute.

Q1:
----

The draft says that, at minimum, the fingerprint needs to be bound to the identity.

Does this mean that, in order to include an SDP identity attribute in an offer/answer, the offer/answer MUST also contain at least one SDP fingerprint attribute? Based on the text about generating the identity it seems like that, but it is not very clear in the SDP procedures.


JSEP requires DTLS/SRTP which requires adding the fingerprint so I think this is already required. Also JSEP points out lack of fingerprint will cause negotiation failure.

This is not about JSEP, but the definition of the SDP identity attribute. As this attribute can (I assume) be used on the wire, it needs to defined as such.

The USAGE of the attribute can then be scoped to WebRTC, JSEP, or whatever.


Q2:
----

Section 5.6.4.1 says:

   "The "a=identity" attribute MUST include all

   fingerprint values that are included in "a=fingerprint" lines."

First, related to the generation of the assertion value, it is unclear how this is implemented. For example, is there a separate JSON object (section 5.6.4) provided to the IdP for each fingerprint? The text talks about “single” fingerprint in the object. Or, are all fingerprints included in the same JSON object?

Yah, I think it would get a Identity token for each fingerprint via a Generate Assertion for each fingerprint. But I think that is largely WebRTC issue.

While it may be an WebRTC issue how to use multiple fingerprints in general, it is an SDP issue how to encode the attribute.


Second, it is unclear what “attribute MUST include all fingerprint values” means. I assume that the attribute will only include a single attribute assertion value, but that the value will be generated by the IdP based on all fingerprint values?

So if there were multiple fingerprint, the SDP would have multiple Identity lines.


In that case I don’t understand the statement in section 5.6.4.2, that says:

   “The semantics of multiple identity attributes are undefined.”

Also, to me “attribute MUST include all fingerprint values” sounds like a single attribute with multiple fingerprint values.



Q3:
----

In the example in Section 5.6.4.1 the SDP fingerprint attribute is included as a session-level attribute. However, it is a media-level attribute. AFAIR, media-level attributes cannot be included as session-level attributes.


I think fingerprint is valid as both session-level or media-level so I suspect this is fine. JSEP also says that if the certs are the same, then it can be session level but if different then must be media level. So I think this is covered in JSEP.

JSEP does not define the attribute. If the attribute can be used both on session- and media-level it needs to be defined in such way in draft-ietf-rtcpweb-security-arch.

Regards,

Christer