draft-ietf-mmusic-kmgmt-ext-11.txt   draft-ietf-mmusic-kmgmt-ext-12.txt 
Internet Engineering Task Force J. Arkko Internet Engineering Task Force J. Arkko
MMUSIC Working Group E. Carrara MMUSIC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm INTERNET-DRAFT F. Lindholm
Expires: October 2004 M. Naslund Expires: April 2005 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
April 2004 November 2004
Key Management Extensions for Session Description Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) Protocol (SDP) and Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-kmgmt-ext-11.txt> <draft-ietf-mmusic-kmgmt-ext-12.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, I accept the provisions of Section
3 of RFC 3667 (BCP 78). 3 of RFC 3667 (BCP 78).
skipping to change at page 2, line 20 skipping to change at page 2, line 20
be used by one or more key management protocols. As such, their use be used by one or more key management protocols. As such, their use
is meaningful only when complemented by an appropriate key management is meaningful only when complemented by an appropriate key management
protocol. protocol.
General guidelines are also given on how the framework should be used General guidelines are also given on how the framework should be used
together with SIP and RTSP. The usage with the MIKEY key management together with SIP and RTSP. The usage with the MIKEY key management
protocol is also defined. protocol is also defined.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.....................................................2 1. Introduction.....................................................3
1.1. Notational Conventions.........................................4 1.1. Notational Conventions.........................................4
2. Extensions to SDP and RTSP.......................................4 2. Extensions to SDP and RTSP.......................................4
2.1. SDP Extensions.................................................4 2.1. SDP Extensions.................................................5
2.2. RTSP Extensions................................................5 2.2. RTSP Extensions................................................5
3. Usage with SDP, SIP, RTSP, and SAP...............................6 3. Usage with SDP, SIP, RTSP, and SAP...............................6
3.1. Use of SDP.....................................................7 3.1. Use of SDP.....................................................7
3.1.1 General processing............................................7 3.1.1 General processing............................................7
3.1.2 Use of SDP with offer/answer and SIP..........................9 3.1.2 Use of SDP with offer/answer and SIP..........................9
3.1.3 Use of SDP with SAP..........................................10 3.1.3 Use of SDP with SAP..........................................11
3.1.4 Bidding-down attack prevention...............................11 3.1.4 Bidding-down attack prevention...............................11
3.2. RTSP usage....................................................12 3.2. RTSP usage....................................................13
4. Example scenarios...............................................14 4. Example scenarios...............................................15
5. Adding further Key management protocols.........................18 5. Adding further Key management protocols.........................19
6. Integration of MIKEY............................................19 6. Integration of MIKEY............................................20
6.1 MIKEY Interface................................................19 6.1 MIKEY Interface................................................20
7. Security Considerations.........................................20 7. Security Considerations.........................................21
8. IANA Considerations.............................................21 8. IANA Considerations.............................................23
8.1. SDP Attribute Registration....................................21 8.1. SDP Attribute Registration....................................23
8.2. RTSP Registration.............................................22 8.2. RTSP Registration.............................................23
8.3. Protocol Identifier Registration..............................22 8.3. Protocol Identifier Registration..............................23
9. Acknowledgments.................................................23 9. Acknowledgments.................................................24
10. Author's Addresses.............................................23 10. Author's Addresses.............................................25
11. References.....................................................24 11. References.....................................................25
11.1. Normative References.........................................24 11.1. Normative References.........................................25
11.2. Informative References.......................................24 11.2. Informative References.......................................26
1. Introduction 1. Introduction
[RFC Editor remark] All instances of RFC xxxx should be replaced [RFC Editor remark] All instances of RFC xxxx should be replaced
with the RFC number of this document, when published. Furthermore, with the RFC number of this document, when published.
all instances of RFC yyyy should be replaced with the RFC number
of the MIKEY (Multimedia Internet KEYing) document [MIKEY], when
published.
There has recently been work to define a security profile for the There has recently been work to define a security profile for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys and security parameters, manage and refresh keys, etc. exchange keys and security parameters, manage and refresh keys, etc.
A key management protocol is executed prior to the security A key management protocol is executed prior to the security
protocol's execution. The key management protocol's main goal is to, protocol's execution. The key management protocol's main goal is to,
in a secure and reliable way, establish a security association for in a secure and reliable way, establish a security association for
the security protocol. This includes one or more cryptographic keys the security protocol. This includes one or more cryptographic keys
skipping to change at page 3, line 54 skipping to change at page 4, line 5
to the actual setup of the media session. to the actual setup of the media session.
* The possibility to negotiate keying material end-to-end without * The possibility to negotiate keying material end-to-end without
applying end-to-end protection of the SDP (instead, hop-by-hop applying end-to-end protection of the SDP (instead, hop-by-hop
security mechanisms can be used which may be useful if security mechanisms can be used which may be useful if
intermediate proxies needs access to the SDP). intermediate proxies needs access to the SDP).
Currently in SDP [SDPnew], there exists one field to transport keys, Currently in SDP [SDPnew], there exists one field to transport keys,
the "k=" field. However, this is not enough for a key management the "k=" field. However, this is not enough for a key management
protocol as there are many more parameters that need to be protocol as there are many more parameters that need to be
transported, and the "k=" field is not extendible. The approach used transported, and the "k=" field is not extensible. The approach used
is to extend the SDP description through a number of attributes that is to extend the SDP description through a number of attributes that
transport the key management offer/answer and also to associate it transport the key management offer/answer and also to associate it
with the media sessions. SIP uses the offer/answer model [OAM] with the media sessions. SIP uses the offer/answer model [OAM]
whereby extensions to SDP will be enough. However, RTSP [RTSP] does whereby extensions to SDP will be enough. However, RTSP [RTSP] does
not use the offer/answer model with SDP, so a new RTSP header is not use the offer/answer model with SDP, so a new RTSP header is
introduced to convey key management data. introduced to convey key management data.
The document also defines the use of the described framework together The document also defines the use of the described framework together
with the key management protocol Multimedia Internet KEYing (MIKEY) with the key management protocol Multimedia Internet KEYing (MIKEY)
[MIKEY]. [MIKEY].
skipping to change at page 5, line 7 skipping to change at page 5, line 15
2.1. SDP Extensions 2.1. SDP Extensions
This section provides an ABNF grammar (as used in [SDPnew]) for the This section provides an ABNF grammar (as used in [SDPnew]) for the
key management extensions to SDP. key management extensions to SDP.
Note that the new definitions are compliant with the definition of an Note that the new definitions are compliant with the definition of an
attribute field, i.e. attribute field, i.e.
attribute = (att-field ":" att-value) | att-field attribute = (att-field ":" att-value) | att-field
The att-field and att-value for the key management extensions are as The ABNF for the key management extensions (conforming to the att-
follow: field and att-value) are as follow:
key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
key-mgmt-att-field = "key-mgmt" key-mgmt-att-field = "key-mgmt"
key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
prtcl-id = KMID prtcl-id = KMID
; e.g. "mikey" ; e.g. "mikey"
keymgmt-data = base64 keymgmt-data = base64
SP = 0x20 SP = 0x20
where KMID is as defined in Section 2 of this memo, base64 is as where KMID is as defined in Section 2 of this memo, base64 is as
defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined
for KMID in Section 8. for KMID in Section 8.
The attribute MAY be used at session level, media level, or at both The attribute MAY be used at session level, media level, or at both
levels. An attribute defined at media level overrides an attribute levels. An attribute defined at media level overrides an attribute
defined at session level. In other words, if the media level defined at session level. In other words, if the media level
attribute is present, the session level attribute MUST be ignored for attribute is present, the session level attribute MUST be ignored for
this media. Section 3.1 describes in detail how the attributes are this media. Section 3.1 describes in detail how the attributes are
used and how the SDP is handled in different usage scenarios. used and how the SDP is handled in different usage scenarios. The
choice of the level depends for example on the particular key
management protocol. Some protocols may not be able to derive enough
key material for all the sessions; furthermore, possibly a different
protection to each session could be required. The particular protocol
might achieve this only by specifying it at the media level. Other
protocols, such as MIKEY, have instead those capabilities (as it can
express multiple security policies and derive multiple keys), so it
may use the session level.
2.2. RTSP Extensions 2.2. RTSP Extensions
To support the key management attributes, the following RTSP header To support the key management attributes, the following RTSP header
is defined: is defined:
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
key-mgmt-spec = "prot" "=" KMID ";" ["uri" "=" <"> rtsp_URL <"> ";"] key-mgmt-spec = "prot" "=" KMID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
"data" "=" base64 "data" "=" base64
where KMID is as defined in Section 2 of this memo, "base64" as where KMID is as defined in Section 2 of this memo, "base64" as
defined in [SDPnew], and "rtsp_URL" as defined in [RTSP]. defined in [SDPnew], and "rtsp_URL" as defined in [RTSP].
The "uri" parameter identifies the context for which the key The "uri" parameter identifies the context for which the key
management data applies, and the RTSP URI SHALL match a (session or management data applies, and the RTSP URI SHALL match a (session or
media) URI present in the description of the session. If the RTSP media) URI present in the description of the session. If the RTSP
aggregated control URI is included it indicates that the key aggregated control URI is included it indicates that the key
skipping to change at page 7, line 7 skipping to change at page 7, line 27
(to assure that the message is authentic). (to assure that the message is authentic).
At the Responder's side, the key management protocol checks the At the Responder's side, the key management protocol checks the
validity of the key management message, together with the validity of the key management message, together with the
availability of the parameters offered, and then provides the key availability of the parameters offered, and then provides the key
management data to be included in the answer. This answer may management data to be included in the answer. This answer may
typically authenticate the Responder to the Initiator, and also state typically authenticate the Responder to the Initiator, and also state
if the initial offer was accepted or not. Certain protocols might if the initial offer was accepted or not. Certain protocols might
require the Responder to include a selection of the security require the Responder to include a selection of the security
parameters that he is willing to support. Again, the actual content parameters that he is willing to support. Again, the actual content
of such response is dependent on the particular key management of such responses is dependent on the particular key management
protocol. protocol.
Section 6 describes a realization of the MIKEY protocol using these Section 6 describes a realization of the MIKEY protocol using these
mechanisms. Procedures to be used when mapping new key management mechanisms. Procedures to be used when mapping new key management
protocols onto this framework are described in Section 5. protocols onto this framework are described in Section 5.
3.1. Use of SDP 3.1. Use of SDP
This section describes the processing rules for the different This section describes the processing rules for the different
applications which use SDP for the key management. applications which use SDP for the key management.
skipping to change at page 9, line 32 skipping to change at page 9, line 53
* Before, or in conjunction with, passing the key management data to * Before, or in conjunction with, passing the key management data to
the key management protocol, the complete list of protocol the key management protocol, the complete list of protocol
identifier from the offer message is provided by the SDP identifier from the offer message is provided by the SDP
application to the key management protocol (as defined in Section application to the key management protocol (as defined in Section
3.1.4). 3.1.4).
When an answer is created, the following offer-answer specific When an answer is created, the following offer-answer specific
procedure SHALL be applied: procedure SHALL be applied:
* If the key management rejects the offer, the answerer SHOULD return * If the key management rejects the offer, the answerer SHOULD return
a "606 Not Acceptable" message, optionally also including one or a "488 Not Acceptable Here" message, optionally also including one
more Warning headers (a 306 "Attribute not understood" when one of or more Warning headers (a 306 "Attribute not understood" when one
the parameters is not supported, and a 399 "Miscellaneous warning" of the parameters is not supported, and a 399 "Miscellaneous
with arbitrary information to be presented to a human user or warning" with arbitrary information to be presented to a human
logged, see Section 20.43 in [SIP]). Further details about the user or logged, see Section 20.43 in [SIP]). Further details about
cause of failure MAY be described in an included message from the the cause of failure MAY be described in an included message from
key management protocol. The session is then aborted (and it is up the key management protocol. The session is then aborted (and it
to local policy or end user to decide how to continue). is up to local policy or end user to decide how to continue).
Note that the key management attribute (related to the same key Note that the key management attribute (related to the same key
management protocol) MAY be present both at session level and at management protocol) MAY be present both at session level and at
media level. Consequently, the process SHALL be repeated for each media level. Consequently, the process SHALL be repeated for each
such key management attribute detected. In case the key management such key management attribute detected. In case the key management
processing of any such attribute does not succeed (e.g. processing of any such attribute does not succeed (e.g.
authentication failure, parameters not supported etc.), on either authentication failure, parameters not supported etc.), on either
session or media level, the entire session setup SHALL be aborted, session or media level, the entire session setup SHALL be aborted,
including those parts of the session which successfully completed including those parts of the session that successfully completed
their part of the key management. their part of the key management.
If more than one key management protocol is supported, multiple If more than one key management protocol is supported, multiple
instances of the key management attribute MAY be included in the instances of the key management attribute MAY be included in the
initial offer when using the offer-answer model, each transporting a initial offer when using the offer-answer model, each transporting a
different key management protocol, thus indicating supported different key management protocol, thus indicating supported
alternatives. alternatives.
If the offerer includes more than one key management protocol If the offerer includes more than one key management protocol
attribute at session level (analogous for the media level), these attribute at session level (analogous for the media level), these
SHOULD be listed in order of preference (the first being the SHOULD be listed in order of preference (the first being the
preferred). The answerer selects the key management protocol it preferred). The answerer selects the key management protocol it
wishes to use, and processes only it, on either session or media wishes to use, and processes only it, on either session or media
level, or on both, according to where located. If the answerer does level, or on both, according to where located. If the answerer does
not support any of the offerer's suggested key management protocols, not support any of the offerer's suggested key management protocols,
the receiver returns a "606 Not Acceptable" error message, whereby the receiver returns a "488 Not Acceptable Here" error message,
the sender MUST abort the current setup procedure. whereby the sender MUST abort the current setup procedure.
Note that the placement of multiple key management offers in a single Note that the placement of multiple key management offers in a single
message has the disadvantage that the message expands and the message has the disadvantage that the message expands and the
computational workload for the offerer will increase drastically. computational workload for the offerer will increase drastically.
Unless the guidelines of Section 3.1.4 are followed, multiple lines Unless the guidelines of Section 3.1.4 are followed, multiple lines
may open up bidding-down attacks. may open up bidding-down attacks. Note also that the multiple offer
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 The offerer MUST include the key management data within an offer that
contains the media description it applies to. contains the media description it applies to.
Re-keying MUST be handled as a new offer, with the new proposed 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 parameters. The answerer treats this as a new offer where the key
management is the issue of change. The re-keying exchange MUST be management is the issue of change. The re-keying exchange MUST be
finalized before the security protocol can change the keys. The same finalized before the security protocol can change the keys. The same
key management protocol used in the original offer SHALL also be used 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- in the new offer carrying re-keying. If the new offer carrying re-
keying fails (e.g., the authentication verification fails), the keying fails (e.g., the authentication verification fails), the
answerer SHOULD send a "606 Not Acceptable" message, including one or answerer SHOULD send a "488 Not Acceptable Here" message, including
more Warning headers (at least a 306). The offerer MUST then abort one or more Warning headers (at least a 306). The offerer MUST then
the session. abort the session.
Note that, in multicast scenarios, unlike unicast, there is only a Note that, in multicast scenarios, unlike unicast, there is only a
single view of the stream [OAM], hence there MUST be a uniform single view of the stream [OAM], hence there MUST be a uniform
agreement of the security parameters. 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 offer does not know yet the answererĘs choice
in terms of e.g. algorithms, nor possibly the key is know. 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 precondition for SIP [SPREC].
3.1.3 Use of SDP with SAP 3.1.3 Use of SDP with SAP
There are cases where SDP is used without conforming to the There are cases where SDP is used without conforming to the
offer/answer model; instead it is a one-way SDP distribution (i.e. offer/answer model; instead it is a one-way SDP distribution (i.e.
without back channel), such as when used with SAP and HTTP. without back channel), such as when used with SAP and HTTP.
The processing follows the two first steps of the general SDP The processing follows the two first steps of the general SDP
processing (see Section 3.1.1). It can be noted that the processing processing (see Section 3.1.1). It can be noted that the processing
in this case differs from the offer/answer case in the fact that only in this case differs from the offer/answer case in the fact that only
one key management protocol SHALL be offered (i.e. no negotiation one key management protocol SHALL be offered (i.e. no negotiation
skipping to change at page 11, line 43 skipping to change at page 12, line 27
where KMID is as defined in Section 2. where KMID is as defined in Section 2.
For example, if the offered protocols are MIKEY and two yet-to-be- For example, if the offered protocols are MIKEY and two yet-to-be-
invented protocols KEYP1, KEYP2, the SDP is: invented protocols KEYP1, KEYP2, the SDP is:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=key-mgmt:mikey ddOoF9sdhskd727ghuiSDsdhsoKko7eWsnDSJD... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD...
a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD...
m=audio 39000 RTP/SAVP 98 m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31 m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
The protocol list, "mikey;keyp1;keyp2", would be generated from The protocol list, "mikey;keyp1;keyp2", would be generated from
the SDP description and used as input to each specified key the SDP description and used as input to each specified key
management protocol (together with the data for that protocol). management protocol (together with the data for that protocol).
Each of the three protocols includes this protocol identifier Each of the three protocols includes this protocol identifier
list in its authentication coverage (according to its protocol list in its authentication coverage (according to its protocol
specification). specification).
If more than one protocol is supported by the offerer, it is If more than one protocol is supported by the offerer, it is
RECOMMENDED that all acceptable protocols are included in the first RECOMMENDED that all acceptable protocols are included in the first
offer, rather than making single, subsequent alternative offers in offer, rather than making single, subsequent alternative offers in
response to error messages, see "Security Considerations". response to error messages, see "Security Considerations".
End-to-end integrity protection of the key-mgmt attributes
altogether, provided externally to the key management themselves,
also gives protection 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. As however this end-to-end protection is
not an assumption of the framework, the mechanisms defined in this
section SHALL be applied.
3.2. RTSP usage 3.2. RTSP usage
RTSP does not use the offer/answer model, as SIP does. This causes 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 some problems, as it is not possible (without modifying RTSP) to send
back an answer. To solve this, a new header has been introduced back an answer. To solve this, a new header has been introduced
(Section 2.2). This also assumes that the key management also has (Section 2.2). This also assumes that the key management also has
some kind of binding to the media, so that the response to the server some kind of binding to the media, so that the response to the server
will be processed as required. will be processed as required.
The server SHALL be the Initiator of the key management exchange for The server SHALL be the Initiator of the key management exchange for
skipping to change at page 14, line 28 skipping to change at page 15, line 22
written. written.
4. Example scenarios 4. Example scenarios
The following examples utilize MIKEY [MIKEY] as the key management The following examples utilize MIKEY [MIKEY] as the key management
protocol to be integrated into SDP and RTSP (see Section 5.1.). protocol to be integrated into SDP and RTSP (see Section 5.1.).
Example 1 (SIP/SDP) Example 1 (SIP/SDP)
A SIP call is taking place between Alice and Bob. Alice sends an A SIP call is taking place between Alice and Bob. Alice sends an
Invite message consisting of the following offer: INVITE message consisting of the following offer:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff s=Cool stuff
e=alice@w-land.example.com e=alice@w-land.example.com
t=0 0 t=0 0
c=IN IP4 w-land.example.com c=IN IP4 w-land.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2
UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt
0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV
m=audio 49000 RTP/SAVP 98 m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31 m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
i.e. Alice proposes to set up one audio stream and one video stream i.e. 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 that run over SRTP (signaled by the use of the SAVP profile). She
uses MIKEY to set up the security parameters for SRTP (Section 6). uses MIKEY to set up the security parameters for SRTP (Section 6).
The MIKEY message contains the security parameters, together with the The MIKEY message contains the security parameters, together with the
necessary key material. Note that MIKEY is exchanging the crypto necessary key material. Note that MIKEY is exchanging the crypto
suite for both streams, as it is placed at the session level. Also, 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 provides its own security, i.e. when Bob processes Alice's
MIKEY message, he will also find the signaling of the security MIKEY message, he will also find the signaling of the security
parameters used to secure the MIKEY exchange. Alice's authentication parameters used to secure the MIKEY exchange. Alice's endpoint's
information is also carried within the MIKEY message, to prove that authentication information is also carried within the MIKEY message,
the message is authentic. 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 Upon receiving the offer, Bob checks the validity of the received
MIKEY message, and, in case of successful verification, he accepts MIKEY message, and, in case of successful verification, he accepts
the offer and sends an answer back to Alice (with his authentication the offer and sends an answer back to Alice (with his authentication
information, and, if necessary, also some key material from his information, and, if necessary, also some key material from his
side): side):
v=0 v=0
o=bob 2891092897 2891092897 IN IP4 foo.example.com o=bob 2891092897 2891092897 IN IP4 foo.example.com
s=Cool stuff s=Cool stuff
e=bob@foo.example.com e=bob@foo.example.com
t=0 0 t=0 0
c=IN IP4 foo.example.com c=IN IP4 foo.example.com
a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2
V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98 m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31 m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
Upon receiving the answer, Alice verifies the correctness of it. In Upon receiving the answer, Alice verifies the correctness of it. In
case of success, at this point Alice and Bob share the security case of success, at this point Alice and Bob share the security
parameters and the keys needed for a secure RTP communication. parameters and the keys needed for a secure RTP communication.
Example 2 (SDP) Example 2 (SDP)
skipping to change at page 15, line 43 skipping to change at page 16, line 40
previous case, but applies only to the audio stream. previous case, but applies only to the audio stream.
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff s=Cool stuff
e=alice@w-land.example.com e=alice@w-land.example.com
t=0 0 t=0 0
c=IN IP4 w-land.example.com c=IN IP4 w-land.example.com
m=audio 49000 RTP/SAVP 98 m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=video 52230 RTP/AVP 31 m=video 52230 RTP/AVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
Bob would then act as described in the previous example, including Bob would then act as described in the previous example, including
the MIKEY answer at the media level for the audio stream (as Alice the MIKEY answer at the media level for the audio stream (as Alice
did). did).
Note that even if the key management attribute were specified at Note that even if the key management attribute were specified at
session level, the video part would not be affected by this (as a session level, the video part would not be affected by this (as a
security profile is not used, instead the RTP/AVP profile is security profile is not used, instead the RTP/AVP profile is
skipping to change at page 16, line 35 skipping to change at page 17, line 35
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 478 Content-Length: 478
v=0 v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie s=Action Movie
e=action@movie.example.com e=action@movie.example.com
t=0 0 t=0 0
c=IN IP4 movie.example.com c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action a=control:rtsp://movie.example.com/action
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=audio 0 RTP/SAVP 98 m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=control:rtsp://movie.example.com/action/audio a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31 m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=control:rtsp://movie.example.com/action/video a=control:rtsp://movie.example.com/action/video
The client checks the validity of the received MIKEY message, and, in The client checks the validity of the received MIKEY message, and, in
case of successful verification, it accept the message. The client case of successful verification, it accept the message. The client
then includes its key management data in the SETUP request going back then includes its key management data in the SETUP request going back
to the server, the client authentication information (to prove that to the server, the client authentication information (to prove that
the message is authentic) and, if necessary, some key material. the message is authentic) and, if necessary, some key material.
SETUP rtsp://movie.example.com/action/audio RTSP/1.0 SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313 CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action"; keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
data="skaoqDeMkdwRW278HjKVB..." data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."
The server processes the request including checking the validity of The server processes the request including checking the validity of
the key management header. the key management header.
RTSP/1.0 200 OK RTSP/1.0 200 OK
CSeq: 313 CSeq: 313
Session: 12345678 Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001 server_port=5000-5001
Note than in this case the key management line was specified at the Note than in this case the key management line was specified at the
skipping to change at page 17, line 45 skipping to change at page 18, line 45
v=0 v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie s=Action Movie
e=action@movie.example.com e=action@movie.example.com
t=0 0 t=0 0
c=IN IP4 movie.example.com c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action a=control:rtsp://movie.example.com/action
m=audio 0 RTP/SAVP 98 m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/audio a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31 m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/video a=control:rtsp://movie.example.com/action/video
Each RTSP header are inserted in the SETUP related to the audio and Each RTSP header are inserted in the SETUP related to the audio and
video separately: video separately:
SETUP rtsp://movie.example.com/action/audio RTSP/1.0 SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313 CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
data="skaoqDeMkdwRW278HjKVB..." data="AQEFgM0XflABAAAAAAAAAAAAA..."
and similarly for the video session: and similarly for the video session:
SETUP rtsp://movie.example.com/action/video RTSP/1.0 SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315 CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059 Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video"; keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="RW278HjKVBskaoqDeMkdw..." data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
Note: The "uri" parameter could be excluded from the two SETUP Note: The "uri" parameter could be excluded from the two SETUP
messages in this example. messages in this example.
5. Adding further Key management protocols 5. Adding further Key management protocols
This framework cannot be used with all key management protocols. The This framework cannot be used with all key management protocols. The
key management protocol needs to comply with the requirements key management protocol needs to comply with the requirements
described in Section 3. In addition to this, the following needs to described in Section 3. In addition to this, the following needs to
be defined: be defined:
skipping to change at page 20, line 41 skipping to change at page 21, line 39
7. Security Considerations 7. Security Considerations
The framework for transfer of key management data as described here The framework for transfer of key management data as described here
is intended to provide the security parameters for the end-to-end is intended to provide the security parameters for the end-to-end
protection of the media session. It is furthermore good practice to protection of the media session. It is furthermore good practice to
secure the session setup (e.g. SDP, SIP, RTSP, SAP). However, it 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 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 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 intermediate proxies to have access to part of the SIP message, and
sometimes also to the SDP description (c.f. [E2M]). General security sometimes also to the SDP description (c.f. [E2M]), although end-to-
considerations for the session setup can be found in SDP [SDPnew], end confidentiality can hide bodies from intermediaries. General
SIP [SIP], and RTSP [RTSP]. The framework defined in this memo is security considerations for the session setup can be found in SDP
useful when the session setup is not protected in an end-to-end [SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this
fashion, but the media streams needs to be end-to-end protected, memo is useful when the session setup is not protected in an end-to-
hence the security parameters such as keys are not wanted revealed to end fashion, but the media streams needs to be end-to-end protected,
intermediaries. hence the security parameters (such as keys) are not wanted revealed
to nor manipulated by intermediaries.
The security will also depend on the encapsulated level of security The security will also depend on the encapsulated level of security
the key management protocol offers. It follows that, under the the key management protocol offers. It follows that, under the
assumption that the key management schemes are secure, the SDP can be assumption that the key management schemes are secure, the SDP can be
passed along unprotected without affecting the key management as passed along unencrypted without affecting the key management as
such, and the media streams will still be secure even if some such, and the media streams will still be secure even if some
attackers gained knowledge of the SDP contents. Further security attackers gained knowledge of the SDP contents. Further security
considerations can be found for each key management protocol (for considerations can be found for each key management protocol (for
MIKEY these can be found in [MIKEY]). MIKEY these can be found in [MIKEY]). However, if the SDP messages
are not sent integrity protected between the parties, it is possible
However, if the SDP messages are not sent authenticated between the for an active attacker to change attributes without being detected.
parties, it is possible for an active attacker to change attributes As the key management protocol may (indirectly) rely on some of the
without being detected. As the key management protocol may session information from SDP (e.g., address information), an attack
(indirectly) rely on some of the session information from SDP (e.g., on SDP may have indirect consequences on the key management. Even if
address information), an attack on SDP may have indirect consequences the key management protocol does not rely on parameters of SDP and
on the key management. Even if the key management protocol does not will not be affected by manipulation of these, different DoS attacks
rely on parameters of SDP and will not be affected by manipulation of aimed at SDP may lead to undesired interruption in the setup. See
these, different DoS attacks aimed at SDP may lead to undesired also the attacks described at the end of this section.
interruption in the setup.
The use of multiple key management protocols in the same offer may The use of multiple key management protocols in the same offer may
open up the possibility of a bidding-down attack, as specified in open up the possibility of a bidding-down attack, as specified in
Section 3.1.4. To exclude such possibility, the authentication of the Section 3.1.4. To exclude such possibility, the authentication of the
protocol identifier list is used. Note though, that the security protocol identifier list is used. Note though, that the security
level of the authenticated protocol identifier will be as high (or level of the authenticated protocol identifier will be as high (or
low), as the "weakest" protocol. Therefore, it is discouraged to low), as the "weakest" protocol. Therefore, it is discouraged to
offer protocols with too different security levels. offer protocols with too different security levels.
Note that it is impossible to assure the authenticity of a declined Note that it is impossible to assure the authenticity of a declined
skipping to change at page 21, line 38 skipping to change at page 22, line 36
the answerer declines the offer usually means that he does not the answerer declines the offer usually means that he does not
support the protocol(s) offered, and consequently cannot be expected support the protocol(s) offered, and consequently cannot be expected
to authenticate the response either. This means that if the Initiator to authenticate the response either. This means that if the Initiator
is unsure of which protocol(s) the Responder supports, we RECOMMEND is unsure of which protocol(s) the Responder supports, we RECOMMEND
that the Initiator offers all acceptable protocols in a single offer. that the Initiator offers all acceptable protocols in a single offer.
If not, this opens up the possibility for a "man-in-the-middle" If not, this opens up the possibility for a "man-in-the-middle"
(MITM) to affect the outcome of the eventually agreed upon protocol, (MITM) to affect the outcome of the eventually agreed upon protocol,
by faking unauthenticated error messages until the Initiator by faking unauthenticated error messages until the Initiator
eventually offers a protocol "to the liking" of the MITM. This is not eventually offers a protocol "to the liking" of the MITM. This is not
really a security problem, but rather a mild form of denial of really a security problem, but rather a mild form of denial of
service that can be avoided by following the above recommendation. In service that can be avoided by following the above recommendation.
the case that the response declines any security (therefore there is Note also that the declined offer could be result of an attacker who
impossibility of authenticating it), the session setup SHALL be sits on the path and removes all the key management offers. The
aborted. bidding-down attack prevention, as described above, would not work in
this case (as the answerer receives no key management attribute).
Also here it is impossible to assure the authenticity of a declined
offer, though here the reason is the "peeling-off" attack. It is up
to the local policy to decide the behavior in the case that the
response declines any security (therefore there is impossibility of
authenticating it). If for example the local policy requires a secure
communication and cannot accept an unsecured one, then the session
setup SHALL be aborted.
8. IANA Considerations 8. IANA Considerations
8.1. SDP Attribute Registration 8.1. SDP Attribute Registration
A new SDP attribute needs to be registered for the purpose of key A new SDP attribute needs to be registered for the purpose of key
management protocol integration with SDP. management protocol integration with SDP.
Contact: Fredrik Lindholm Contact: Fredrik Lindholm
mailto: fredrik.lindholm@ericsson.com mailto: fredrik.lindholm@ericsson.com
skipping to change at page 22, line 51 skipping to change at page 24, line 13
following registration created initially: "mikey". following registration created initially: "mikey".
Contact: Fredrik Lindholm Contact: Fredrik Lindholm
mailto: fredrik.lindholm@ericsson.com mailto: fredrik.lindholm@ericsson.com
tel: +46 8 58531705 tel: +46 8 58531705
Value name: mikey Value name: mikey
Long name: Multimedia Internet KEYing Long name: Multimedia Internet KEYing
Purpose: Usage of MIKEY with the key-mgmt-att-field Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header attribute and the keymgmt RTSP header
Reference: Section 7 in RFC yyyy Reference: Section 7 in RFC 3830
Note that this registration implies that the protocol identifier, Note that this registration implies that the protocol identifier,
KMID, name space will be shared between SDP and RTSP. KMID, name space will be shared between SDP and RTSP.
Further values may be registered according to the "Specification Further values may be registered according to the "Specification
Required" policy as defined in [RFC2434]. Each new registration needs Required" policy as defined in [RFC2434]. Each new registration needs
to indicate the parameter name, and register it within IANA. Note to indicate the parameter name, and register it within IANA. Note
that the parameter name is case sensitive and it is RECOMMENDED that that the parameter name is case sensitive and it is RECOMMENDED that
the name to be in lower case letters. For each new registration, it the name to be in lower case letters. For each new registration, it
is mandatory that a permanent, stable, and publicly accessible is mandatory that a permanent, stable, and publicly accessible
skipping to change at page 23, line 29 skipping to change at page 24, line 42
* Value name: the name of the value being registered (which MUST * Value name: the name of the value being registered (which MUST
comply with the KMID as defined in Section 2) comply with the KMID as defined in Section 2)
* Long Name: long-form name in English * Long Name: long-form name in English
* Purpose: short explanation of the purpose of the registered name. * Purpose: short explanation of the purpose of the registered name.
* Reference: a reference to the specification (e.g. RFC number) * Reference: a reference to the specification (e.g. RFC number)
providing the usage guidelines in accordance to Section 5 (and providing the usage guidelines in accordance to Section 5 (and
also complying to the specified requirements). also complying to the specified requirements).
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Joerg Ott, Rolf Blom, Magnus Brolin, The authors would like to thank Rolf Blom, Johan Bilien, Magnus
Johan Bilien, Jon-Olov Vatn, and Erik Eliasson. A special thanks to Brolin, Erik Eliasson, Martin Euchner, Joerg Ott, Jon Peterson, and
Colin Perkins and Magnus Westerlund, who contributed in many Jon-Olov Vatn. A special thanks to Colin Perkins and Magnus
sections. Westerlund, who contributed in many sections.
10. Author's Addresses 10. Author's Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas Phone: +358 40 5079256 02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara Elisabetta Carrara
Ericsson Research Ericsson Research
skipping to change at page 24, line 19 skipping to change at page 25, line 37
Karl Norrman Karl Norrman
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502 SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@ericsson.com Sweden EMail: karl.norrman@ericsson.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC yyyy, Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC 3830.
[Internet Draft, <draft-ietf-msec-mikey-08.txt>].
[OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with
the Session Description Protocol (SDP)", IETF, RFC 3264. the Session Description Protocol (SDP)", IETF, RFC 3264.
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", IETF, RFC 2326. Streaming Protocol (RTSP)", IETF, RFC 2326.
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", IETF, RFC 2119. Requirement Levels", IETF, RFC 2119.
skipping to change at page 24, line 51 skipping to change at page 26, line 18
[RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", IETF, RFC 2434. IANA Considerations Section in RFCs", IETF, RFC 2434.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", IETF, RFC 3548. Encodings", IETF, RFC 3548.
11.2. Informative References 11.2. Informative References
[E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the [E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the
Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono- Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono-
sipping-end2middle-security-01. sipping-end2middle-security-03.
[KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", IETF, RFC 1510. Service (V5)", IETF, RFC 1510.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", IETF, RFC 3851.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
K., "The Secure Real-time Transport Protocol", IETF, RFC 3711. K., "The Secure Real-time Transport Protocol", IETF, RFC 3711.
[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security
Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires in October 2004. This Internet-Draft expires in April 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/