Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

Martin Thomson <> Thu, 17 January 2019 02:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAD8F130F12; Wed, 16 Jan 2019 18:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Pes0j0Ia; dkim=pass (2048-bit key) header.b=e6rUgxar
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V6zbr7Tv5oUg; Wed, 16 Jan 2019 18:24:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1134912D4EA; Wed, 16 Jan 2019 18:24:54 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id 144C56476; Wed, 16 Jan 2019 21:24:53 -0500 (EST)
Received: from web4 ([]) by compute1.internal (MEProxy); Wed, 16 Jan 2019 21:24:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=RL9 l84aJ4Jp5k50iXNmCXbOVU+PQkJm1gmnWtW4Mpn0=; b=Pes0j0IaQ3vo5vDiTm9 t8VPymdPnoIyxh1r59DO3/Z5C0bR5uhGIN/Dss0kve51P1dRdhsbruXPh0j+UHZV 08Oj9+wqT1G3pblTFHCrUI1J2LRpiTTGsT3ZzswJsD2SHkGGL/OiSwXW1AxZ0XSN p6g1HnVyzkv99jkzcbaMN8WH/5IL8xtt/zRUwgIxi7KeD7J4S3pwsnjM4IL6yG+9 iVhUc/TcZXU7lwblpv8vcSPXY/WinP8m1ASxqH/ArRFseRJ6gwlvOW29GC9erQkr lygR42wtdiF39xxiXsQu8Q6y479K2LRxtcxGHyl4hEfS48AozpYg26omFJS65u+T tzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RL9l84aJ4Jp5k50iXNmCXbOVU+PQkJm1gmnWtW4Mp n0=; b=e6rUgxarKYOSJ4LeW8grolFYCL9d1Fb44fvxifVsliPaHMea5aOU1H/yt w7gn/sJFSHORMAK/fa8xG9IXfPVrkOJFGr3LszDEvUIAZ00pRVSoQL0SGG9UMoDu iH3oq8iltxeaR8fokkLSV/wkJbE/kb2syIcxEICGhwwLgfVjPK0Fk6+2GIUDg0go jjkVudhBuEYBWZDDSavSabFmD6dVDFmGzoHx+TDhDUy+/5anX77psWZncioBHEdb WhDMEgsq3ntptWbSej5erG2L7XbG586G1bmHkwPTffTWyQYmF17SdAu/V+fKnEN1 FM+OMzuapht5hHEt2ZyrNIL1SA1Dg==
X-ME-Sender: <xms:c-c_XE5B0Sc8apZu6f177ft2ru2hYD0A2yor6-LoWr-dnD6xA8BOeQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeigdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof hfufgjffesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv thenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:c-c_XBX09cuCtF2a9G8HSHXvJLZOB9XylnlEJvyBm48cA8In_WiSDw> <xmx:c-c_XCLxUFo7cJok-QBCkQZf7orBOcL9cSQjP8fCPXG-MG4vSqhUJg> <xmx:c-c_XGRmFU0ep9-GpxFRGlxX-uCt-Hvgw-Qv5drV7JZe5NKxMDBUWw> <xmx:dOc_XACSqX_PKrr-JniHbnC4_mURlrWSmbwh5OKTEJWHKuFo4qaROA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9E1B2BA783; Wed, 16 Jan 2019 21:24:51 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
To: Magnus Westerlund <>, Flemming Andreasen <>, mmusic <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-36e4bfd3
References: <> <>
In-Reply-To: <>
Date: Thu, 17 Jan 2019 13:24:51 +1100
Archived-At: <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jan 2019 02:24:57 -0000

Hi Magnus, thanks for reviewing.

PR for all the changes here:

And responses inline.

On Wed, Jan 16, 2019, at 23:31, Magnus Westerlund wrote:
> I assume it is the presentation language in Section 3 of RFC 8446 that 
> you are referring to? Can you be a bit more explicit in the reference to 
> point to the actual section?

Sure.  Done.

> 2. Section 3.2:
> "   A WebRTC identity assertion is provided as a JSON [JSON] object that
>    is encoded into a JSON text."
> That doesn't match what is written in Sections 7.4 and 7.4.1 of draft-
> ietf-rtcweb-security-arch-17.
> What is provided as an JSON is the fingerprint, not the Identity 
> assertion (see 7.4)
> What 7.4.1 says about identity assertions are:
>    Once an IdP has generated an assertion, it is attached to the SDP
>    offer/answer message.  This is done by adding a new 'identity'
>    attribute to the SDP.  The sole contents of this value are a
>    Base64-encoded [RFC4648] identity assertion.
> Thus, they appear to be only Base64 encoded binary blobs.

That binary blob is a UTF-8 encoded JSON text.  That format is described in Section 7.6 of the security-arch doc.  I admit, having read your comment and gone looking for this, I would have missed this connection.  I think that the security-arch needs some editorial work.  The process is:

1. collect all fingerprint attributes
2. assemble into an object as described in 7.4
3. serialize that object into a JSON text
4. pass that as a string to the IdP (the IdP treats this as opaque)
5. get back a JSON object in the form described in 7.6
6. serialize that object into a UTF-8-encoded JSON text
7. base64 encode THAT to produce the a=identity attribute value

That is what is implemented at least.

This needs to be a JSON object because  the relying party needs to be able to extract the attributes described in 7.6 in order to instantiate the IdP.

> 3. Section 3.2:
> "The SDP "identity" attribute includes the base64 [BASE64] encoding of
>    the same octets that were input to the hash."
> I don't understand this sentence. What was included into which hash. 
> Please rewrite to be descriptive of which information to retrieve or at 
> least be explicit to reference the relevant component of the identity 
> attribute.

I made an attempt.  Take a look at the PR to see if that helps at all.

> 4. Section 3.2:
>   "The "external_id_hash"
>    extension is validated by performing base64 decoding on the value of
>    the SDP "identity" attribute, hashing the resulting octets using SHA-
>    256, and comparing the results with the content of the extension."
> To my understanding the binary blob that is Base64 encoded and put in 
> the SDP Identity attribute after the IdP has taken the fingerprint and 
> the user identity assertion is IdP specific and really a binary blob 
> that only the IdP specific validator can check. So why is the validation 
> of a binary blob done on the binary blob rather than the base64 
> encoding? Risk for non canonical encoding? I don't quite see that as the 
> IdP will produce the assertion and even the base64 encoding happens once 
> before being provided in SDP and can thus the hash can be run on the 
> Base64.

The potential for disagreement about padding is what concerned me here.  Padding in base64 is somewhat erratic.  Then there is the domain transform from string (how the headers are ostensibly represented) and octet sequences.  Avoiding another need to describe that transformation (with UTF-8 involved, I would assume), seemed less hazardous.

The value needs to be decoded anyway, so this seemed like the most robust approach.

> 5. Section 3.2:
>    "Where a PASSPoRT is used, the compact form of the PASSPoRT MUST be
>    expanded into the full form.  The base64 encoding used in the
>    Identity (or 'y') header field MUST be decoded then used as input to
>    SHA-256."
> Also here there appear to be some mismatch between what RFC 8224 defines 
> as a full passport object. See Section 4.1 of RFC 8224:
>   After these two JSON objects, the header and the payload, have been
>    constructed and base64-encoded, they must each be hashed and signed
>    per [RFC8225], Section 6.  The header, payload, and signature
>    components comprise a full PASSporT object.

I've tried to address that in the same commit above.  The construction of the JWS is - as usual - subject to multiple base64 rounds, so the trick is in identifying the right binary bits to hash.  I think that what I have described is clearer.

> 6. As currently written but questioned above, if the object to hash is a 
> JSON object, are the delimitation of the object given, such that one 
> knows if any final CRLF are to be included or not.

All of these protocol steps are vulnerable to whitespace changes.  PASSPorT rather naively tries to address this point with canonicalization, but this doesn't.  If whitespace is caught by the a=identity attribute or Identity: header field, then that whitespace needs to be hashed.  Do you think that needs to be said explicitly?  I didn't do that, but can if you think that helps.

> 7. Section 3.2:
> Identity bindings in either form might be provided by only one peer.
>    An endpoint that does not produce an identity binding MUST generate
>    an empty "external_id_hash" extension in its ClientHello.
> What is an empty "external_id_hash" extension? Is that with 0 bytes of 
> hash data?

Correct.  Updated in the PR.