the prior signaling exchange did not provide facilities to
authenticate the source. Using an authentication protocol that
does not provide session keys as part of a successful protocol
exchange will make it impossible to derive the necessary
parameters required by TESLA. MIKEY provides session key
establishment. Additionally, the exchange of parameters and
algorithms MUST be authenticated and integrity protected. The
security protection of the parameter exchange needs to provide the
same level or a higher level of security.
5.2. Downgrading Attack
Threat:
The exchange of security-related parameters and algorithms is
always subject to downgrading whereby an adversary modifies some
(or all) of the provided parameters. For example, a few
parameters require that a supported hash algorithm be listed. To
mount an attack, the adversary has to modify the list of provided
algorithms and to select the weakest one.
Countermeasures:
TESLA parameter bootstrapping MUST be integrity protected to
prevent modification of the parameters and their values.
Moreover, since unmodified parameters from an unknown source are
not useful, authentication MUST be provided. This functionality
is not provided by mechanisms described in this document.
Instead, the capabilities of the underlying authentication and key
exchange protocol (MIKEY) are reused for this purpose.
5.3. Denial of Service Attack
Threat:
An adversary might want to modify parameters exchanged between the
communicating entities in order to establish different state
information at the respective communication entities. For
example, an adversary might want to modify the key disclosure
delay or the interval duration in order to disrupt the
communication at a later state since the TESLA algorithm assumes
that the participating communication entities know the same
parameter set.
Countermeasures:
The exchanged parameters and the parameters and algorithms MUST be
integrity protected to allow the recipient to detect whether an
adversary attempted to modify the exchanged information.
Authentication and key exchange algorithms provided by MIKEY offer
this protection.
5.4. Replay Attack
Threat:
An adversary who is able to eavesdrop on one or multiple protocol
exchanges (MIKEY exchanges with the parameters described in this
document) might be able to replay the payloads in a later protocol
exchange. If the recipients accept the parameters and algorithms
(or even the messages that carry these payloads), then a denial of
service, downgrading, or a man-in-the-middle attack might be the
consequence (depending on the entire set of replayed attributes
and messages).
Countermeasures:
In order to prevent replay attacks, a freshness guarantee MUST be
provided. As such, the TESLA bootstrapping message exchange MUST
be unique and fresh, and the corresponding authentication and key
exchange protocol MUST provide the same properties. In fact, it
is essential to derive a unique and fresh session key as part of
the authentication and key exchange protocol run that MUST be
bound to the protocol session. This includes the exchanged
parameters.
5.5. Traffic Analysis
Threat:
An adversary might be able to learn parameters and algorithms if
he is located along the signaling path. This information can then
later be used to mount attacks against the end-to-end multimedia
communication. In some high-security and military environments,
it might even be desirable not to reveal information about the
used parameters to make it more difficult to launch an attack.
Countermeasures:
Confidentiality protection can be provided by a subset of the
available MIKEY authentication and key exchange protocols, namely,
those providing public key encryption and symmetric key
encryption. The initial hash key, which is also one of the TESLA
bootstrapping parameters, does not require confidentiality
protection due to the properties of a hash chain.
6. IANA Considerations
This document requires an IANA registration for the following
attributes. The registries are provided by MIKEY [RFC3830].
Prot Type:
This attribute specifies the protocol type for the security
protocol as described in Section 4.1.
Type:
Identifies the type of the general payload. The General
Extensions Payload was defined to allow possible extensions to
MIKEY without the need for defining a completely new payload each
time. Section 4.4 describes this attribute in more detail.
Following the policies outlined in [RFC3830], the values in the range
up to 240 (including 240) for the above attributes are assigned after
expert review by the MSEC working group or its designated successor.
The values in the range from 241 to 255 are reserved for private use.
The IANA has added the following attributes and their respective
values to an existing registry created in [RFC3830]:
Prot Type:
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
The value of 1 for the ’Prot Type’ must be added to the ’Prot type’
registry created by [RFC3830].
Type:
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The value of 2 for the ’Type’ must be added to the ’Type’ registry
created by [RFC3830]. The values of 0 and 1 are already registered
in [RFC3830].
Also, the IANA has created two new registries:
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see Section 4.2).
TESLA-MAC: MAC Function used in TESLA:
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see Section 4.2).
Following the policies outlined in [RFC2434], the values for the
TESLA-PRF and the TESLA-MAC registry in the range up to 240
(including 240) for the above attributes are assigned after expert
review by the MSEC working group or its designated successor. The
values in the range from 241 to 255 are reserved for private use.
IANA has added the following values to the TESLA-PRF and the
TESLA-MAC registry:
TESLA-PRF:
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
TESLA-MAC:
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
7. Acknowledgements
The authors would like to thank Mark Baugher and Ran Canetti for the
discussions in context of time synchronization. Additionally, we
would like to thank Lakshminath Dondeti, Russ Housley, and Allison
Mankin for their document reviews and for their guidance.
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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
8.2. Informative References
[DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", Work in Progress, April 2005.
[PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar,
"Efficient and Secure Source Authentication for
Multicast", in Proc. of Network and Distributed System
Security Symposium NDSS 2001, pp. 35-46, 2001.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] 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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RSA-R] Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.
Authors’ Addresses
Steffen Fries
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: steffen.fries@siemens.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.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).