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]