[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0",
RFC 2246, January 1999.
Appendix A. MIKEY - SRTP Relation
The terminology in MIKEY differs from the one used in SRTP as MIKEY
needs to be more general, nor is tight to SRTP only. Therefore, it
might be hard to see the relations between keys and parameters
generated in MIKEY and those used by SRTP. This section provides
some hints on their relation.
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP’s crypto context
TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged.
SRTP may use an MKI to index the TEK or TGK (the TEK is then derived
from the TGK that is associated with the corresponding MKI), see
below.
A.1. MIKEY-SRTP Interactions
In the following, we give a brief outline of the interface between
SRTP and MIKEY and the processing that takes place. We describe the
SRTP receiver side only, the sender side will require analogous
interfacing.
1. When an SRTP packet arrives at the receiver and is processed, the
triple <SSRC, destination address, destination port> is extracted
from the packet and used to retrieve the correct SRTP crypto
context, hence the Data SA. (The actual retrieval can, for
example, be done by an explicit request from the SRTP
implementation to MIKEY, or, by the SRTP implementation accessing
a "database", maintained by MIKEY. The application will typically
decide which implementation is preferred.)
2. If an MKI is present in the SRTP packet, it is used to point to
the correct key within the SA. Alternatively, if SRTP’s <From,
To> feature is used, the ROC||SEQ of the packet is used to
determine the correct key.
3. Depending on whether the key sent in MIKEY (as obtained in step 2)
was a TEK or a TGK, there are now two cases.
- If the key obtained in step 2 is the TEK itself, it is used
directly by SRTP as a master key.
- If the key instead is a TGK, the mapping with the CS_ID
(internal to MIKEY, Section 6.1.1) allows MIKEY to compute the
correct TEK from the TGK as described in Section 4.1 before
SRTP uses it.
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK
(or TEK) be associated with a distinct MKI. It is RECOMMENDED that
the use of <From, To> in this scenario be limited to very simple
cases, e.g., one stream only.
Besides the actual master key, other information in the Data SA
(e.g., transform identifiers) will of course also be communicated
from MIKEY to SRTP.
Authors’ Addresses
Jari Arkko
Ericsson Research
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.com
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Mats Naslund
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Karl Norrman
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.