NSIS H. Tschofenig
Internet-Draft J. Kross
Expires: January 10, 2005 Siemens AG
July 12, 2004
Extended QoS Authorization for the QoS NSLP
draft-tschofenig-nsis-qos-ext-authz-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Proper authorization is essential for a Quality of Service signaling
protocol. Three authorization models have been identified: a
two-party model, a token-based three-party model, and a generic
three-party model
This document discusses two possible solution for the generic
three-party model: a challenge/response based and an EAP-based
approach.
Tschofenig & Kross Expires January 10, 2005 [Page 1]
Internet-Draft Extended QoS NSLP Authorization July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Alternatives . . . . . . . . . . . . . . . . . . . . 6
4.1 Challenge/Response-based Authentication/Authorization . . 6
4.2 EAP-based Authentication/Authorization . . . . . . . . . . 7
5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Challenge/Response-based Authentication/Authorization . . 10
5.2 EAP-based Authentication/Authorization . . . . . . . . . . 10
5.3 Integrity Object . . . . . . . . . . . . . . . . . . . . . 11
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Tschofenig & Kross Expires January 10, 2005 [Page 2]
Internet-Draft Extended QoS NSLP Authorization July 2004
1. Introduction
Three authorization models are described in Section 3.6 of
[I-D.ietf-nsis-qos-nslp]:
o Two party approach
o Token based three party approach
o Generic three party approach
The two party approach is sketched in Section 3.6.1 of
[I-D.ietf-nsis-qos-nslp], the token based three party approach is
described in Section 3.6.2 of [I-D.ietf-nsis-qos-nslp] (based on
[RFC3520] and [RFC3521]), and an overview of the generic three party
approach is provided with Section 3.6.3 of [I-D.ietf-nsis-qos-nslp].
It is obvious that these authorization approaches offer different
security and address different deployment scenarios.
This document focuses on a more detailed discussion of the generic
three party approach. Section 3 provides an overview of the generic
three party approach. Section 4 lists two possible solution
approaches. For completeness, object payloads are described in
Section 5. A short conclusion is given in Section 6.
Tschofenig & Kross Expires January 10, 2005 [Page 3]
Internet-Draft Extended QoS NSLP Authorization July 2004
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 [RFC2119].
Tschofenig & Kross Expires January 10, 2005 [Page 4]
Internet-Draft Extended QoS NSLP Authorization July 2004
3. Overview
This section offers message flows and protocol-specific details about
authorization for QoS reservations for the generic three party
approach.
Figure 1 illustrates a case where an entity A (e.g., an end host)
sends an NSIS QoS signaling message towards an entity B (e.g, a NSIS
aware router). This request cannot be authorized by entity B itself
but is rather forwarded to another entity C. The protocol used
between entity A and entity B is based on NSIS whereas the protocol
used between entity B and entity C is, for example, Diameter. A
proposal for a Diameter QoS application is provided with
[I-D.alfano-aaa-qosprot].
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
| |
QoS | | QoS
authz| |authz
req.| | res.
| |
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 1: Three party approach
In the following, two alternative solution proposals for this model
are shown:
o Challenge/Response-based Authentication and Authorization
o EAP-based Authentication and Authorization
Tschofenig & Kross Expires January 10, 2005 [Page 5]
Internet-Draft Extended QoS NSLP Authorization July 2004
4. Protocol Alternatives
4.1 Challenge/Response-based Authentication/Authorization
Figure 2 shows a message flow for the generic three party approach
with a challenge-response mechanism. In this case, after entity B
asked entity C for authorization of a QoS request, entity C issues a
challenge to entity A, which is passed on by entity B. Entity A
resubmits its QoS request, including a response to the challenge.
This is again forwarded to entity C, which verifies whether entity A
is the one it claims to be, and if so, and after checking for entity
A's authorization to use the resources it requests, either grants or
denies the request.
+--------------------+
| Entity C |
| authenticating / |
| authorizing |
| resource |
| request |
+----+-------------+-+
^ |c ^ |
| |h |R |
| |a |e |
| |l |s | QoS
| |l |p |authz
QoS | |e |o | res.
authz| |n |n |
req.| |g |s |
| |e |e |
QoS | v | v
+-------------+ request +---------+----------+
| Entity |----------------->| Entity B |
| requesting | challenge | performing |
| resource |<-----------------| QoS |
| A | response | reservation |
| +----------------->| |
| |granted / rejected| |
| |<-----------------+ |
+-------------+ +--------------------+
Figure 2: Three party challenge-response based approach
Please note that the QoS NSLP does not explicitly send a successful
response message for the challenge/response protocol after a QoS
reservation request. Instead the successful outcome of the protocol
Tschofenig & Kross Expires January 10, 2005 [Page 6]
Internet-Draft Extended QoS NSLP Authorization July 2004
run is implicated by the successul commitment of the entire QoS
reservation. An unsuccessful outcome of the challenge/response
protocol, however, would be indicated explicitly by a reject message
returned immediately - the error codes still need to be defined in
[I-D.ietf-nsis-qos-nslp].
The properties of this approach are intentionally similar to the
digest-authentication used with SIP (see [RFC3261]). This approach
provides better security properties than a token-based authorization
approach since a stronger liveness check needs to be provided. The
QoS request and the result of the challenge/response authentication
and authorization need to be associated with each other.
Furthermore, it is necessary to bind subsequent refresh messages to
the initial authentication and authorization protocol step. This is
typically accomplished with the establishment of session keys and the
protection of signaling messages between entity A and B.
The necessary steps for the QoS NSLP are the following:
o A challenge/response protocol needs to be defined or selected. A
number of protocols can be reused, including the
digest-authentication approach listed in [RFC3261]. This
authentication and key exchange protocol needs to provide mutual
authentication, replay protection and session key establishment.
It seems to be reasonable to investigate some of the requirements
raised in [I-D.walker-ieee802-req] regarding the selection of such
a protocol.
o Integrity protection needs to be applied to signaling messages
exchanged between the entity A and entity B once a session key is
available.
o Since the authentication and key establishment is executed betwen
entity A and entity C, it is necessary to forward the established
keying material from entity C to entity B (using AAA protocols).
o In some circumstances it might be necessary to combine the
security protection at the NTLP with the security protection at
the NSLP. This can, for example, be accomplished by combining the
session keys of both security protocols as suggested in
[I-D.puthenkulam-eap-binding]. Such a binding is necessary if the
reused challenge/response protocol is also used in other
protocols.
4.2 EAP-based Authentication/Authorization
The Extensible Authentication Protocol (EAP) serves as a container
Tschofenig & Kross Expires January 10, 2005 [Page 7]
Internet-Draft Extended QoS NSLP Authorization July 2004
for EAP methods. EAP methods themselves are authentication and key
exchange protocols. EAP is agnostic with regard to the underlying
protocol carrying the EAP payloads.
The main difference between the EAP-based approach discussed in this
section, and the challenge/response based approach discussed in
Section 4.1 is related to the flexible choice of authentication and
key exchange protocols with EAP on the one hand, and some degree of
inefficiency introduced with EAP (such as the EAP-Request/Identity,
EAP-Response/Identity and EAP-Success messages) on the other hand.
Due to the usage of EAP in IEEE 802.1X and also in PANA, the security
properties have been studied extensively. The discussions in the EAP
keying framework (see [I-D.ietf-eap-keying]) are also applicable.
Please note that EAP is not necessarily a three party protocol - EAP
also supports the two party scenario.
An example message flow is shown in Figure 3 which uses the EAP-AKA
method [I-D.arkko-pppext-eap-aka] for authentication and session key
establishment. Please note that the AAA messages triggered by this
exchange are not shown for editorial reasons.
+---------+ +---------+
| MN | | R1 |
+---------+ +---------+
(a) + <---------------------------------------------> +
| Discovery Request/Response (NTLP) |
| |
(b) | ----------------------------------------------> |
| C-Mode |
| NTLP/NSLP QoS CREATE Req. |
| (EAP-Auth/Authz requested; | Initial
| EAP-Identity) | Setup
| |
(c) | <---------------------------------------------- |
| C-Mode |
| NTLP/NSLP QoS CREATE Resp. |
| (EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC)) |
| (Algorithm/Parameter Negotiation) |
(d) | ----------------------------------------------> |
| C-Mode |
| NTLP/NSLP QoS CREATE Req. |
| (EAP-Response/AKA-Challenge |
| (AT_RES, AT_MAC)) |
| (Algorithm/Parameter Negotiation) |
+~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+
Tschofenig & Kross Expires January 10, 2005 [Page 8]
Internet-Draft Extended QoS NSLP Authorization July 2004
(e) | Authentication Authorization finished |
| Secure channel at the NSLP layer established |
+~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+
(f) | <---------------------------------------------- |
| NTLP/NSLP QoS CREATE Resp. |
| NTLP/NSLP QoS CREATE Req. |
| (EAP-Success) |
| (Secure Confirmation) |
| |
+ +
..........
+ +
| ----------------------------------------------> |
(g) | NTLP/NSLP QoS REFRSH msg | Refresh
| | Msg
| <---------------------------------------------- |
| NTLP/NSLP QoS ACK msg |
+ +
Figure 3: EAP based Auth/Authz exchange using EAP-AKA
The message exchange shown in Figure 3 starts with the optional
discovery of the next QoS NSLP aware node (messages (a)). The first
QoS NSLP message with a resource request is sent with the Network
Access Identity and a request to perform EAP-based authentication
(message (b)). Note that this exchange assumes that the EAP-Request/
Identity and the EAP-Response/Identity exchange is omitted. This
exchange is optional in EAP if the identity can be provided by other
means. Router 1 contacts the AAA infrastructure, and the EAP server
starts the message exchange. The AAA message communication is not
shown. Subsequently, two messages (messages (c) and (d)) are
exchanged between the EAP peer and the EAP server which contain
EAP-AKA specific information. After successful authentication and
authorization, session keys are derived and provided to R1 via AAA
mechanisms (see [I-D.ietf-aaa-eap] and [RFC3579]). These session
keys can then be used to protect subsequent NSLP messages as
indicated by (e). The EAP-Success message can already experience
such a protection (see message (f)). Furthermore, it is useful to
repeat the previously sent objects. Subsequent refresh messages (g)
are protected with the previously established session keys and are
therefore associated with the previous authentication and
authorization protocol execution.
Tschofenig & Kross Expires January 10, 2005 [Page 9]
Internet-Draft Extended QoS NSLP Authorization July 2004
5. Payload Formats
5.1 Challenge/Response-based Authentication/Authorization
For carrying the credentials for the challenge/response-based
authentication and authorization approach within the QoS NSLP, it is
proposed to use a new Policy Element, called CR policy element. Its
format is shown in Figure 4.
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTHZ_CR |
+---------------------------+---------------------------+
| |
// CR Packet (Opaque to QoS NSLP) //
| |
+-------------------------------------------------------+
Figure 4: Format of CR Policy Element
CR Packet: The CR Packet contains the information required for the
Challenge/Response handshake. Further details will be described in a
future version of this document.
5.2 EAP-based Authentication/Authorization
Figure 3 illustrates an example message flow for EAP-based
authentication and authorization. This section proposes how to
integrate the data required for the EAP exchange into the QoS NSLP
message format.
[I-D.ietf-nsis-qos-nslp] describes the generic format for Policy
Elements. It is proposed that the EAP data is carried within a new
Policy Element, called EAP Policy Element. It follows the generic
format of Policy elements as defined in Appendix A.7.3 of
[I-D.ietf-nsis-qos-nslp]. Figure 5 illustrates the specific format.
Tschofenig & Kross Expires January 10, 2005 [Page 10]
Internet-Draft Extended QoS NSLP Authorization July 2004
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTHZ_EAP |
+---------------------------+---------------------------+
| |
// EAP Packet (Opaque to QoS NSLP) //
| |
+-------------------------------------------------------+
Figure 5: Format of EAP Policy Element
EAP Packet: The EAP Packet contains an EAP packet in the format of
[RFC3748], section 4.
5.3 Integrity Object
A future version of this document will describe the payload format of
an Integrity Object.
Tschofenig & Kross Expires January 10, 2005 [Page 11]
Internet-Draft Extended QoS NSLP Authorization July 2004
6. Conclusion
The QoS NSLP has to be provided for the generic three party case in
order to be complete. This document discusses two possible
solutions: the challenge/response and the EAP-based approach
The working group needs to make the following two decisions:
o Should a challenge/response or an EAP-based scheme be developed?
o Should this work be included in the main QoS NSLP
[I-D.ietf-nsis-qos-nslp] document?
There are some technical aspects that need to be addressed, as
explained throughout the text. Hence, the enhancement is more
complex than just adding one new payload to the NSLP. Some security
issues and also non-security issues need to be solved. For example,
EAP itself is only a container and does not provide fragmentation and
reliable transmission of EAP payloads. Carrying EAP within the QoS
NSLP requires further investigations since different transport
protocols have to be supported by GIMPS (see
[I-D.schulzrinne-nsis-ntlp]). These issues have already been
discussed in, for example, PANA [I-D.ietf-pana-pana].
Tschofenig & Kross Expires January 10, 2005 [Page 12]
Internet-Draft Extended QoS NSLP Authorization July 2004
7. Security considerations
Selected security aspects with the challenge/response based approach
have been mentioned in Section 4.1 and with respect to EAP in Section
4.2.
If security protection is provided by GIMPS (which is an
instantiation of the NTLP) and also at the NSLP with the mechanisms
discussed in this document, then the two phases should be combined
since security vulnerabilities are introduced otherwise. For
example, running EAP over TLS for client-side authentication could be
one possibility but it raises issues with the discovered
man-in-the-middle attack problems for tunneled authentication (see
[I-D.puthenkulam-eap-binding]).
There is certainly a tradeoff between the flexibility of EAP and the
simplicity of a challenge/response protocol.
In some scenarios, it is necessary to cope with the 'lying NAS'
problem. With the usage of EAP, it is necessary to provide the EAP
server with enough information to perform the authorization steps.
However, EAP methods themselves are independent of the environment in
which they are executed. Hence, an adversary (acting as an NSIS NSLP
node) could misuse an EAP exchange to create the illusion for the EAP
server that the context is different (e.g., wireless LAN access).
The work in the area [I-D.arkko-eap-service-identity-auth] and
[I-D.mariblanca-aaa-eap-lla] is applicable in this context. The goal
is to give both, the EAP peer and the EAP server, enough assurance
that the Authenticator (i.e., QoS NSLP in this context) is not lying.
It might be worth mentioning that the introduction of COPS in RSVP
(see [RFC2749]) and the usage of POLICY_OBJECT [RFC3182] already
provided a first attempt in offering a generic three party
authorization model. Hence, the problem is not artifical.
Unfortunately, the multiple-roundtrip communication and the AAA
infrastructure was not fully worked out at that time. The
deficiencies in a roaming environment have first been mentioned with
[I-D.thomas-nsis-rsvp-analysis]. A more detailed treatment of the
security properties are provided with
[I-D.ietf-nsis-rsvp-sec-properties].
Tschofenig & Kross Expires January 10, 2005 [Page 13]
Internet-Draft Extended QoS NSLP Authorization July 2004
8. References
8.1 Normative References
[I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03
(work in progress), May 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
8.2 Informative References
[I-D.alfano-aaa-qosprot]
Alfano, F., McCann, P. and H. Tschofenig, "Diameter
Quality of Service Application",
draft-alfano-aaa-qosprot-00 (work in progress), July 2004,
<reference.I-D.alfano-aaa-qosprot.xml>.
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Identities
for the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-00 (work in
progress), April 2004,
<reference.I-D.arkko-eap-service-identity-auth.xml>.
[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication",
draft-arkko-pppext-eap-aka-12 (work in progress), April
2004, <reference.I-D.arkko-pppext-eap-aka.xml>.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-08 (work in progress), June 2004,
<reference.I-D.ietf-aaa-eap.xml>.
[I-D.ietf-eap-keying]
Aboba, B., "EAP Key Management Framework",
Tschofenig & Kross Expires January 10, 2005 [Page 14]
Internet-Draft Extended QoS NSLP Authorization July 2004
draft-ietf-eap-keying-01 (work in progress), October 2003,
<reference.I-D.ietf-eap-keying.xml>.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun,
"A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-02 (work in progress), May
2004.
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-02
(work in progress), May 2004.
[I-D.ietf-nsis-rsvp-sec-properties]
Tschofenig, H. and R. Graveman, "RSVP Security
Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work
in progress), February 2004,
<reference.I-D.ietf-nsis-rsvp-sec-properties.xml>.
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-04 (work in
progress), May 2004, <reference.I-D.ietf-pana-pana.xml>.
[I-D.mariblanca-aaa-eap-lla]
Mariblanca, D., "EAP lower layer attributes for AAA
protocols", draft-mariblanca-aaa-eap-lla-01 (work in
progress), June 2004,
<reference.I-D.mariblanca-aaa-eap-lla.xml>.
[I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003,
<reference.I-D.puthenkulam-eap-binding.xml>.
[I-D.schulzrinne-nsis-ntlp]
Schulzrinne, H., "GIMPS: General Internet Messaging
Protocol for Signaling", draft-schulzrinne-nsis-ntlp-00
(work in progress), June 2003,
<reference.I-D.schulzrinne-nsis-ntlp.xml>.
[I-D.thomas-nsis-rsvp-analysis]
Thomas, M., "Analysis of Mobile IP and RSVP Interactions",
draft-thomas-nsis-rsvp-analysis-00 (work in progress),
November 2002,
Tschofenig & Kross Expires January 10, 2005 [Page 15]
Internet-Draft Extended QoS NSLP Authorization July 2004
<reference.I-D.thomas-nsis-rsvp-analysis.xml>.
[I-D.walker-ieee802-req]
Stanley, D., "EAP Method Requirements for Wireless LANs",
draft-walker-ieee802-req-01 (work in progress), May 2004,
<reference.I-D.walker-ieee802-req.xml>.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
and A. Sastry, "COPS usage for RSVP", RFC 2749, January
2000, <reference.RFC.2749.xml>.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001, <reference.RFC.3182.xml>.
[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,
<reference.RFC.3261.xml>.
[RFC3520] Hamer, L., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003.
Authors' Addresses
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Joachim Kross
Siemens AG
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Tschofenig & Kross Expires January 10, 2005 [Page 16]
Internet-Draft Extended QoS NSLP Authorization July 2004
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 (2004). 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.
Tschofenig & Kross Expires January 10, 2005 [Page 17]