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

Commentary: This is a first - draft at sections to help clarify key usage and packetization format . 
 Overall this looks like pretty good and I think much of what I do n't like could be fixed simply by deleting two sub sections . 
 Impressive you were able to put " Overall this looks like pretty good " and " much of what I do n't like " into the same sentence . :) OK , I 'll remove the section(s ) with the steps . It gets a bit into the weeds , though it might be useful to figure out how to replace this . The issue is I hear people getting confused over how to use the keys . That 's why I thought that an informative section might help . A library hides all this , but if you 're writing the library , you need to understand these steps . I 'll leave this here until the weekend ( or later this week ) , as I have other stuff to get done . But , I 'll come back to it . 
 I just pushed a set of changes , squashing the changes into a single PR . Otherwise , the changes look to be even larger than they really are since I removed many additions from the first commit . 
 LGTM
Paragraph (version A):
To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys; an "inner" key
(E2E Key(i); i={a given endpoint}) for authenticated encryption of
RTP media between endpoints and an "outer" key (HBH Key(j); j={a
given hop}) for the hop between an endpoint and a Media Distributor
or between Media Distributor.  Reference the following figure.
Paragraph (version A):
The PERC Double draft specification I-D.ietf-perc-double uses
standard SRTP keying material and recommended cryptographic
transform(s) to first form the inner, end-to-end SRTP cryptographic
context.  That end-to-end SRTP cryptographic context MAY be used to
encrypt some RTP header extensions along with RTP media content.  The
output of this is treated like an RTP packet and encrypted again
using the outer hop-by-hop cryptographic context.  The endpoint
executes the entire Double operation while the Media Distributor just
performs the outer, hop-by-hop operation.
Paragraph (version B):
To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys: an "inner" key
(an E2E key distinct for each transmitted media flow) for
authenticated encryption of RTP media between endpoints and an
"outer" key (HBH key) known only to media distributor and the
adjacent endpoint) for the hop between an endpoint and a Media
Distributor or between Media Distributor.  Reference the following
figure.
Paragraph (version A):
To ensure the confidentiality of E2E keys shared between endpoints,
endpoints will make use of a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference.  That KEK,
defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKTKey,
will be used to subsequently encrypt SRTP master keys used for E2E
authenticated encryption (E2E Key(i); i={a given endpoint}) of media
sent by a given endpoint.
Paragraph (version B):
To ensure the confidentiality of E2E keys shared between endpoints,
endpoints will make use of a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference.  That KEK,
defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKT Key,
will be used to subsequently encrypt the SRTP master key used for E2E
authenticated encryption of media sent by a given endpoint.  Each
endpoint in the conference will create a random SRTP master key for
E2E authenticated encryption, thus participants in the conference
MUST keep track of the E2E keys received via the Full EKT Field for
each distinct SSRC in the conference so that it can properly decrypt
received media.  Note, too, that an endpoint may change its E2E key
at any time and advertise that new key to the conference as specified
in I-D.ietf-perc-srtp-ekt-diet.
Paragraph (version A):
Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
and each SSRC's associated E2E Key(i) information.  Following a
change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD
be retained for a period long enough to ensure that late-arriving or
out-of-order packets from other endpoints can be successfully
decrypted.  The endpoint MUST discard the E2E Key(i) and KEK
information no later than when it leaves the conference.
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.
Paragraph (version B):
Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
and each SSRC's associated E2E key information.  Following a change
in an E2E key, prior E2E keys SHOULD be retained by receivers for a
period long enough to ensure that late-arriving or out-of-order
packets from the endpoint can be successfully decrypted.  Receiving
endpoints MUST discard old E2E keys no later than when it leaves the
conference.
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 an E2E key.
Paragraph (version A):
To ensure the integrity of transmitted media packets, this framework
requires that every packet be authenticated hop-by-hop (HBH) between
an endpoint and a Media Distributor, as well between Media
Distributors.  The authentication key used for hop-by-hop
authentication is derived from an SRTP master key shared only on the
respective hop (HBH Key(j); j={a given hop}).  Each HBH Key(j) is
distinct per hop and no two hops ever intentionally use the same SRTP
master key.
Paragraph (version B):
To ensure the integrity of transmitted media packets, this framework
requires that every packet be authenticated hop-by-hop (HBH) between
an endpoint and a Media Distributor, as well between Media
Distributors.  The authentication key used for hop-by-hop
authentication is derived from an SRTP master key shared only on the
respective hop.  Each HBH key is distinct per hop and no two hops
ever intentionally use the same SRTP master key.
Paragraph (version A):
Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media
Distributor to establish HBH keys for transmitting RTP and RTCP
packets to that peer Media Distributor.  The Key Distributor does not
facilitate establishing HBH keys for use between Media Distributors.
Paragraph (version B):
Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media
Distributor to establish the HBH key for transmitting RTP and RTCP
packets to that peer Media Distributor.  The Key Distributor does not
facilitate establishing a HBH key for use between Media Distributors.
Paragraph (version A):
The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls-
tunnel establish one or more TLS tunnels between the Media
Distributor and Key Distributor, making it is possible for the Media
Distributor to facilitate the establishment of a secure DTLS
association between each endpoint and the Key Distributor as shown
the following figure.  The DTLS association between endpoints and the
Key Distributor will enable each endpoint to receive E2E key
information, Key Encryption Key (KEK) information (i.e., EKTKey), and
HBH key information.  At the same time, the Key Distributor can
securely provide the HBH key information to the Media Distributor.
The key information summarized here may include the SRTP master key,
SRTP master salt, and the negotiated cryptographic transform.
Paragraph (version B):
The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls-
tunnel establish one or more TLS tunnels between the Media
Distributor and Key Distributor, making it is possible for the Media
Distributor to facilitate the establishment of a secure DTLS
association between each endpoint and the Key Distributor as shown
the following figure.  The DTLS association between endpoints and the
Key Distributor will enable each endpoint to receive E2E key
information, Key Encryption Key (KEK) information (i.e., EKT Key),
and HBH key information.  At the same time, the Key Distributor can
securely provide the HBH key information to the Media Distributor.
The key information summarized here may include the SRTP master key,
SRTP master salt, and the negotiated cryptographic transform.
Paragraph (version A):
Following the initial key information exchange with the Key
Distributor, endpoints will be able to encrypt media end-to-end with
their E2E Key(i), sending that E2E Key(i) to other endpoints
encrypted with KEK, and will be able to encrypt and authenticate RTP
packets using local HBH Key(j).  The procedures defined do not allow
the Media Distributor to gain access to the KEK information,
preventing it from gaining access to any endpoint's E2E key and
subsequently decrypting media.
Paragraph (version A):
The KEK (i.e., EKTKey) may need to change from time-to-time during
the life of a conference, such as when a new participant joins or
leaves a conference.  Dictating if, when or how often a conference is
to be re-keyed is outside the scope of this document, but this
framework does accommodate re-keying during the life of a conference.
Paragraph (version B):
Following the initial key information exchange with the Key
Distributor, an endpoints will be able to encrypt media end-to-end
with an E2E key, sending that E2E key to other endpoints encrypted
with the KEK, and will be able to encrypt and authenticate RTP
packets using a HBH key.  The procedures defined do not allow the
Media Distributor to gain access to the KEK information, preventing
it from gaining access to any endpoint's E2E key and subsequently
decrypting media.
Paragraph (version B):
The KEK (i.e., EKT Key) may need to change from time-to-time during
the life of a conference, such as when a new participant joins or
leaves a conference.  Dictating if, when or how often a conference is
to be re-keyed is outside the scope of this document, but this
framework does accommodate re-keying during the life of a conference.