Draft: draft-ietf-perc-private-media-framework

Commentary: This is related to text that was in framework that said Investigate adding ability to enable the transmission of one - way media from a non - trusted device ( e.g. , announcements ) . One possible solution is to have the Key Distributor send an " ekt_key " message that is explicitly labeled for receive - only and giving that to announcement servers . A possible approach would be to define EKT Keys with a SPI , for example , for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters . Endpoints would never send media with EKT Keys with those SPI values . 
 The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server . The EKT Key contains the key , cipher , MKI , etc . The KMF could add " direction " as a new field , which would be " send - only " ( sent to announcement servers ) , " receive - only " ( sent to endpoints ) , or " send - receive " for all the " normal " EKT Keys used in the conference between endpoints . Using SPI values to have certain meaning would work , but the device would have to know its role . That might lead to some confusion . So , I 'd prefer an explicit indication to the device . Also , we might want to use this to admit certain endpoints into the conference ( e.g. , large - scale " webinars " or similar ) where endpoints participating should be in listen - only mode . ( Of course , any media they transmit could be discarded , but having a receive - only key makes that more explicit , too . ) 
 Note that at IETF 96 , there was no interest in working on this requirement , in part indicating that announcements , etc would come out - of - band and likely not involve media . The general sentiment was to remove this from the to do list . 
 We can close this open issue till there is energy to work on in the WG
Paragraph (version A):
Interaction between the Key Distributor and the call processing
function may be necessary to for proper conference-to-endpoint
mappings, which may or may not be satisfied by getting information
directly from the endpoints or via some other means.  See dolist for
a related item in the To Do list.
Paragraph (version B):
Interaction between the Key Distributor and the call processing
function is necessary to for proper conference-to-endpoint mappings.
This is described in identity.
Paragraph (version A):
If there is a need to encrypt one or more RTP header extensions end-
to-end, an encryption key is derived from the end-to-end SRTP master
key to encrypt header extensions as per RFC6904.  The Media
Distributor will not be able use the information contained in those
header extensions encrypted with E2E keys.  See dolist for a related
item in the To Do list.
Paragraph (version B):
If there is a need to encrypt one or more RTP header extensions end-
to-end, an encryption key is derived from the end-to-end SRTP master
key to encrypt header extensions as per RFC6904.  The Media
Distributor will not be able use the information contained in those
header extensions encrypted with E2E keys.
Paragraph (version A):
WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be
used to bind the identity of the user of the endpoint to the
fingerprint of the DTLS-SRTP certificate used for the call.  This
certificate is unique for a given call and a conference.  This allows
the Key Distributor to ensure that only authorized users participate
in the conference.  Similarly the Key Distributor can create a WebRTC
Identity assertion to bind the fingerprint of the unique certificate
used by the Key Distributor for this conference so that the endpoint
can validate it is talking to the correct Key Distributor.
Paragraph (version B):
WebRTC Identity assertion I-D.ietf-rtcweb-security-arch can be used
to bind the identity of the user of the endpoint to the fingerprint
of the DTLS-SRTP certificate used for the call.  This certificate is
unique for a given call and a conference.  This allows the Key
Distributor to ensure that only authorized users participate in the
conference.  Similarly the Key Distributor can create a WebRTC
Identity assertion to bind the fingerprint of the unique certificate
used by the Key Distributor for this conference so that the endpoint
can validate it is talking to the correct Key Distributor.
Paragraph (version B):
The Key Distributor is responsible for knowing what users are allowed
in a given conferences.  When the call setup signalling indicates a
session from a particular endpoint and user wishes to join a
conferences, the Key Distributor will tell the Media Distributor
which conference to place that session in using a globally unique
identifier for the conference that is sent, along with the relevant
keying information, from the Key Distributor to the Media
Distributor.