Network Working Group A. Barreto Internet-Draft Instituto Tecnologico de Intended status: Experimental Aeronautica Expires: December 10, 2007 A. Faleiros Universidade Federal do ABC June 8, 2007 MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode draft-barreto-ietf-dhhmac-sas-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents a new transport mode to the Multimedia Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has as its objective the negotiation of cryptography parameters necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end multimedia channel, but all its operation modes have some kind of limitation that prevents it of being used to this purpose. The Barreto & Faleiros Expires December 10, 2007 [Page 1] Internet-Draft MIKEY DHHMAC-SAS June 2007 MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and MIKEY-DHHMAC modes by adding the features of key continuity and Short Authentication String (SAS), making possible its use in any end-to- end multimedia scenario. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Description of the MIKEY Modes . . . . . . . . . . . . . . 4 2.2. The ZRTP Protocol . . . . . . . . . . . . . . . . . . . . 5 2.3. Use Case Motivating the Proposed Mode . . . . . . . . . . 6 3. A new MIKEY DHHMAC Mode: MIKEY-DHHMAC-SAS . . . . . . . . . . 6 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Functioning of the MIKEY-DHHMAC-SAS . . . . . . . . . . . 9 4. DHHMAC-SAS Payload Formats . . . . . . . . . . . . . . . . . . 10 4.1. Modified Table 6.1a from RFC 3830 . . . . . . . . . . . . 10 4.2. Modified Table 6.12 from RFC 3830 . . . . . . . . . . . . 11 4.3. Modified Table 6.15 from RFC 3830 . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Barreto & Faleiros Expires December 10, 2007 [Page 2] Internet-Draft MIKEY DHHMAC-SAS June 2007 1. Introduction The purpose of MIKEY protocol [RFC3830] is to negotiate and to carry a set of parameters necessary to the establishment of a safe multimedia channel. This set of parameters is known as cryptographic context. As example of existing information in a cryptographic context are the session keys negotiated and its sizes, the safe multimedia transport protocols to be used and its ways of functioning, among others information. One of the greatest qualities of the related protocol is its capacity to negotiate the cryptographic context in only one round, that is, in only one exchange of offers and acceptance (or refuses) message, thus making possible its insertion in SDP protocol [RFC4566] and causing a minimum modification in the preexisting signaling protocols. Another great advantage is the fact that it makes possible to secure the information being based only on protections developed in the terminals, not having the necessity to perform any control on the channel where the information will pass through, which it is known as end-the-end protection. The importance of end-to-end architectures resides on the possibility of its use in existing scenarios, also on those where it is not possible to guarantee a trust relationship between all the intermediary elements necessary to create a channel. It can be cited as an example, the case of an user that has a personal trust relationship with another one but the companies providing the telephone service to the users do not have a similar trust. In this case, it only is possible to establish a security channel through an end-to-end security architecture. MIKEY offers several types of safe transportation to the cryptographic context, however all these types of transportation have some kind of limitation that makes them not very appropriate to be used on large scales with many numbers of users and environments that need a low cost of implementation. Alternatively, there are other end-the-end alternatives for the safe transport of the cryptographic context (ZRTP [I-D.zimmermann-avt-zrtp] ), but, as well as in the MIKEY, all these solutions have some scalability limitation. This document presents a new transport mode to the MIKEY, the MIKEY- DHHMAC-SAS. The MIKEY-DHHMAC-SAS solves the scalability and cost problems found in the previous MIKEY's mode, as well as adds existing characteristics of the alternative protocols presented in the previous paragraph, without inserting their limitations. Barreto & Faleiros Expires December 10, 2007 [Page 3] Internet-Draft MIKEY DHHMAC-SAS June 2007 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Existing Solutions 2.1. Description of the MIKEY Modes The MIKEY [RFC3830] originally has three forms to carry through the transport of the cryptographic context (MIKEY-PS, MIKEY-PK and MIKEY-DH). Later, aiming at to solve problems and limitations found in this specification, two other ways had been developed (MIKEY-RSA-R and MIKEY-DHHMAC). The first type is MIKEY-PS. It uses a pre-shared key to provide authentication and secrecy of the cryptographic context. This solution is sufficiently efficient in scenarios with a small number of users, because its use in an environment with many users (n) would require a negotiation of a great number of session keys (n^2-n)/2, as the secrets are combined pair-by-pair. The second type uses a public key infrastructure (PKI) to conduct this negotiation, there is two types: the MIKEY-PK and the MIKEY-RSA-R [RFC4738]. Both types use the public key of its pair to cipher the negotiated key and its private key to sign the messages negotiated by the protocol. In the first one, MIKEY-PK, a problem similar to the one found in S/MIME exists, so in order to complete conduct the cipher task, it is necessary that the user had previously acquired its certificate pair. This problem is solved by MIKEY-RSA-R, which in the initiation message sends only its certificate instead of generating the symmetrical secret to be shared by the pairs, which makes this task to be conducted in the terminal that will answer the initial message. Although MIKEY-RSA-R is sufficiently robust, the use of PKI can be very onerous in some scenarios, for example residential users. The use of PKI in these scenarios would make necessary that each existing user has to acquire a certificate from a certification authority. As an alternative to the use of PKI, MIKEY offers types of transportation using the Diffie-Hellman algorithm (DH): MIKEY-DH and MIKEY-DHHMAC [RFC4650]. Even though MIKEY-DH guarantees the confidentiality of secret shared in an independent way of PKI, it still needs to use certificates to guarantee protection against man- in-the-middle (MITM) attacks. To solve this problem, MIKEY-DHHMAC Barreto & Faleiros Expires December 10, 2007 [Page 4] Internet-Draft MIKEY DHHMAC-SAS June 2007 protects the protocol using authenticated messages for a previously shared secret established between the pairs, this creates/generates a scalable limitation similar to the one found in MIKEY-PS. 2.2. The ZRTP Protocol The other alternative to the problem cited in this document is the ZRTP [I-D.zimmermann-avt-zrtp]. The ZRTP is a specification draft studying in the IETF and it uses the DH to provide the safe negotiation. However, it uses two new properties: the authentication based on SAS and the use of Key Continuity, instead of using certified and static keys shared between the pairs. The first one, the authentication process, it is based on a signature generated by a hash function using the DH public values (DHi and DHr) generated by the pairs, this is called Shorts Authentication String (SAS). If there is a MITM attack, the DH public values received will not be those emitted by the real pairs. They must check to see if they have the same SAS, before initiating the use of the channel with sensible information. Previous to initiating the use of the channel with sensible information, the pairs should match as a proof of evidence that they have the same SAS. The second property offered for the ZRTP is called Key Continuity. This concept consists of not using only the private value generated by the DH algorithm as the key used for the cipher process, but the combination of this value with others keys previously shared between the terminals, negotiated by DH or through other protocol, as MIKEY. This characteristic guarantees an additional resistance to protocol attacks. If anyone has suffered a MITM attack, the secret that the aggressor has is not enough to monitor the content of the channel. Although the ZRTP is safe enough, its functioning is based on a series of posterior messages to the signaling protocols (SIP) before opening the multimedia channel. This makes the protocol not very attractive from the efficiency point of view. Such fact occurs because many users can give up the call because of the delay caused by the establishment of the secret. Moreover, when compared with MIKEY, ZRTP needs more rounds to start working. Moreover, it is possible to insert MIKEY messages inside of the existing signaling protocols. These messages are inserted in the offer/acceptance message of the protocols using only one attribute. This facilitates the life of VoIP developers, which have to make just a few modifications in its products to provide the security offered by the protocol. Barreto & Faleiros Expires December 10, 2007 [Page 5] Internet-Draft MIKEY DHHMAC-SAS June 2007 2.3. Use Case Motivating the Proposed Mode During the presentation of this document some alternatives have been introduced, some are standards and others are experimental. The underlying intention of that is the construction of a safe channel between two users. Although all the solutions presented support this intention, when referring to security in an end-to-end scenario, the architectures studied in this document have some limitations, as it has previously been presented. However, when comparing the solutions presented, MIKEY protocol has showed to be the most efficient one because in every type of functioning, it accomplishes the negotiation of the cryptography context in a safety way in only one round. As it has been seen, in an end-to-end scenario composed by many users (telephony in the Internet), the most attractive way of MIKEY protocol is based on Diffie-Hellman secret (DH). Among all types of MIKEY that use DH, only one (MIKEY-DHHMAC) makes the implementation of the desired scenario possible with the necessary independence. However this scenario is not very scalable because it uses a pre- shared key. Considering this scenario, in the present chapter a new extension of MIKEY protocol will be introduced, the MIKEY-DHHMAC-SAS. This type of functioning extends MIKEY-DH standard, solving the problem of scalability found in [RFC4650]. Additionally, this new type adds the properties of Key Continuity and authentication through SAS [I-D.zimmermann-avt-zrtp], thus increasing the robustness of the original protocol [RFC3830]. 3. A new MIKEY DHHMAC Mode: MIKEY-DHHMAC-SAS 3.1. Outline The MIKEY-DHHMAC-SAS is basically the MIKEY-DHHMAC with some additional protections of ZRTP protocol. Its objective is to complement the MIKEY-DHHMAC, proving the necessary scalability so that it can be used in heterogeneous environments and by a very great number of users. Its functioning occurs in one round. It is inserted in the initiation message (DHHMAC_SAS_I) the DH public value (DHi) constructed by the initiator, while in the reply message (DHMAC_SAS_R) the value sent for the initiator (DHi) is sent, besides Barreto & Faleiros Expires December 10, 2007 [Page 6] Internet-Draft MIKEY DHHMAC-SAS June 2007 the public value calculated by the addressee (DHr), which makes that both messages possess a very similar format, as it can be seen in figure 01. The great difference between MIKEY-DHHMAC-SAS and others types of MIKEY is that it offers two levels of authentication. The first level uses KEMAC header to provide the authentication with initiation and reply messages. As well as MIKEY-DHHMAC, the content of KEMAC is used only for the authentication of all MIKEY message body and its cryptography resources are not used. Differently from MIKEY-DHHMAC, this new protocol does not use static pre-shared keys to accomplish the authentication of messages and to provide a protection against MITM attacks. Instead, MIKE-DHHMAC-SAS uses dynamic keys which might have been agreed among the keys using other protocols or old DH sessions. The MIKEY-DHHMAC-SAS mode exchange is defined as follows: Initiator Responder DHMAC_SAS_I=HDR,T,RAND,IDi,IDr, {SP},DHi,{GenExt(KHASH)},{KEMAC} ---------> DHMAC_SAS_R=HDR,T, RAND,IDi, Idr,DHi, Dhr,{KEMAC} <---------- Figure 1: MIKEY-DHHMAC-SAS Mode To inform which keys will be used to accomplish the authentication, MIKEY-DHHMAC-SAS uses a new MIKEY header, the KHASH (KeyHASH). This new header carries the last 32 bits from the signatures generated by three shared keys chosen randomly between the pairs, which will be used by the protocol to make the authentication messages. The KHASH header is represented by the expression: KHASH = hash (s0)32||hash (s1)32||hash (s2)32. Once the users get the value carried in KHASH, they must use it to generate the shared key Kh=hash (s0||s1||s2), which will be used to authenticate the content of MIKEY messages. It must be highlighted that the hash algorithm used to generate the Kh value is the same one used to generate the KHASH value. An additional comment on KHASH is that this header only exists in the initiation message. This is done to prevent that a MITM attacker changes the keys offered by the initiator, substituting them for keys that he has access. Barreto & Faleiros Expires December 10, 2007 [Page 7] Internet-Draft MIKEY DHHMAC-SAS June 2007 Once all keys are agreed in the previous sessions, they are locally stored in the terminal, in an isolated form by a definite amount of time. In the case of the destination terminal does not have some of the keys offered by the initiator, the destination terminal must generate an error message (Invalid KEY - figure 3) and send it to the initiator or, if you local police to permit, the receiver phone can't put in its response (DHHMAC-SAS-R) the KHASH header, meaning that the channel security is based only the SAS check. Another characteristic of MIKEY-DHHMAC-SAS is that the use of authentication based on KEMAC header is optional. Therefore it cannot be calculated in the first safe conference negotiated between the pairs. It has been distinguished that the guarantee against MITM attacks and the correct identification of the pairs are accomplished through a second level of protection, which is based on Shorts Authentication String (SAS). As it has been presented in [I-D.zimmermann-avt-zrtp], the SAS consists of a signature generated by a HMAC function using the DH public values agreed in the session as input. The HMAC function used is the same one specified in KEMAC header. The SAS value has the form presented in expression: SAS=hash (Dhi|| DHr||"Short String Authentication"), where DHi and DHr are respectively those DH public values calculated in the initiator and its pair. As in [I-D.zimmermann-avt-zrtp], the new MIKEY mode depends on an active participation of the user. Besides, it requires from the system some type of interface with the user, since they must check the SAS values that have been received before initiating the discussion of a secret content. In the case of suffering a MITM attack, these values will not be the same, which makes the attack to be detected and the conference interrupted. To provide more robustness against MITM attacks, instead of using the secret generated by DH algorithm (DHKey) to derive the used keys for the multimedia transportation protocol (TGK), the terminals will generate a new secret derived from its combination with the one used to authenticate MIKEY messages (Kh). The TGK is defined by TGK=hash (DHKey||Kh), where the hash function is the same one specified in KHASH. The property above offers MIKEY the characteristic of Key Continuity, such as the ZRTP, which preserves the channel even if a MITM attack occurs. Barreto & Faleiros Expires December 10, 2007 [Page 8] Internet-Draft MIKEY DHHMAC-SAS June 2007 Since the shared keys used in the cipher process are chosen randomly, the system can store the DHKey secret automatically, as soon as the channel is initialized, therefore, it does not need any type of synchronization. This is different from the ZRTP, which offers some concern to identify and validate through the system when checking SAS. 3.2. Functioning of the MIKEY-DHHMAC-SAS As it has been showed in figure 1, the communication process of MIKEY-DHHMAC-SAS is done in only one round, where the initiator generates a DH public value (DHi) and inserts it in an initial message (DHHMAC_SAS_I), which must be confirmed and returned with the second public part DHr in a reply message (DHHMAC_SAS_R). The first step that the initiator must accomplish is the generation of its DH secret (x), as well as the public value (DHi) to be carried by the initiation message. The rule of generation of DH secret is the same one presented in the original specification of MIKEY protocol. After generating the DHi, the user needs to define several parameters of the initiation message. The definition rule of these attributes is the same one in [RFC3830], with exception of the KEMAC attribute, which obeys the rules based on MIKEY-DHHMAC and KHASH. This is specific to the new type of transportation and it has been presented in the previous section. If the initiator has all the attributes necessary to compose the DHHMAC message, then it constructs the MIKEY message, inserts it in the SDP message body [RFC4567] and it sends it to the person that he wishes to establish the communication. When receiving the initialization message, the destination terminal shall open its pair identification header and the transportation type in which MIKEY is functioning, which in this case will be the MIKEY- DHHMAC-SAS. After that, it will locate the signatures of all the keys previously shared with that user. If the authentication of the messages is accomplished by the MIKEY through KEMAC header and it is possible to recover the keys used through KHASH, the matching of the message authentication tag will be done. If the authentication tag does not match, an error message must be generated and sent in reply to the initiation message. If the authentication tag matches, the terminal will proceed with the generation of the local secret (y) and DH value to be shared in the same ways of the ones done in the initiator terminal. Barreto & Faleiros Expires December 10, 2007 [Page 9] Internet-Draft MIKEY DHHMAC-SAS June 2007 If the terminal has these values, it will be able to build the reply message to be sent to the initiator. Moreover, the local terminal will must generate the shared secret (TGK). Once this task is done, the called terminal will start its multimedia channel, while it waits the initiator terminal to send a reply message. Once the initiator received the reply message, it will have to validate it through the verification of its authentication (if such authentication exists) and after that generate the TGK shared with its pair. After this, it will have to proceed to the initialization of the local multimedia channel, which will make the establishment of a safe conference possible. After the initialization of the channel, even before its use to transport sensible information is possible, the terminals must check the SAS values. Optionally, the application might provide an interface that allows the user to inform the validation of SAS. The information of SAS validation can be used to define the period of time that the secret (DHKey) generated for the session will have to remain stored in a safety key repository in the system. If this information is not validated, the system will not store the key. Once the SAS is validated, the terminals can initiate the exchange of confidential information between themself, therefore all the protections offered by the protocol are active. 4. DHHMAC-SAS Payload Formats This section specifies the payload formats and data type values for MIKEY-DHHMAC-SAS. This document introduces two new message types (Table 6.1a of [RFC3830]), an Error no (Table 6.12 of [RFC3830]), and a general extension payload (Table 6.15 of [RFC3830]). This section specifies those additions. 4.1. Modified Table 6.1a from RFC 3830 Modified Table 6.1a from RFC 3830: Barreto & Faleiros Expires December 10, 2007 [Page 10] Internet-Draft MIKEY DHHMAC-SAS June 2007 Data type | Value | Comment ------------------------------------------------------------------ Pre-shared | 0 | Initiator's pre-shared key message PSK ver msg | 1 | Verification message of a Pre-shared key msg Public key | 2 | Initiator's public-key transport message PK ver msg | 3 | Verification message of a public-key message D-H init | 4 | Initiator's DH exchange message D-H resp | 5 | Responder's DH exchange message Error | 6 | Error message DHHMAC init | 7 | DH HMAC message 1 DHHMAC resp | 8 | DH HMAC message 2 RSA-R I_MSG | 9 | Initiator's RSA-R public-key message RSA-R R_MSG | 10 | Responder's RSA-R public-key message DHHMAC_SAS_I| 11 | Initiator's DHHMAC-SAS message (NEW) DHHMAC_SAS_R| 12 | Responder's DHHMAC-SAS message (NEW) Figure 2: Table 6.1a from RFC 3830 (Revised) 4.2. Modified Table 6.12 from RFC 3830 Modified Table 6.12 from RFC 3830: Error no | Value| Comment ------------------------------------------------------- Auth failure | 0| Authentication failure Invalid TS | 1| Invalid timestamp Invalid PRF | 2| PRF function not supported Invalid MAC | 3| MAC algorithm not supported Invalid EA | 4| Encryption algorithm not supported Invalid HA | 5| Hash function not supported Invalid DH | 6| DH group not supported Invalid ID | 7| ID not supported Invalid Cert | 8| Certificate not supported Invalid SP | 9| SP type not supported Invalid SPpar | 10| SP parameters not supported Invalid DT | 11| not supported Data type Unspecified error | 12| an unspecified error occurred Unsupported message type | 13 | unparseable MIKEY message Invalid KEY | 14 | shared key don't exists(NEW) Figure 3: Table 6.12 from RFC 3830 (Revised) 4.3. Modified Table 6.15 from RFC 3830 Modified Table 6.15 from RFC 3830: Barreto & Faleiros Expires December 10, 2007 [Page 11] Internet-Draft MIKEY DHHMAC-SAS June 2007 Type | Value| Comments --------------------------------------- Vendor ID | 0| Vendor specific byte string SDP IDs | 1| List of SDP key mgmt IDs (allocated for use in | | [RFC4567]) TESLA I-Key| 2| [RFC4442] Key ID | 3| information on type and identity of keys | | [RFC4563]) CSB_ID | 4| Responder's modified CSB_ID (group mode) KHASH | 5| Key hash=hash (s0)32||hash (s1)32||hash(s2)32 Figure 4: Table 6.15 from RFC 3830 (Revised) 5. Security Considerations Since the protocol uses DH as algorithm for the negotiation of keys, a special attention must be given to the generator of random numbers. This fact, although it is not commented in details in the original MIKEY specification, is very important in the current model, since the use of random operations is very common in MIKEY-DHHMAC-SAS. A possibility consists in generating the random numbers using algorithms based on physical phenomena as those described in [I-D.zimmermann-avt-zrtp]. It is also important to say that many operations of the MIKEY-DHHMAC- SAS are based on hash algorithms. Although the MIKEY standardizes the SHA-1 and the HMAC-SHA-1 as the hash algorithms, the use of more robust algorithms as the SHA-2 and the HMAC-SHA-2, using keys of at least 256 bits, is strongly advised. This is because there are many known attacks on family 1 of SHA. Although attacks for the functionalities inherited from ZRTP [ROBIN] exist, they are very theoretical and only occurs in very specific scenarios of the VoIP technology. This is not the case of the scenario studied in the present document, which makes the technology safe until the present moment. To solve the problem of the necessity of confirmation in the ZRTP, the key storage is done independent and locally in the terminal. Moreover, it is not obligatory. This is possible because the key used to compose the message is based only on some secrets randomly chosen among the secrets locally stored by the terminal. The choice of the values to be used is announced in a protected way through the HMAC message, which makes the use of robust hash algorithms necessary. Barreto & Faleiros Expires December 10, 2007 [Page 12] Internet-Draft MIKEY DHHMAC-SAS June 2007 6. Acknowledgements Many thanks to Rafael Dilego and Beatriz F. Aragao for their reviews of earlier version of this document. 7. IANA Considerations The following IANA assignments were added to the MIKEY registry: Added to "Error payload name spaces:" Invalid KEY-------------- 14 Added to "Common Header payload name spaces:" DHHMAC_SAS_I------------- 11 DHHMAC_SAS_R------------- 12 Added to "General Extensions payload name spaces:" KHASH-------------------- 5 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006. [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Barreto & Faleiros Expires December 10, 2007 [Page 13] Internet-Draft MIKEY DHHMAC-SAS June 2007 Description Protocol", RFC 4566, July 2006. [RFC4567] 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. [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006. [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006. 8.2. Informative References [I-D.zimmermann-avt-zrtp] Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-03 (work in progress), March 2007. [ROBIN] Robin, J. and A. Schwartz, "Analysis of ZRTP. Final Report of Discipline CS259 - Security Protocols of the Stanford University.", 2006. Authors' Addresses Alexandre de Barros Barreto Instituto Tecnologico de Aeronautica Praca Marechal Eduardo Gomes, 50 - Vila das Acacias Sao Jose dos Campos, SP BR Phone: +55 12 3945-9097 Email: kabart@gmail.com Barreto & Faleiros Expires December 10, 2007 [Page 14] Internet-Draft MIKEY DHHMAC-SAS June 2007 Antonio Candido Faleiros Universidade Federal do ABC Rua Catequese 242, 4o. Andar Santo Andre, SP BR Phone: +55 11 4966-3166 Email: faleiros@ufabc.edu.br Barreto & Faleiros Expires December 10, 2007 [Page 15] Internet-Draft MIKEY DHHMAC-SAS June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Barreto & Faleiros Expires December 10, 2007 [Page 16]