|
|
|
@ -0,0 +1,505 @@ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Network Working Group Y. Sheffer |
|
|
|
|
Internet-Draft Check Point |
|
|
|
|
Intended status: Informational July 6, 2008 |
|
|
|
|
Expires: January 7, 2009 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Using EAP-GTC for Simple User Authentication in IKEv2 |
|
|
|
|
draft-sheffer-ikev2-gtc-00.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 January 7, 2009. |
|
|
|
|
|
|
|
|
|
Abstract |
|
|
|
|
|
|
|
|
|
Despite many years of effort, simple username-password authentication |
|
|
|
|
is still prevalent. In many cases a password is the only credential |
|
|
|
|
available to the end user. IKEv2 uses EAP as a sub-protocol for user |
|
|
|
|
authentication. This provides a well-specified and extensible |
|
|
|
|
architecture. To this day EAP does not provide a simple password- |
|
|
|
|
based authentication method. The only existing password |
|
|
|
|
authentication methods either require the peer to know the password |
|
|
|
|
in advance (EAP-MD5), or are needlessly complex when used within |
|
|
|
|
IKEv2 (e.g. PEAP). This document codifies the common practice of |
|
|
|
|
using EAP-GTC for this type of authentication, with the goal of |
|
|
|
|
achieving maximum interoperability. The various security issues are |
|
|
|
|
extensively analyzed. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 1] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents |
|
|
|
|
|
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
|
|
|
|
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
|
|
|
|
3. Alternatives to EAP-GTC in IKEv2 . . . . . . . . . . . . . . . 4 |
|
|
|
|
3.1. Non-password credentials . . . . . . . . . . . . . . . . . 4 |
|
|
|
|
3.2. Using the IKE preshared secret . . . . . . . . . . . . . . 4 |
|
|
|
|
3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication |
|
|
|
|
schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
|
|
|
|
4. Using EAP-GTC in IKE: Details . . . . . . . . . . . . . . . . . 5 |
|
|
|
|
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 |
|
|
|
|
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 |
|
|
|
|
6.1. Key generation and MITM protection . . . . . . . . . . . . 6 |
|
|
|
|
6.2. Protection of credentials between the IKE gateway and |
|
|
|
|
the AAA server . . . . . . . . . . . . . . . . . . . . . . 6 |
|
|
|
|
6.3. Server authentication . . . . . . . . . . . . . . . . . . . 6 |
|
|
|
|
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 |
|
|
|
|
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
|
|
|
|
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 |
|
|
|
|
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 |
|
|
|
|
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 |
|
|
|
|
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
|
|
|
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
|
|
|
|
Intellectual Property and Copyright Statements . . . . . . . . . . 9 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 2] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Introduction |
|
|
|
|
|
|
|
|
|
"Oh dear! It's possible that we have added EAP to IKE to support a |
|
|
|
|
case that EAP can't support." -- C. Kaufman. |
|
|
|
|
|
|
|
|
|
Despite many years of effort, simple username-password authentication |
|
|
|
|
is still prevalent. In many cases a password is the only credential |
|
|
|
|
available to the end user. |
|
|
|
|
|
|
|
|
|
IKEv2 [RFC4306] uses the Extensible Authentication Protocol (EAP) as |
|
|
|
|
a sub-protocol for user authentication. This provides a well- |
|
|
|
|
specified and extensible architecture and enables useful capabilities |
|
|
|
|
like SIM authentication. Unfortunately, for a number of reasons EAP |
|
|
|
|
still does not provide a simple password-based authentication method. |
|
|
|
|
The only existing password authentication methods either require the |
|
|
|
|
peer to know the password in advance (EAP-MD5), or are needlessly |
|
|
|
|
complex when used within IKEv2 (e.g. PEAP). |
|
|
|
|
|
|
|
|
|
Technically, the IKE preshared secret authentication mode can be used |
|
|
|
|
for password authentication. In fact even the IKEv2 RFC winks at |
|
|
|
|
this practice. But this use jeopardizes the protocol's security and |
|
|
|
|
should clearly be avoided (more details below). |
|
|
|
|
|
|
|
|
|
EAP is used in IKEv2 at a stage when the remote access gateway has |
|
|
|
|
already been authenticated. At this point the user has a high enough |
|
|
|
|
level of trust to send his or her password to the gateway. Such an |
|
|
|
|
exchange is enabled by the EAP Generic Token Card (GTC) method, which |
|
|
|
|
is a simple text transport between the two EAP peers. To quote |
|
|
|
|
[RFC3748]: |
|
|
|
|
|
|
|
|
|
The EAP GTC method is intended for use with the Token Cards |
|
|
|
|
supporting challenge/response authentication and MUST NOT be used |
|
|
|
|
to provide support for cleartext passwords in the absence of a |
|
|
|
|
protected tunnel with server authentication. |
|
|
|
|
|
|
|
|
|
IKEv2 does indeed provide "a protected tunnel with server |
|
|
|
|
authentication". The current document updates [RFC3748] by making an |
|
|
|
|
exception and allowing the use of GTC to carry secret credentials, in |
|
|
|
|
this specific situation. Section 6 further elaborates on the |
|
|
|
|
security properties of this solution. |
|
|
|
|
|
|
|
|
|
Other protocols provide a similar protected tunnel, for example TLS- |
|
|
|
|
EAP, described in [I-D.nir-tls-eap]. These protocols however are out |
|
|
|
|
of scope for this document. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 3] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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]. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. Alternatives to EAP-GTC in IKEv2 |
|
|
|
|
|
|
|
|
|
This section presents a few of the alternatives to EAP-GTC, and |
|
|
|
|
explains why they are either insecure or impractical given today's |
|
|
|
|
common identity management infrastructure. |
|
|
|
|
|
|
|
|
|
3.1. Non-password credentials |
|
|
|
|
|
|
|
|
|
Certificate-based authentication, especially when combined with |
|
|
|
|
hardware protection (e.g. a hardware token), can be deployed in a |
|
|
|
|
more secure manner than the form of password authentication which we |
|
|
|
|
discuss. However, due to a host of issues to do with cost, |
|
|
|
|
inconvenience and reliability this solution has not gained wide |
|
|
|
|
market acceptance over the last 10 years. |
|
|
|
|
|
|
|
|
|
3.2. Using the IKE preshared secret |
|
|
|
|
|
|
|
|
|
Sec. 2.15 of RFC 4306 points out that the generation of the IKE |
|
|
|
|
preshared secret from a weak password is insecure. Such use is |
|
|
|
|
vulnerable to off line password guessing by an active attacker. All |
|
|
|
|
the attacker needs to do is respond correctly to the first IKE_INIT |
|
|
|
|
message, and then record the third IKE message. This is then |
|
|
|
|
followed by a dictionary attack to obtain the password. |
|
|
|
|
|
|
|
|
|
3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes |
|
|
|
|
|
|
|
|
|
Challenge-response schemes, like EAP-MD5 and EAP-MSCHAPv2, have a |
|
|
|
|
clear security advantage over sending the plaintext password to the |
|
|
|
|
gateway. Password-based mutual authentication schemes like SRP have |
|
|
|
|
a further advantage in that the gateway's authentication is much |
|
|
|
|
stronger than when using certificates alone, since the AAA server |
|
|
|
|
proves its knowledge of a per-client credential, and the gateway |
|
|
|
|
proves that it has been authorized by the AAA server for that |
|
|
|
|
particular client. |
|
|
|
|
|
|
|
|
|
Unfortunately all of these methods also suffer from a major drawback: |
|
|
|
|
the gateway must have a priori access to the plaintext password. |
|
|
|
|
While many RADIUS servers may indeed have such access, other very |
|
|
|
|
common deployments do not provide it. One typical example is when |
|
|
|
|
the gateway directly accesses an LDAP directory (or a Microsoft |
|
|
|
|
Active Directory) to authenticate the user. The usual way to do that |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 4] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
is by issuing an LDAP Bind operation into the directory, using the |
|
|
|
|
just-received plaintext password. Often in this case it is the IKE |
|
|
|
|
gateway that terminates the EAP protocol, and it needs a way to |
|
|
|
|
obtain the raw password. |
|
|
|
|
|
|
|
|
|
An additional issue with mutual authentication schemes is their heavy |
|
|
|
|
IP encumbrance, which has resulted in a scarcity of standards using |
|
|
|
|
them and a low rate of market adoption. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4. Using EAP-GTC in IKE: Details |
|
|
|
|
|
|
|
|
|
EAP-GTC is specified in [RFC3748], Sec. 5.6. This section is non- |
|
|
|
|
normative, and is merely an interpretation of this specification in |
|
|
|
|
the context of IKEv2. |
|
|
|
|
|
|
|
|
|
Simple authentication requires a non secret identity ("user name") |
|
|
|
|
and a secret credential ("password"). Both of these are arbitrary |
|
|
|
|
Unicode strings, although implementations may impose length |
|
|
|
|
constraints. |
|
|
|
|
|
|
|
|
|
In the case of EAP-GTC, the user name is conveyed in the IKE IDi |
|
|
|
|
payload. According to [RFC4718], Sec. 3.4, the user name can be |
|
|
|
|
encoded in one of two ways: as a simple user name, in which case the |
|
|
|
|
ID_KEY_ID identification type is used; or as a combination user name |
|
|
|
|
plus realm, in which case the format is a NAI [RFC4282] and the |
|
|
|
|
identification type is ID_RFC822_ADDR. In either case, the user name |
|
|
|
|
is a Unicode string encoded as UTF-8. Using the EAP Identity payload |
|
|
|
|
is redundant, and if it is used, it should be identical to the IDi |
|
|
|
|
payload. |
|
|
|
|
|
|
|
|
|
EAP-GTC consists of a simple 2-message exchange. The contents of the |
|
|
|
|
Type-Data field in the Request should not be interpreted in any way, |
|
|
|
|
and should be displayed to the user. This field contains a Unicode |
|
|
|
|
string, encoded as UTF-8. |
|
|
|
|
|
|
|
|
|
The password is sent in the EAP Response. The Type-Data field of the |
|
|
|
|
Response is also a Unicode string encoded as UTF-8. Note that none |
|
|
|
|
of the IDi payload, the EAP Request or the EAP Response is null- |
|
|
|
|
terminated. |
|
|
|
|
|
|
|
|
|
If either or both the user name and the password are non-ASCII, they |
|
|
|
|
should be normalized by the IKE client before the IKE/EAP message is |
|
|
|
|
constructed. The normalization method is SASLprep, [RFC4013]. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 5] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. IANA Considerations |
|
|
|
|
|
|
|
|
|
This document does not require any action by IANA. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6. Security Considerations |
|
|
|
|
|
|
|
|
|
6.1. Key generation and MITM protection |
|
|
|
|
|
|
|
|
|
Modern EAP methods generate a key shared between the two protocol |
|
|
|
|
peers. GTC does not (and cannot) generate such a key. RFC 4306 |
|
|
|
|
mandates that: |
|
|
|
|
|
|
|
|
|
EAP methods that do not establish a shared key SHOULD NOT be used, |
|
|
|
|
as they are subject to a number of man-in-the-middle attacks |
|
|
|
|
[EAPMITM] if these EAP methods are used in other protocols that do |
|
|
|
|
not use a server-authenticated tunnel. |
|
|
|
|
|
|
|
|
|
However GTC must never be used in such a situation, since the client |
|
|
|
|
would be sending its credentials openly to an unauthenticated server. |
|
|
|
|
When using GTC with IKEv2, the implementation (or local |
|
|
|
|
administrators) MUST ensure that the same credentials are never used |
|
|
|
|
in such a manner. |
|
|
|
|
|
|
|
|
|
6.2. Protection of credentials between the IKE gateway and the AAA |
|
|
|
|
server |
|
|
|
|
|
|
|
|
|
In the proposed solution, the raw credentials are sent from the IKE |
|
|
|
|
gateway to a AAA server, typically a RADIUS server. These |
|
|
|
|
credentials and the associated messaging MUST be strongly protected. |
|
|
|
|
Some of the existing options include: |
|
|
|
|
o An IPsec tunnel between the gateway and the AAA server. |
|
|
|
|
o RADIUS over TCP with TLS, [I-D.winter-radsec]. |
|
|
|
|
o RADIUS over UDP with DTLS, [I-D.dekok-radext-dtls] (expired). |
|
|
|
|
The legacy RADIUS security mechanism (Sec. 5.2 of [RFC2865]) is |
|
|
|
|
considered weak and SHOULD NOT be used when better alternatives are |
|
|
|
|
available. |
|
|
|
|
|
|
|
|
|
6.3. Server authentication |
|
|
|
|
|
|
|
|
|
The client may only send its cleartext credentials after it has |
|
|
|
|
positively authenticated the server. This authentication is |
|
|
|
|
specified, albeit rather vaguely, in [RFC4306] and is out of scope of |
|
|
|
|
the current document. Unauthenticated (BTNS) derivatives of IKE MUST |
|
|
|
|
NOT be used with EAP-GTC. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 6] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7. Acknowledgments |
|
|
|
|
|
|
|
|
|
I would like to thank Yoav Nir and Charlie Kaufman for their helpful |
|
|
|
|
comments. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. |
|
|
|
|
Levkowetz, "Extensible Authentication Protocol (EAP)", |
|
|
|
|
RFC 3748, June 2004. |
|
|
|
|
|
|
|
|
|
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names |
|
|
|
|
and Passwords", RFC 4013, February 2005. |
|
|
|
|
|
|
|
|
|
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", |
|
|
|
|
RFC 4306, December 2005. |
|
|
|
|
|
|
|
|
|
8.2. Informative References |
|
|
|
|
|
|
|
|
|
[EAPMITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle |
|
|
|
|
in Tunneled Authentication Protocols", November 2002, |
|
|
|
|
<http://eprint.iacr.org/2002/163>. |
|
|
|
|
|
|
|
|
|
[I-D.dekok-radext-dtls] |
|
|
|
|
DeKok, A., "DTLS as a Transport Layer for RADIUS", |
|
|
|
|
draft-dekok-radext-dtls-00 (work in progress), |
|
|
|
|
February 2007. |
|
|
|
|
|
|
|
|
|
[I-D.nir-tls-eap] |
|
|
|
|
Nir, Y., Tschofenig, H., and P. Gutmann, "TLS using EAP |
|
|
|
|
Authentication", draft-nir-tls-eap-03 (work in progress), |
|
|
|
|
April 2008. |
|
|
|
|
|
|
|
|
|
[I-D.winter-radsec] |
|
|
|
|
Winter, S., McCauley, M., and S. Venaas, "RadSec Version 2 |
|
|
|
|
- A Secure and Reliable Transport for the RADIUS |
|
|
|
|
Protocol", draft-winter-radsec-01 (work in progress), |
|
|
|
|
February 2008. |
|
|
|
|
|
|
|
|
|
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, |
|
|
|
|
"Remote Authentication Dial In User Service (RADIUS)", |
|
|
|
|
RFC 2865, June 2000. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 7] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The |
|
|
|
|
Network Access Identifier", RFC 4282, December 2005. |
|
|
|
|
|
|
|
|
|
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and |
|
|
|
|
Implementation Guidelines", RFC 4718, October 2006. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix A. Change Log |
|
|
|
|
|
|
|
|
|
A.1. -00 |
|
|
|
|
|
|
|
|
|
Initial version. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Author's Address |
|
|
|
|
|
|
|
|
|
Yaron Sheffer |
|
|
|
|
Check Point Software Technologies Ltd. |
|
|
|
|
5 Hasolelim St. |
|
|
|
|
Tel Aviv 67897 |
|
|
|
|
Israel |
|
|
|
|
|
|
|
|
|
Email: yaronf@checkpoint.com |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 8] |
|
|
|
|
|
|
|
|
|
Internet-Draft EAP-GTC in IKEv2 July 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Full Copyright Statement |
|
|
|
|
|
|
|
|
|
Copyright (C) The IETF Trust (2008). |
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheffer Expires January 7, 2009 [Page 9] |
|
|
|
|
|
|
|
|
|
|