MSEC S. Fries
Internet-Draft H. Tschofenig
Expires: November 24, 2005 Siemens
May 23, 2005
Bootstrapping TESLA
draft-ietf-msec-bootstrapping-tesla-01.txt
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 November 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
With the Timed Efficient Stream Loss-tolerant Authentication protocol
(TESLA) a protocol for providing source authentication in multicast
scenarios has been introduced. TESLA uses MAC chaining for this
purpose. A mapping for TESLA to the Secure Real-time Transport
Protocol (SRTP) has been published which assumes that TESLA
parameters are made available by out-of-band mechanisms.
This document specifies MIKEY payloads for bootstrapping TESLA for
Fries & Tschofenig Expires November 24, 2005 [Page 1]
Internet-Draft Bootstrapping TESLA May 2005
source authentication of secure group communications using SRTP.
TESLA may be bootstrapped using one of the MIKEY key management
approaches, e.g., by using a digitally signed MIKEY message sent via
unicast, multicast or broadcast.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 4
4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 5
4.1 Security Policy payload (SP) . . . . . . . . . . . . . . . 5
4.2 TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Time synchronization . . . . . . . . . . . . . . . . . . . 7
4.4 Key data transport within MIKEY's General Extension
Payload . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1 MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Downgrading Attack . . . . . . . . . . . . . . . . . . . . 11
5.3 Denial of Service Attack . . . . . . . . . . . . . . . . . 11
5.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 11
5.5 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Fries & Tschofenig Expires November 24, 2005 [Page 2]
Internet-Draft Bootstrapping TESLA May 2005
1. Introduction
[I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in
order to support TESLA [I-D.ietf-msec-tesla-intro] for source
authentication in multicast scenarios. Therefore the cryptographic
context needs to be enhanced with a set of TESLA parameters. It is
necessary to provide these parameters before the actual multicast
session starts. [I-D.ietf-msec-srtp-tesla] does not address the
bootstrapping for these parameters.
This document details bootstrapping of TESLA using the Multimedia
Internet Keying (MIKEY) [RFC3830] protocol. MIKEY defines an
authentication and key management framework that can be used for
real-time applications (both for peer-to-peer communication and group
communication). In particular, [RFC3830] is defined in a way to
support SRTP in the first place but is open to enhancements to be
used for other purposes too. Following the description in RFC 3830
[RFC3830] MIKEY is targeted for point to point as well as for group
communication. In the context of group communication an
administrator entity can distributes session keys to the associated
entities participating in the communication session. This scenario
is also applicable for TESLA where one entity may provide information
to many others in a way that the integrity of the communicated
information can be assured. The combination of MIKEY and TESLA
supports this group based approach by utilizing the MIKEY framework
to distribute TESLA parameter information to all involved entities.
The three authentication and key exchange protocols defined in
[RFC3830] as well as the fourth protocol provided by [I-D.ietf-msec-
mikey-dhhmac] may be used to provide also the TESLA parameters. The
required TESLA parameters to be exchanged are already described in
[I-D.ietf-msec-srtp-tesla], while this document describes their
transport within MIKEY.
The following security requirements have to be placed on the exchange
of TESLA parameters:
o Integrity MUST be provided when sending the TESLA parameters,
especially for the initial key.
o Confidentiality MAY be provided for the TESLA parameter
These security requirements apply to the TESLA bootstrapping
procedure only. Security requirements for applications using TESLA
are beyond the scope of this document. Security aspects that relate
to TESLA itself are described in [I-D.ietf-msec-tesla-intro] and
security issues for TESLA usage for SRTP is covered in [I-D.ietf-
msec-srtp-tesla].
Fries & Tschofenig Expires November 24, 2005 [Page 3]
Internet-Draft Bootstrapping TESLA May 2005
2. Terminology
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].
3. TESLA Parameter Overview
According to [I-D.ietf-msec-srtp-tesla] the following transform
dependent parameters need to be provided for proper TESLA operation:
1. An identifier for the PRF, implementing the one-way function
F(x) in TESLA (F(x) is used to calculate keys using a hash
chain), e.g. to indicate a keyed hashing function like HMAC-
SHA1.
2. A non-negative integer, determining the length of the F output,
i.e. the length of the keys in the chain (that is also the key
disclosed in an SRTP packet if TESLA is used in the SRTP
context).
3. An identifier for the PRF, implementing the one-way function
F'(x) in TESLA (to derive the keys for the TESLA MAC, from the
keys in the chain), e.g. to indicate a keyed hashing function
like HMAC-SHA1.
4. A non-negative integer, determining the length of the output of
F', i.e. the length of the key for the TESLA MAC.
5. An identifier for the TESLA MAC, that accepts the output of
F'(x) as its key, e.g. to indicate a keyed hashing function like
HMAC-SHA1.
6. A non-negative integer, determining the length of the output of
the TESLA MAC.
7. The beginning of the session for which a key will be applied.
8. The interval duration (in milliseconds), for which a dedicated
key will be used.
9. The key disclosure delay (in number of intervals), characterizes
the period after which the key will be sent to the involved
entities (e.g., as part of SRTP packets).
10. Non-negative integer, determining the length of the key chain,
which is determined based up the expected duration of the
stream.
Fries & Tschofenig Expires November 24, 2005 [Page 4]
Internet-Draft Bootstrapping TESLA May 2005
11. The initial key of the chain to which the sender has committed
himself.
Section 6.2 in [I-D.ietf-msec-srtp-tesla] provides information about
the default value for the above-listed parameters.
4. Parameter encoding within MIKEY
As mentioned in Section 3, TESLA parameters need to be transported
before actually starting a session. MIKEY currently only defines a
payload for transporting the SRTP policy (see Section 6.10 of
[RFC3830]). This section describes the enhancement of MIKEY to allow
the transport of a TESLA policy and additionally the initial TESLA
key.
4.1 Security Policy payload (SP)
The Security Policy payload defines a set of policies that apply to a
specific security protocol. The definition here relies on the
security policy payload definition in [RFC3830].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits):
Identifies the payload that is added after
this payload. See Section 6.1 of [RFC3830] for
more details.
* Policy no (8 bits):
Each security policy payload must be given a
distinct number for the current MIKEY session by the
local peer. This number is used to map a cryptographic session
to a specific policy (see also Section 6.1.1 of [RFC3830]).
Fries & Tschofenig Expires November 24, 2005 [Page 5]
Internet-Draft Bootstrapping TESLA May 2005
* Prot type (8 bits):
This value defines the security protocol.
A second value needs to be defined as shown below:
(MIKEY already defines the value 0.)
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
* Policy param length (16 bits):
This field defines the total length of the
policy parameters for the selected security protocol.
* Policy param (variable length):
This field defines the policy for the specific
security protocol.
The Policy param part is built up by a set of Type/Length/Value (TLV)
payloads. For each security protocol, a set of possible type/value
pairs can be negotiated as defined.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits):
Specifies the type of the parameter.
* Length (8 bits):
Specifies the length of the Value field (in bytes).
* Value (variable length):
Specifies the value of the parameter.
4.2 TESLA policy
This policy specifies the parameters for TESLA. The types/values
that can be negotiated are defined by the following table. The
concrete default values are taken from [I-D.ietf-msec-srtp-tesla],
but other values may also be used:
Fries & Tschofenig Expires November 24, 2005 [Page 6]
Internet-Draft Bootstrapping TESLA May 2005
Type | Meaning | Possible values
---------------------------------------------------------------
1 | PRF identifier for f, realising F(x) | see below
2 | Length of PRF f output | 160
3 | PRF identifier for f', realising F'(x) | see below
4 | Length of PRF f' output | 160
5 | Identifier for the TESLA MAC | see below
6 | Length of TESLA MAC output | 80 (trunkened)
7 | Start of session | in bytes
8 | Interval duration (in msec) | in bytes
9 | Key disclosure delay | in bytes
10| Key chain length (numer of intervals) | in bytes
11| local timestamp media receiver | see below
For the PRF realising F(x), a one byte length is sufficient.
The currently defined possible values are:
TESLA PRF F(x) | Value
-----------------------
HMAC-SHA1 | 0
For the PRF realising F'(x), a one byte length is enough.
The currently defined possible values are:
TESLA PRF F'(x) | Value
-----------------------
HMAC-SHA1 | 0
For the TESLA MAC, a one byte length is enough.
The currently defined possible values are:
TESLA MAC | Value
-----------------------
HMAC-SHA1 | 0
4.3 Time synchronization
MIKEY as well as TESLA require the time synchronization of the
communicating peers. MIKEY requires time sychronization to provide
timestamp based replay protection for the one-roundtrip
authentication and key exchange protocols. TESLA, on the other hand,
needs this information to determine the clock drift between the
senders and the receivers in order to appropriately release the
disclosed key. Two alternatives are available for time
Fries & Tschofenig Expires November 24, 2005 [Page 7]
Internet-Draft Bootstrapping TESLA May 2005
synchronization:
1. Usage of out of band synchronization using NTP [RFC1305]. This
approach is already recommended within [RFC3830]. The advantage
of this approach is the option to use the MIKEY key management
variants that perform within a half roundtrip. The disadvantage
is the required time synchronization via an additional protocol.
2. [I-D.ietf-msec-tesla-intro] also sketches a possible inband
synchronization in Section 3.3.1. This approach is shortly
repeated here in the context of MIKEY. Note, that here the
actual TESLA policy payload is transmitted as part of the MIKEY
responder message.
* The data receiver, which would be the MIKEY initiator sets the
local time parameter t_r and sends it as part of the timestamp
payload as described in [RFC3830]. This value t_r needs to be
stored locally.
* Upon receipt of the MIKEY initiator message the data sender
replies with the MIKEY responder message, setting the local
time stamp at data receiver (parameter 11) to the value t_r
received in the MIKEY initiator message and sets his local
time as 64 bit UTC value t_s in the timestamp payload as
described in [RFC3830].
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
* Upon receiving the MIKEY responder message the data receiver
sets D_t = t_s - t_r + S, where S is an estimated bound on the
clock drift throughout the duration of the session.
This approach has the advantage that it does not require an
additional time synchronization protocol. The disadvantage is
the necessity to perform a full MIKEY handshake, to enable
correct parameter transport. Moreover this approach is direction
dependent, as it may only be applied if the media receiver is
also the MIKEY initiator.
Therefore, in scenarios, where the media receiver is also the
MIKEY initiator, alternative 2, piggybacking timestamp
information in MIKEY, MAY be chosen, while in any other case NTP
SHOULD be used (alternative 1).
Fries & Tschofenig Expires November 24, 2005 [Page 8]
Internet-Draft Bootstrapping TESLA May 2005
4.4 Key data transport within MIKEY's General Extension Payload
The General Extensions Payload was defined to allow possible
extensions to MIKEY without the need for defining a completely new
payload each time. This payload can be used in any MIKEY message and
is part of the authenticated/signed data part.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits):
Identifies the payload following this payload.
* Type (8 bits):
Identifies the type of general payload. MIKEY
already defines the Values 0 and 1.
This document introduces a new value (2).
Type | Value | Comments
----------------------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs
TESLA I-Key | 2 | TESLA initial key
* Length (16 bits):
The length in bytes of the Data field.
* Data (variable length):
The general payload data.
5. Security Considerations
The security properties of multi-media data in a multicast
environment depends on a number of building blocks.
SRTP-TESLA [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP
[RFC3711] in order to support TESLA [I-D.ietf-msec-tesla-intro] for
Fries & Tschofenig Expires November 24, 2005 [Page 9]
Internet-Draft Bootstrapping TESLA May 2005
source authentication in multicast scenarios. As such, security
considerations described with TESLA (see [PCST] and [I-D.ietf-msec-
tesla-intro]), the TESLA SRTP mapping [I-D.ietf-msec-srtp-tesla] and
SRTP [RFC3711] itself are relevant in this context.
Furthermore, since this document details bootstrapping of TESLA using
the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the
security considerations of MIKEY are applicable to this document.
As a summary, in order for a multi-media application to support TESLA
the following protocol interactions (in relationship to this draft
are necessary):
o MIKEY [RFC3830] is executed between the desired entities to
perform authentication and a secure distribution of keying
material. In order to subsequently use TESLA the parameters
described in this document are distributed using MIKEY. MIKEY
itself uses another protocol for parameter transport, namely SDP
that might again be used within SIP to setup a session between the
desired entities.
o After the algorithms, parameters and the session keys are
available at the respective communication entities data traffic
protection via SRTP-TESLA [I-D.ietf-msec-srtp-tesla] can be used.
SRTP-TESLA itself applies TESLA to the SRTP protocol and as such
the processing guidelines of TESLA need to be followed.
5.1 MitM Attack
Threat:
The exchange of security related parameters and algorithms without
proper authentication can allow an adversary to perform a man-in-
the-middle attack. The mechanisms described in this document do
not itself provide such an authentication and integrity
protection.
Countermeasures:
Throughout the document it is assumed that the parameter exchange
is secured using another protocol, i.e., the exchange parameters
and algorithms are part of a authentication and key exchange
protocol, namely MIKEY. Source authentication of group and
multicast communication cannot be provided for the data traffic if
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 run
it is not possible to derive the necessary parameters required by
TESLA. MIKEY provides session key establishment. Additionally,
the exchange of parameters and algorithms MUST be authenticated
Fries & Tschofenig Expires November 24, 2005 [Page 10]
Internet-Draft Bootstrapping TESLA May 2005
with the strength necessary in the specific context in which the
protocol is used.
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 is listed. An
adversary might want to modify the list of provided algorithsm to
select the weakes one.
Countermeasures:
The parameter exchange provided in this document MUST be integrity
protected to prevent modification of fields and their values.
This functionality is not provided by mechanisms described in this
document. Instead the capabilities of the underlying
authentication and key exchang protocol (MIKEY) are reused for
this purpose.
5.3 Denial of Service Attack
Threat:
An adversary might want to modify parameters exchange 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 discurpt 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
provide this protection.
5.4 Replay Attack
Fries & Tschofenig Expires November 24, 2005 [Page 11]
Internet-Draft Bootstrapping TESLA May 2005
Threat:
An adversary who is able to eavesdrop 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 as well 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 including the exchange parameters.
5.5 Traffic Analysis
Threat:
An adversary might be able to learn parameters and algorithms, if
located along the signaling path. This information can then later
be used to mount attacks against the end-to-end multi-media
communication. In some high-security and military environments it
might even be desireable not to reveal information about the used
parameters to make it more difficult to launch an attack.
Countermeasures:
Confidentity 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. Please note that 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.
This aspect is described in great detail in the respective TESLA
documents since hash chains represent a core concept of TESLA.
6. IANA Considerations
This document requires an IANA registration for the following
attributes:
Fries & Tschofenig Expires November 24, 2005 [Page 12]
Internet-Draft Bootstrapping TESLA May 2005
Prot Type:
This attribute specifies the protocol type for the security
protocol as described in Section 4.1.
Pseudo-random Function (PRF) used in the TESLA policy:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
MAC Function used in TESLA:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
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 outline in [RFC2434] 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.
IANA needs to register the following attributes and their respective
values:
Prot Type:
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
PRF:
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
Fries & Tschofenig Expires November 24, 2005 [Page 13]
Internet-Draft Bootstrapping TESLA May 2005
MAC:
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
Type:
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The values of 0 and 1 are already registered.
7. Acknowledgments
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 for his document reviews.
8. References
8.1 Normative References
[I-D.ietf-msec-srtp-tesla]
Baugher, M., "The Use of TESLA in SRTP",
draft-ietf-msec-srtp-tesla-03 (work in progress),
February 2005.
[I-D.ietf-msec-tesla-intro]
Perrig, A., Canetti, R., Song, D., Tygar, D., and B.
Briscoe, "TESLA: Multicast Source Authentication Transform
Introduction", draft-ietf-msec-tesla-intro-04 (work in
progress), December 2004.
[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,
Fries & Tschofenig Expires November 24, 2005 [Page 14]
Internet-Draft Bootstrapping TESLA May 2005
August 2004.
8.2 Informative References
[I-D.ietf-msec-mikey-dhhmac]
Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", draft-ietf-msec-mikey-dhhmac-11 (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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
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
Fries & Tschofenig Expires November 24, 2005 [Page 15]
Internet-Draft Bootstrapping TESLA May 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fries & Tschofenig Expires November 24, 2005 [Page 16]
