option has been added to optimize signaling overhead in case the
Initiator knows some key (e.g., a public key) that the Responder has,
but is unsure of what protocol the Responder supports. The mechanism
is not intended to negotiate options within one and the same
protocol.
The offerer MUST include the key management data within an offer that
contains the media description it applies to.
Re-keying MUST be handled as a new offer, with the new proposed
parameters. The answerer treats this as a new offer where the key
management is the issue of change. The re-keying exchange MUST be
finalized before the security protocol can change the keys. The same
key management protocol used in the original offer SHALL also be used
in the new offer carrying re-keying. If the new offer carrying re-
keying fails (e.g., the authentication verification fails), the
answerer SHOULD send a "488 Not Acceptable Here" message, including
one or more Warning headers (at least a 306). The offerer MUST then
abort the session.
Note that, in multicast scenarios, unlike unicast, there is only a
single view of the stream [OAM], hence there MUST be a uniform
agreement of the security parameters.
After the offer is issued, the offerer SHOULD be prepared to receive
media, as the media may arrive prior to the answer. However, this
brings issues, as the offerer does not know yet the answerer’s choice
in terms of, e.g., algorithms, or possibly the key is known. This
can cause delay or clipping can occur; if this is unacceptable, the
offerer SHOULD use mechanisms outside the scope of this document,
e.g., the security preconditions for SIP [SPREC].
4.1.3. Use of SDP with SAP
There are cases where SDP is used without conforming to the
offer/answer model; instead, it is a one-way SDP distribution (i.e.,
without back channel), such as when used with SAP and HTTP.
The processing follows the two first steps of the general SDP
processing (see Section 4.1.1). It can be noted that the processing
in this case differs from the offer/answer case in that only one key
management protocol SHALL be offered (i.e., no negotiation will be
possible). This implies that the bidding-down attack is not an
issue; therefore, the countermeasure is not needed. The key
management protocol used MUST support one-way messages.
4.1.4. Bidding-Down Attack Prevention
The possibility to support multiple key management protocols may,
unless properly handled, introduce bidding-down attacks.
Specifically, a man-in-the-middle could "peel off" cryptographically
strong offers (deleting the key management lines from the message),
leaving only weaker ones as the Responder’s choice. To avoid this,
the list of identifiers of the proposed key management protocols MUST
be authenticated. The authentication MUST be done separately by each
key management protocol.
Accordingly, it MUST be specified (in the key management protocol
specification itself or in a companion document) how the list of key
management protocol identifiers can be processed to be authenticated
from the offerer to the answerer by the specific key management
protocol. Note that even if only one key management protocol is
used, that still MUST authenticate its own protocol identifier.
The list of protocol identifiers MUST then be given to each of the
selected (offered) key management protocols by the application with
";" separated identifiers. All the offered protocol identifiers MUST
be included, in the same order as they appear in the corresponding
SDP description.
The protocol list can formally be described as
prtcl-list = KMPID *(";" KMPID)
where KMPID is as defined in Section 3.
For example, if the offered protocols are MIKEY and two yet-to-be-
invented protocols KEYP1, KEYP2, the SDP is:
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD...
a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD...
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000
The protocol list, "mikey;keyp1;keyp2", would be generated from the
SDP description and used as input to each specified key management
protocol (together with the data for that protocol). Each of the
three protocols includes this protocol identifier list in its
authentication coverage (according to its protocol specification).
If more than one protocol is supported by the offerer, it is
RECOMMENDED that all acceptable protocols are included in the first
offer, rather than making single, subsequent alternative offers in
response to error messages; see "Security Considerations".
End-to-end integrity protection of the key-mgmt attributes
altogether, provided externally to the key management itself, also
protects against this bidding-down attack. This is, for example, the
case if SIP uses S/MIME [RFC3851] to end-to-end integrity protect the
SDP description. However, as this end-to-end protection is not an
assumption of the framework, the mechanisms defined in this section
SHALL be applied.
4.2. RTSP Usage
RTSP does not use the offer/answer model, as SIP does. This causes
some problems, as it is not possible (without modifying RTSP) to send
back an answer. To solve this, a new header has been introduced
(Section 3.2). This also assumes that the key management also has
some kind of binding to the media, so that the response to the server
will be processed as required.
The server SHALL be the Initiator of the key management exchange for
sessions in PLAY mode, i.e., transporting media from server to
client. The below text describes the behavior for PLAY mode. For
any other mode, the behavior is not defined in this specification.
To obtain a session description, the client initially contacts the
server via a DESCRIBE message. The initial key management message
from the RTSP server is sent to the client in the SDP of the 200 OK
in response to the DESCRIBE. Note that only one key management
protocol SHALL be used per session/media level. A server MAY allow
the SDP with key management attribute(s) to be distributed to the
client through other means than RTSP, although this is not specified
here.
The "uri" parameter of the KeyMgmt header is used to indicate for the
key management protocol on what context the carried message applies.
For key management messages on the SDP session level, the answer MUST
contain the RTSP aggregated control URL to indicate this. For key
management messages initially on SDP media level, the key management
response message in the KeyMgmt header MAY use the RTSP media-level
URL. For RTSP sessions not using aggregated control, i.e., no
session-level control URI is defined, the key management protocol
SHALL only be invoked on individual media streams. In this case
also, the key management response SHALL be on individual media
streams (i.e., one RTSP key management header per media).
When responding to the initial key management message, the client
uses the new RTSP header (KeyMgmt) to send back an answer. How this
is done depends on the usage context:
* Key management protocol responses for the initial establishment of
security parameters for an aggregated RTSP session SHALL be sent in
the first SETUP of the session. This means that if the key
management is declared for the whole session but is set up in non-
aggregated fashion (i.e., one media per RTSP session), each SETUP
MUST carry the same response for the session-level context. When
performing a setup of the second or any subsequent media in an RTSP
session, the same key management parameters as established for the
first media also apply to these setups.
* Key management responses for the initial establishment of security
parameters for an individual media SHALL only be included in SETUP
for the corresponding media stream.
If a server receives a SETUP message in which it expects a key
management message, but none is included, a "403 Forbidden" SHOULD be
returned to the client, whereby the current setup MUST be aborted.
When the server creates an initial SDP message, the procedure SHALL
be the same as described in Section 4.1.1.
The client processing of the initial SDP message from the server
SHALL follow the same procedures as described in Section 4.1.1,
except that, if there is an error, the session is aborted (no error
is sent back).
The client SHALL create the response, using the key management header
in RTSP, as follows:
* The identifier of the key management protocol used (e.g., MIKEY)
MUST be placed in the "prot" field of the header. The prot values
are maintained by IANA (Section 9).
* The keymgmt-data field MUST be created as follows: the key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded by the RTSP
application and then encapsulated in the "data" field of the
header. The semantics of the encapsulated message is dependent on
the key management protocol that is used.
* Include, if necessary, the URL to indicate the context in the "uri"
parameter.
The server SHALL process a received key management header in RTSP as
follows:
* The key management protocol is identified according to the "prot"
field.
* The key management data from the "data" field MUST be extracted,
base64 decoded to reconstruct the original message, and then passed
to the key management protocol for processing.
* If the key management protocol is successful, the processing can
proceed according to normal rules.
* Otherwise, if the key management fails (e.g., due to authentication
failure or parameter not supported), an error is sent back as the
SETUP response using RTSP error code 463 (see Section 3.2) and the
session is aborted. It is up to the key management protocol to
specify (within the RTSP status code message or through key
management messages) details about the type of error that occurred.
Re-keying within RTSP is for further study, given that media updating
mechanisms within RTSP are unspecified at the time this document was
written.
5. Example Scenarios
The following examples utilize MIKEY [MIKEY] as the key management
protocol to be integrated into SDP and RTSP.
5.1. Example 1 (SIP/SDP)
A SIP call is taking place between Alice and Bob. Alice sends an
INVITE message consisting of the following offer:
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2
UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt
0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
That is, Alice proposes to set up one audio stream and one video
stream that run over SRTP (signaled by the use of the SAVP profile).
She uses MIKEY to set up the security parameters for SRTP (Section
7). The MIKEY message contains the security parameters, together
with the necessary key material. Note that MIKEY is exchanging the
crypto suite for both streams, as it is placed at the session level.
Also, MIKEY provides its own security, i.e., when Bob processes
Alice’s MIKEY message, he will also find the signaling of the
security parameters used to secure the MIKEY exchange. Alice’s
endpoint’s authentication information is also carried within the
MIKEY message, to prove that the message is authentic. The above
MIKEY message is an example of message when the pre-shared method
MIKEY is used.
Upon receiving the offer, Bob checks the validity of the received
MIKEY message, and, in case of successful verification, he accepts
the offer and sends an answer back to Alice (with his authentication
information, and, if necessary, also some key material from his
side):
v=0
o=bob 2891092897 2891092897 IN IP4 foo.example.com
s=Cool stuff
e=bob@foo.example.com
t=0 0
c=IN IP4 foo.example.com
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2
V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
Upon receiving the answer, Alice verifies the correctness of it. In
case of success, at this point Alice and Bob share the security
parameters and the keys needed for a secure RTP communication.
5.2. Example 2 (SDP)
This example shows what Alice would have done if she wished to
protect only the audio stream. She would have placed the MIKEY line
at media level for the audio stream only (also specifying the use of
the SRTP profile there, SAVP). The semantics of the MIKEY messages
is as in the previous case, but applies only to the audio stream.
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=video 52230 RTP/AVP 31
a=rtpmap:31 H261/90000
Bob would then act as described in the previous example, including
the MIKEY answer at the media level for the audio stream (as Alice
did).
Note that even if the key management attribute were specified at the
session level, the video part would not be affected by this (as a
security profile is not used, instead the RTP/AVP profile is
signaled).
5.3. Example 3 (RTSP)
A client wants to set up a streaming session and requests a media
description from the streaming server.
DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp
From: user@example.com
The server sends back an OK message including an SDP description,
together with the MIKEY message. The MIKEY message contains the
necessary security parameters that the server is willing to offer to
the client, together with authentication information (to prove that
the message is authentic) and the key material. The SAVP profile
also signals the use of SRTP for securing the media sessions.
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 478
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=control:rtsp://movie.example.com/action/video
The client checks the validity of the received MIKEY message, and, in
case of successful verification, it accept the message. The client
then includes its key management data in the SETUP request going back
to the server, the client authentication information (to prove that
the message is authentic), and, if necessary, some key material.
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."
The server processes the request including checking the validity of
the key management header.
RTSP/1.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
Note that in this case the key management line was specified at the
session level, and the key management information only goes into the
SETUP related to the first stream. The "uri" indicates to the server
that the context is for the whole aggregated session the key
management applies. The RTSP client then proceeds setting up the
second media (video) in aggregation with the audio. As the two media
are run in aggregation and the key context was established in the
first exchange, no more key management messages are needed.
5.4. Example 4 (RTSP)
The use of the MIKEY message at the media level would change the
previous example as follows.
The 200 OK would contain the two distinct SDP attributes for MIKEY at
the media level:
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 561
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/video
Each RTSP header is inserted in the SETUP related to the audio and
video separately:
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
data="AQEFgM0XflABAAAAAAAAAAAAA..."
and similarly for the video session:
SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
Note: The "uri" parameter could be excluded from the two SETUP
messages in this example.
6. Adding Further Key Management Protocols
This framework cannot be used with all key management protocols. The
key management protocol needs to comply with the requirements
described in Section 4. In addition to this, the following needs to
be defined:
* The key management protocol identifier to be used as the protocol
identifier should be registered at IANA according to Section 9.
* The information that the key management needs from SDP and RTSP,
and vice versa, as described in Section 4. The exact API is
implementation specific, but it MUST at least support the exchange
of the specified information.
* The key management protocol to be added MUST be such that the
processing in Section 4 (describing its interactions with SDP and
RTSP) can be applied. Note in particular, Section 4.1.4 requires
each key management protocol to specify how the list of protocol
identifiers is authenticated inside that key management protocol.
The key management MUST always be given the protocol identifier(s)
of the key management protocol(s) included in the offer in the
correct order as they appear.
Finally, it is obviously crucial to analyze possible security
implications induced by the introduction of a new key management
protocol in the described framework.
Today, the MIKEY protocol [MIKEY] has adopted the key management
extensions to work together with SIP and RTSP (see Section 7). Other
protocols MAY use the described attribute and header, e.g., Kerberos
[KERB]; however, this is subject to future standardization.
7. Integration of MIKEY
[MIKEY] describes a key management protocol for real-time
applications (both for peer-to-peer communication and group
communication). MIKEY carries the security parameters needed for
setting up the security protocol (e.g., SRTP) protecting the media
stream. MIKEY can be integrated within SDP and RTSP, following the
rules and guidelines described in this document.
MIKEY satisfies the requirements described in Section 4. The MIKEY
message is formed as defined in [MIKEY], then passed from MIKEY to
the SDP application that base64 encodes it, and encapsulates it in
the keymgmt-data attribute. The examples in Section 5 use MIKEY,
where the semantics of the exchange is also briefly explained.
The key management protocol identifier (KMPID) to be used as the
protocol identifier SHALL be "mikey" and is registered at IANA; see
Section 9 for details.
The information that the key management needs from SDP and RTSP, and
vice versa, follows Section 4. To avoid bidding-down attacks, the
directives in Section 4.1.4 are followed. The list of protocol
identifiers is authenticated within MIKEY by placing the list in a
General Extension Payload (of type "SDP IDs", [MIKEY]), which then
automatically will be integrity protected/signed. The receiver SHALL
then match the list in the General Extension Payload with the list
included in SDP and SHOULD (according to policy) if they differ, or
if integrity/signature verification fails, reject the offer.
The server will need to be able to know the identity of the client
before creating and sending a MIKEY message. To signal the (MIKEY)
identity of the client to the server in the DESCRIBE, it is
RECOMMENDED to include the From header field in RTSP. Other methods
to establish the identity could be using the IP address or retrieving
the identity from the RTSP authentication if used.
7.1. MIKEY Interface
This subsection describes some aspects, which implementers SHOULD
consider. If the MIKEY implementation is separate from the
SDP/SIP/RTSP, an application programming interface (API) between
MIKEY and those protocols is needed with certain functionality
(however, exactly what it looks like is implementation dependent).
The following aspects need to be considered:
* the possibility for MIKEY to receive information about the sessions
negotiated. This is to some extent implementation dependent. But
it is RECOMMENDED that, in the case of SRTP streams, the number of
SRTP streams is included (and the direction of these). It is also
RECOMMENDED to provide the destination addresses and ports to
MIKEY. When referring to streams described in SDP, MIKEY SHALL
allocate two consecutive numbers for the related Crypto Session
indexes (as each stream can be bi-directional). An example: if the
SDP contains two m lines (specifying whatever direction of the
streams), and MIKEY is at the session level, then MIKEY allocates,
e.g., the Crypto Sessions Identifiers (CS IDs; see [MIKEY]) ’1’ and
’2’ for the first m line, and ’3’ and ’4’ for the second m line.
* the possibility for MIKEY to receive incoming MIKEY messages and
return a status code from/to the SIP/RTSP application.
* the possibility for the SIP or RTSP applications to receive
information from MIKEY. This would typically include the receiving
of the Crypto Session Bundle Identifier (CSB ID; see [MIKEY], to
later be able to identify the active MIKEY session), and the SSRCs
and the rollover counter (ROC; see [SRTP]) for SRTP usage. It is
also RECOMMENDED that extra information about errors can be
received.
* the possibility for the SIP or RTSP application to receive outgoing
MIKEY messages.
* the possibility to tear down a MIKEY CSB (e.g., if the SIP session
is closed, the CSB SHOULD also be closed).
8. Security Considerations
The framework for transfer of key management data as described here
is intended to provide the security parameters for the end-to-end
protection of the media session. It is furthermore good practice to
secure the session setup (e.g., SDP, SIP, RTSP, SAP). However, it
might be that the security of the session setup is not possible to
achieve end-to-end, but only hop-by-hop. For example, SIP requires
intermediate proxies to have access to part of the SIP message, and
sometimes also to the SDP description (cf. [E2M]), although end-to-
end confidentiality can hide bodies from intermediaries. General
security considerations for the session setup can be found in SDP
[SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this
memo is useful when the session setup is not protected in an end-to-
end fashion, but the media streams need to be end-to-end protected;
hence the security parameters (such as keys) are not wanted revealed
to or manipulated by intermediaries.
The security will also depend on the level of security the key
management protocol offers. It follows that, under the assumption
that the key management schemes are secure, the SDP can be passed
along unencrypted without affecting the key management as such, and