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

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed this document and I don't think this is yet ready for publications. There appears to be issues that appears to question the possibility for interoperable implementation.

1. Section 3.2:

   The "extension_data" for the "external_id_hash" extension contains a
   "ExternalIdentityHash" struct, described below using the syntax
   defined in [TLS13]:

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?

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.

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.

Can you also be more explicit that the SDP "identity" attribute is defined in draft-ietf-rtcweb-security-arch?

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.

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.

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.

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?

Cheers

Magnus



On 2019-01-07 15:09, Flemming Andreasen wrote:
Greetings MMUSIC

This is to announce a 2 week WGLC on the draft:

    https://www.ietf.org/id/draft-ietf-mmusic-sdp-uks-03.txt

as Proposed Standard. Please review and provide any comments you may have on the document by Monday, January 21, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------