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

Commentary: This looks good to me 
 Minor nits “ hadnshake ” — “ handshake ” “ Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints . ” — from other endpoints .
Paragraph (version A):
An endpoint's ability to join a conference hosted by a Media
Distributor MUST NOT alone be interpreted as being authorized to have
access to the E2E media encryption keys, as the Media Distributor
does not have the ability to determine whether an endpoint is
authorized.  Trusted endpoint authorization is described in I-
D.roach-perc-webrtc.
Paragraph (version B):
An endpoint's ability to join a conference hosted by a Media
Distributor MUST NOT alone be interpreted as being authorized to have
access to the E2E media encryption keys, as the Media Distributor
does not have the ability to determine whether an endpoint is
authorized.  Instead, the Key Distributor is responsible for
authenticating endpoints (e.g., using WebRTC Identity I-D.ietf-
rtcweb-security-arch) and determining their authorization to receive
E2E media encryption keys.
Paragraph (version A):
The Key Distributor, which may be collocated with an endpoint or
exist standalone, is responsible for providing key information to
endpoints for both end-to-end and hop-by-hop security and for
providing key information to Media Distributors for the hop-by-hop
security.
Paragraph (version B):
The Key Distributor, which may be colocated with an endpoint or exist
standalone, is responsible for providing key information to endpoints
for both end-to-end and hop-by-hop security and for providing key
information to Media Distributors for the hop-by-hop security.
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
(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 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.
Paragraph (version B):
The PERC Double transform I-D.ietf-perc-double enables endpoints to
perform encryption using both the E2E and HBH contexts while still
preserving the same overall interface as other SRTP transforms.  The
Media Distributor simply uses the corresponding normal (single) AES-
GCM transform, keyed with the appropriate HBH keys.  See keyinventory
for a description of the keys used in PERC and packetformat for an
overview of how the packet appears on the wire.
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.  Each HBH key 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 use the same SRTP master key.
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 generate E2E and HBH
keys and receive the Key Encryption Key (KEK) (i.e., EKT Key).  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 Media Distributor maintains a tunnel with the Key Distrubutor
(e.g., using I-D.ietf-perc-dtls-tunnel), making it 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 generate E2E and HBH
keys and receive the Key Encryption Key (KEK) (i.e., EKT Key).  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):
In establishing the DTLS association between endpoints and the Key
Distributor, the endpoint acts as the DTLS client and the Key
Distributor acts as the DTLS server.  The Key Encryption Key (KEK)
(i.e., EKT Key) is conveyed by the Key Distributor over the DTLS
association to endpoints via procedures defined in PERC EKT I-D.ietf-
perc-srtp-ekt-diet via the EKTKey message.
Paragraph (version A):
Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double
cipher, the endpoint will generate both E2E and HBH encryption keys
and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key
or MAY generate different E2E keys.  In either case, the generated
SRTP master salt for E2E encryption MUST be replaced with the salt
value provided by the Key Distributor via the EKTKey message.  That
is because every endpoint in the conference uses the same SRTP master
salt.  The endpoint only transmits the SRTP master key (not the salt)
used for E2E encryption to other endpoints in RTP/RTCP packets per I-
D.ietf-perc-srtp-ekt-diet.
Paragraph (version B):
In establishing the DTLS association between endpoints and the Key
Distributor, the endpoint MUST act as the DTLS client and the Key
Distributor MUST act as the DTLS server.  The Key Encryption Key
(KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the
DTLS association to endpoints via procedures defined in PERC EKT I-
D.ietf-perc-srtp-ekt-diet via the EKTKey message.
Paragraph (version B):
Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double
cipher, the endpoint will generate both E2E and HBH encryption keys
and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key
for transmission or MAY generate a fresh E2E key.  In either case,
the generated SRTP master salt for E2E encryption MUST be replaced
with the salt value provided by the Key Distributor via the EKTKey
message.  That is because every endpoint in the conference uses the
same SRTP master salt.  The endpoint only transmits the SRTP master
key (not the salt) used for E2E encryption to other endpoints in RTP/
RTCP packets per I-D.ietf-perc-srtp-ekt-diet.
Paragraph (version A):
It is important to this solution framework that the entities can
trust and validate the authenticity of other entities, especially the
Key Distributor and endpoints.  The details of this are outside the
scope of specification but a few possibilities are discussed in the
following sections.  The key requirements is that endpoints can
verify they are connected to the correct Key Distributor for the
conference and the Key Distributor can verify the endpoints are the
correct endpoints for the conference.
Paragraph (version B):
It is important to this solution framework that the entities can
validate the authenticity of other entities, especially the Key
Distributor and endpoints.  The details of this are outside the scope
of specification but a few possibilities are discussed in the
following sections.  The key requirements is that endpoints can
verify they are connected to the correct Key Distributor for the
conference and the Key Distributor can verify the endpoints are the
correct endpoints for the conference.