New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identity Assertions and RTCDtlsTransport objects #114

Open
aboba opened this Issue Jun 25, 2014 · 7 comments

Comments

Projects
None yet
3 participants
@aboba
Copy link
Contributor

aboba commented Jun 25, 2014

Since it is now possible to have distinct RTCDtlsTransport objects for RTP and RTCP, this raises some questions. For example:

a. Are the certificates used for RTP and RTCP DTLS Transports necessarily the same on both the local and remote side? If they are supposed to be the same, what happens if they aren't?
b. Can different identities be asserted for the RTP and RTCP DTLS Transports? Does this make sense in some circumstances? If so, when?

@robin-raymond robin-raymond added the 1.1 label Jun 28, 2014

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Jul 8, 2014

Within a browser, it would appear to me that the certificates used for RTP and RTCP DTLS Transports should be the same (assuming that RTP and RTCP aren't multiplexed).

However, I am wondering whether a SFU could potentially terminate RTCP but not RTP, in which case the certificates and asserted identities might be different between RTP and RTCP.

A question is whether a browser should care about what the asserted identity is for RTCP, or whether it should just focus on RTP. So while a browser would always use the same certificate and identity for both RTP and RTCP, the question is whether it should be "strict in what it sends, liberal in what it is willing to receive".

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Jul 8, 2014

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Jul 8, 2014

As noted by Martin:

"a=identity is a session-level attribute and they should (MUST?) only be one."

[BA] So an application desiring compatibility with WebRTC 1.0 needs to require that the validated peer identities for RTP and RTCP be the same. Also, an ORTC implementation will only assert a single identity for RTP and RTCP. However, an application not requiring backward compatibility with WebRTC 1.0 could allow validated peer RTP and RTCP identities to be different.

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Jul 14, 2014

Proposed resolution:

Add the following text to Section 14.5:

"NOTE: Where RTP and RTCP are not multiplexed, distinct RTCRtpIceTransport, RTCRtpDtlsTransport and RTCIdentity objects can be constructed for RTP and RTCP. However, while it is possible for getIdentityAssertion() to be called with different values of provider, protocol and username for the RTP and RTCP RTCIdentity objects, application developers desiring backward compatibility with WebRTC 1.0 are strongly discouraged from doing so, since this is likely to result in an error."

Change the following text in Section 14.6 from:

" It is possible that multiple assertions will be signalled. A browser MAY either choose to treat
this as an error or ignore the additional assertions. If multiple different
assertions are validated, then they MUST produce identical identity
values."

To:

" Where RTP and RTCP are not multiplexed, it is possible that the assertions for both the RTP and RTCP DTLS transports will be validated, but that the identities will not be equivalent. For applications requiring backward compatibility with WebRTC 1.0, this MUST be considered an error. However, if backward compatibility with WebRTC 1.0 is not required the application MAY consider an alternative, such as ignoring the RTCP identity assertion."

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014

Robin Raymond
Added section on WebRTC 1.0 compatibility issues, responding to Issue w…
…3c#66

Added Identity support, as described in Issue w3c#78
Reworked getStats method, as described in Issue w3c#85
Removed ICE restart method described in Issue w3c#93
Addressed CNAME and synchronization context issues described in Issue w3c#94
Fixed WebIDL issues noted in Issue w3c#97
Addressed NITs described in Issue w3c#99
DTLS transport issues fixed as described in Issue w3c#100
ICE transport issues fixed as described in Issue w3c#101
ICE transport controller fixes made as described in Issue w3c#102
Sender and Receiver object fixes made as described in Issue w3c#103
Fixed RTCRtpEncodingParameter default issues described in Issue w3c#104
Fixed 'Big Picture' issues descibed in Issue w3c#105
Fixed RTCRtpParameter default issues described in Issue w3c#106
Added a multi-stream capability, as noted in Issue w3c#108
Removed quality scalability capabilities and parameters, as described in Issue w3c#109
Added scalability examples as requested in Issue w3c#110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue w3c#111
Removed header extensions from RTCRtpCodecParameters as described in Issue w3c#113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue w3c#114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue w3c#116
Added layering diagrams as requested in Issue w3c#117
Added a typedef for payload type, as described in Issue w3c#118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue w3c#121
Added explanation of Voice Activity Detection (VAD), responding to Issue w3c#129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue w3c#130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue w3c#131
Addressed ICE terminology issues, as described in Issue w3c#132
Separated references into Normative and Informative, as noted in Issue w3c#133

@aboba aboba reopened this Jul 17, 2014

@elagerway elagerway added 1.0 and removed 1.1 labels Jul 17, 2014

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Jul 29, 2014

At the ORTC CG meeting on July 20, it was suggested that the same provider, protocol and username should be automatically shared between the RTP and RTCP RTCIdentity objects. However, it was not clear how to make this happen.

While the "component" of an RTCIdentity object can be determined from RTCIdentity.transport.transport.component, there is no easy way to determine the RTP RTCIceTransport given the RTCP RTCIceTransport, RTP RTCDtlsTransport given the RTCP RTCDtlsTransport or RTP RTCIdentity object given the RTCP RTCIdentity object.

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Jul 13, 2016

Until 1.0 has a concrete proposal that has actual implementations that validate its usage in the real world, I think we should not touch this at all.

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Dec 27, 2017

At this point, there is only one identity implementation for WebRTC 1.0 - and 20+ open issues. So this issue is unlikely to be resolved in the near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment