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

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 May 2018 10:20:03 +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.

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?

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?

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.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 17 May 2018 11:50:04 -0600

> On May 11, 2018, at 4:20 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

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. 

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

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. 

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

So if there were multiple fingerprint, the SDP would have multiple Identity lines.
 
> 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…

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. 

> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 May 2018 18:03:44 +0000

Hi,

Q1:
----

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:

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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 May 2018 06:42:04 +0000

Resending, as it seems like my reply to Cullen yesterday got stucked somewhere on the Internet.

Regards,

Christer

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 17 May 2018 at 21:03
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute

Hi,

Q1:
----

Q2:
----

Section 5.6.4.1 says:

Q3:
----

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 May 2018 15:49:12 -0400

Christer just made me aware of this discussion. I have a couple of 
comments about definition of the attribute.

FIRST:

I find the extension mechanism to be atypical. Currently it is:

    identity-attribute  = "identity:" identity-assertion
                          [ SP identity-extension
                            *(";" [ SP ] identity-extension) ]

This sets the list of extensions off from the identity assertion with a 
space while then separating them from one another by semicolons. This 
seems to blend SDP and SIP syntax oddly. I would expect to go more fully 
in one direction or the other. Either:

    identity-attribute  = "identity:" identity-assertion
                            *( SP identity-extension )

or

    identity-attribute  = "identity:" identity-assertion
                            *(";" identity-extension)

(May require tweaking extension-att-value.)

SECOND:

Form of SDP attribute definitions:

Historically there have been problems with the definitions of new SDP 
attributes. Especially, the manner of defining the syntax was 
inconsistent. RFC4566 gave insufficient guidance on how to do this. 
draft-ietf-mmusic-rfc4566bis (especially section 8.2.4.1) has provided 
more guidance on how to do this. Please do your definitions in that 
style. For instance:

    5.6.4.2  a=identity Attribute

    The identity attribute is session level only.  It contains an
    identity assertion, encoded as a base-64 string [RFC4648].

      Attribute Name: identity

      Attribute Value: identity-value

      Usage Level: session

      Charset Dependent: No

      Mux Category: ???

    The Augmented BNF syntax [2] for the attribute is:

      identity-value = identity-assertion
                          [ SP identity-extension
                            *(";" [ SP ] identity-extension) ]
                          ; perhaps altered based on above discussion

    [continue on with remainder of section.]

    7.  IANA Considerations

    This document defines the SDP attribute,'identity'.
    The details of the attribute are defined in Section 5.

    For issues regarding this attribute contact Eric Rescorla
    ([email-masked]).

But it seems that current practice is moving away from identifying 
individuals in the contact information, in favor of listing a wg mailing 
list or the iesg mailing list.

	Thanks,
	Paul

On 5/18/18 3:46 PM, Christer Holmberg wrote:
> FYI,
> 
> You may want to take a look at this. I wasn’t even aware that they are 
> defining an SDP attribute in the security architecture document, and as 
> far as I know there has been no request to e.g., the SDP security 
> directorate to look at it.
> 
> Regards,
> 
> Christer
> 
> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *Christer 
> Holmberg
> *Sent:* 18 May 2018 08:42
> *To:* Cullen Jennings <[email-masked]>
> *Cc:* RTCWeb IETF <[email-masked]>
> *Subject:* Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on 
> SDP identity attribute
> 
> *From: *Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Thursday 17 May 2018 at 21:03
> *To: *Cullen Jennings <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *RE: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on 
> SDP identity attribute
> 
> Hi,
> 
>     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.
> 
>     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?
> 
> 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
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 May 2018 11:46:34 -0600

You are right Christer, I was looking at this the wrong way of how it was used vs the defn. of Identity. Let me answer the questions from only the point of view how the Identity header is defined by draft-ietf-rtcweb-security-arch and not how the identity header is used in WebRTC in general. 

> On May 17, 2018, at 12:03 PM, Christer Holmberg <[email-masked]> wrote:
> 
>  
> Hi,
>  

It seems to me that the defn of an Identity header does not need it to be use for fingerprints at all. What goes in it the assertion is pretty much determined by the IdP. Some future system that did not have fingerprints but used token binding or blockchain style smart contracts could probably work just fine. It’s up to the IdP. 

So I might be wrong but I would say that Identity header does not require a fingerprint to be in the SDP, but when Identity is used in WebRTC, there will also be a fingerprint. 

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

As you point out, all that is the Identity assertion definition defines is how to encode it and that’s base 64 of JSON so that part is fine. Section 5.6.4.1 is about how it Identity is used in the contact of WebRTC. How the IdP does this is pretty out of scope of IETF stuff but I think you raise a good point that this implies that in the WebRTC case, if there 

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

Section 8 of RFC4572 that defines the fingerprint attribute says that it is both at session and media-level attribute.  (2nd para of https://tools.ietf.org/html/rfc4572#section-8 )

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 May 2018 19:49:13 +0000

Hi,

> You are right Christer, I was looking at this the wrong way of how it was used vs the defn. of Identity. 
> Let me answer the questions from only the point of view how the Identity header is defined by 
> draft-ietf-rtcweb-security-arch and not how the identity header is used in WebRTC in general. 
> 
>> Q1:
>> ----
>>  
>> 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.
>  
> It seems to me that the defn of an Identity header does not need it to be use for fingerprints at all. What goes in it the 
> assertion is pretty much determined by the IdP. Some future system that did not have fingerprints but used token binding 
> or blockchain style smart contracts could probably work just fine. It’s up to the IdP. 
>
> So I might be wrong but I would say that Identity header does not require a fingerprint to be in the SDP, but when Identity 
> is used in WebRTC, there will also be a fingerprint. 

But, the text says that, at a minimum, the fingerprint needs to be bound to the identity.

If that is not true, that statement needs to be removed/modified. If it does apply to WebRTC, it needs to be clear that it is a WebRTC requirement, not a generic attribute requirement.

---

>> 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?
>  
> As you point out, all that is the Identity assertion definition defines is how to encode it and that’s base 64 of JSON 
> so that part is fine. Section 5.6.4.1 is about how it Identity is used in the contact of WebRTC. How the IdP does this is 
> pretty out of scope of IETF stuff but I think you raise a good point that this implies that in the WebRTC case, if there 

My question was whether each assertion will be in a separate JSON. But, when re-reading the draft I think I found the answer. The ABNF can contain multiple assertions, and there is text saying that each assertion is a JSON.

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

---

>> 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.
>   
> Section 8 of RFC4572 that defines the fingerprint attribute says that it is both at session and media-level attribute. 
> (2nd para of https://tools.ietf.org/html/rfc4572#section-8 ) 

Yes, but this draft defines the Identity attribute :)

Just because the Identity attribute can be used together with the Fingerprint attribute it doesn't mean that it automatically inherits the properties of the Fingerprint attribute - especially since you earlier indicated that there may be cases where the fingerprint isn't even used for the assertion. The definition of the Identity attribute needs to state whether it can be used on session and/or media-level.

Regards,

Christer