[4] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC
4567, July 2006.
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
8.2. Informative References
[6] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
Applied Cryptography", CRC Press 1996.
[7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[9] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol",
Designs, Codes, and Cryptography, Special Issue Public Key
Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171,
2000.
ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps.
[10] Discrete Logarithms and the Diffie-Hellman Protocol,
http://www.crypto.ethz.ch/research/ntc/dldh/.
[11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[13] 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.
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[15] ITU-T Recommendation H.235.7: " H.323 Security framework: Usage
of the MIKEY Key Management Protocol for the Secure Real Time
Transport Protocol (SRTP) within H.235"; 9/2005.
[16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
Key Wrap Algorithm", RFC 3394, September 2002.
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
[18] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535,
June 2006.
[19] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management Architecture",
RFC 4046, April 2005.
[20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[21] ITU-T Recommendation H.235.0, " H.323 Security framework:
Security framework for H-series (H.323 and other H.245 based)
multimedia systems", (09/2005).
[22] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)", RFC 4210, September 2005.
[23] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[24] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Data Validation and
Certification Server Protocols", RFC 3029, February 2001.
[25] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, September
2005.
[26] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, September 2005.
[27] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[37] IANA MIKEY Payload Name Spaces per RFC 3830, see
http://www.iana.org/assignments/mikey-payloads.
[29] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005.
[30] Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash
Algorithm", October 2005,
http://www.cs.columbia.edu/~smb/papers/new-hash.pdf.
[31] Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC
Algorithms For MIKEY", Work in Progress, June 2005.
[32] Bellare, M.: "New Proofs for NMAC and HMAC: Security Without
Collision-Resistance", http://eprint.iacr.org/2006/043.pdf,
November 2005.
[33] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An
additional mode of key Distribution in MIKEY: MIKEY-RSA-R",
Work in Progress, August 2006.
Appendix A. Usage of MIKEY-DHHMAC in H.235
This appendix provides informative overview how MIKEY-DHHMAC can be
applied in some H.323-based multimedia environments. Generally,
MIKEY is applicable for multimedia applications including IP
telephony. [15] describes various use cases of the MIKEY key
management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-
DHHMAC) with the purpose to establish TGK keying material among H.323
endpoints. The TGKs are then used for media encryption by applying
SRTP [20]. Addressed scenarios include point-to-point with one or
more intermediate gatekeepers (trusted or partially trusted) in
between.
One particular use case addresses MIKEY-DHHMAC to establish a media
connection from an endpoint B calling (through a gatekeeper) to
another endpoint A that is located within that same gatekeeper zone.
While EP-A and EP-B typically do not share any auth_key a priori,
some separate protocol exchange means are achieved outside the actual
call setup procedure to establish an auth_key for the time while
endpoints are being registered with the gatekeeper; such protocols
exist [15] but are not shown in this document. The auth_key between
the endpoints is being used to authenticate and integrity protect the
MIKEY-DHHMAC messages.
To establish a call, it is assumed that endpoint B has obtained
permission from the gatekeeper (not shown). Endpoint B as the caller
builds the MIKEY-DHHMAC I_message (see section 3) and sends the
I_message encapsulated within the H.323-SETUP to endpoint A. A
routing gatekeeper (GK) would forward this message to endpoint B; in
case of a non-routing gatekeeper, endpoint B sends the SETUP directly
to endpoint A. In either case, H.323 inherent security mechanisms
[21] are applied to protect the (encapsulation) message during
transfer. This is not depicted here. The receiving endpoint A is
able to verify the conveyed I_message and can compute a TGK.
Assuming that endpoint A would accept the call, EP-A then builds the
MIKEY-DHHMAC R_message and sends the response as part of the
CallProceeding-to-Connect message back to the calling endpoint B
(possibly through a routing gatekeeper). Endpoint B processes the
conveyed R_message to compute the same TGK as the called endpoint A.
1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message
[, R_rev_message])
Notes: If it is necessary to establish directional TGKs for full-
duplex links in both directions B->A and A->B, then the
calling endpoint B instantiates the DHHMAC protocol twice:
once in the direction B->A using I_fwd_message and another run
in parallel in the direction A->B using I_rev_message. In
that case, two MIKEY-DHHMAC I_messages are encapsulated within
SETUP (I_fwd_message and I_rev_message) and two MIKEY-DHHMAC
R_messages (R_fwd_message and R_rev_message) are encapsulated
within CallProceeding-to-CONNECT. The I_rev_message
corresponds with the I_fwd_message. Alternatively, the called
endpoint A may instantiate the DHHMAC protocol in a separate
run with endpoint B (not shown); however, this requires a
third handshake to complete.
For more details on how the MIKEY protocols may be deployed
with H.235, please refer to [15].
Author’s Address
Martin Euchner
Hofmannstr. 51
81359 Munich, Germany
Phone: +49 89 722 55790
Fax: +49 89 722 62366
EMail: martin_euchner@hotmail.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).