RFC 4851
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
8. Acknowledgements
The EAP-FAST design and protocol specification is based on the ideas and hard efforts of Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc. The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, and Simon Josefsson. Helpful review comments were provided by Russ Housley, Jari Arkko, Bernard Aboba, Ilan Frenkel, and Jeremy Steiglitz.9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006.
9.2. Informative References
[EAP-PROV] Cam-Winget, N., "Dynamic Provisioning using EAP- FAST", Work in Progress, January 2007. [IEEE.802-1X.2004] "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004. [NIST.SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006.
Appendix A. Examples
In the following examples the version field in EAP Fast is always assumed to be 1. The S, M, and L bits are assumed to be 0 unless otherwise specified.A.1. Successful Authentication
The following exchanges show a successful EAP-FAST authentication with optional PAC refreshment; the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque in SessionTicket extension)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/EAP-FAST (TLS change_cipher_spec, TLS finished) -> TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST) <- EAP Payload TLV (EAP-Request/EAP-GTC(Challenge)) EAP Payload TLV (EAP-Response/ EAP-GTC(Response with both user name and password)) -> optional additional exchanges (new pin mode, password change etc.) ...
<- Intermediate-Result TLV (Success)
Crypto-Binding TLV (Request)
Intermediate-Result TLV (Success)
Crypto-Binding TLV(Response) ->
<- Result TLV (Success)
[Optional PAC TLV]
Result TLV (Success)
[PAC TLV Acknowledgment] ->
TLS channel torn down
(messages sent in clear text)
<- EAP-Success
A.2. Failed Authentication
The following exchanges show a failed EAP-FAST authentication due to
wrong user credentials; the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/EAP-FAST
(TLS change_cipher_spec,
TLS finished) ->
TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
<- EAP Payload TLV (EAP-Request/
EAP-GTC (Challenge))
EAP Payload TLV (EAP-Response/
EAP-GTC (Response with both
user name and password)) ->
<- EAP Payload TLV (EAP-Request/
EAP-GTC (error message))
EAP Payload TLV (EAP-Response/
EAP-GTC (empty data packet to
acknowledge unrecoverable error)) ->
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in clear text)
<- EAP-Failure
A.3. Full TLS Handshake using Certificate-based Ciphersuite
In the case where an abbreviated TLS handshake is tried and failed,
and a fallback to certificate-based full TLS handshake occurs within
EAP-FAST Phase 1, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello
with PAC-Opaque extension)->
// Peer sends PAC-Opaque of Tunnel PAC along with a list of
ciphersuites supported. If the server rejects the PAC-
Opaque, it falls through to the full TLS handshake
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity (MyID2))->
// identity protected by TLS.
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-Success
A.4. Client Authentication during Phase 1 with Identity Privacy
In the case where a certificate-based TLS handshake occurs within
EAP-FAST Phase 1, and client certificate authentication and identity
privacy is desired, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,TLS Hello-Request)
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// TLS Hello-Request is piggybacked to the TLS Finished as
Handshake Data and protected by the TLS tunnel
// Subsequent messages are protected by the TLS Tunnel
EAP-Response/EAP-FAST
(TLS client_hello) ->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
Result TLV (Success))
EAP-Response/EAP-FAST
(Result-TLV (Success)) ->
//TLS channel torn down
(messages sent in clear text)
<- EAP-Success
A.5. Fragmentation and Reassembly
In the case where EAP-FAST fragmentation is required, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (L=1,M=1, TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,]) EAP-Response/EAP-FAST -> <- EAP-Request/EAP-FAST (M=1, [TLS certificate_request(con't),]) EAP-Response/EAP-FAST -> <- EAP-Request/EAP-FAST ([TLS certificate_request(con't),] TLS server_hello_done) EAP-Response/EAP-FAST, (L=1,M=1,[TLS certificate,])-> <- EAP-Request/EAP-FAST EAP-Response/EAP-FAST ([TLS certificate(con't),] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished))-> <- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity (MyID2))->
// identity protected by TLS.
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-Success
A.6. Sequence of EAP Methods
Where EAP-FAST is negotiated, with a sequence of EAP method X
followed by method Y, the conversation will occur as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Optional additional X Method exchanges...
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/EAP-Type X)->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP Payload TLV (EAP-Request/Method Y)
// Next EAP conversation started after successful completion
of previous method X. The Intermediate-Result and Crypto-
Binding TLVs are sent in this packet to minimize round-
trips. In this example, identity request is not sent
before negotiating EAP-Type=Y.
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP-Payload-TLV (EAP-Response/Method Y) ->
// Optional additional Y Method exchanges...
<- EAP Payload TLV
(EAP-Request/Method Y)
EAP Payload TLV
(EAP-Response/Method Y) ->
<- Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// Compound MAC calculated using Keys generated from EAP
methods X and Y and the TLS tunnel. Compound Keys
generated using Keys generated from EAP methods X and Y;
and the TLS tunnel.
// TLS channel torn down (messages sent in clear text)
<- EAP-Success
A.7. Failed Crypto-Binding
The following exchanges show a failed crypto-binding validation. The
conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/EAP-FAST
(TLS Server Key Exchange,
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange,
TLS change_cipher_spec,
TLS finished)->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished)
EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Challenge))
EAP Payload TLV (EAP-Response/
EAP-MSCHAPV2 (Response)) ->
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Success Request))
EAP Payload TLV (EAP-Response/
EAP-MSCHAPV2 (Success Response)) ->
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Result TLV (Failure),
Error TLV (Error Code = 2001) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-Failure
A.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
Where EAP-FAST is negotiated, with a sequence of EAP method followed
by Vendor-Specific TLV exchange, the conversation will occur as
follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X)->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
Vendor-Specific TLV
// Vendor Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor Specific TLV
in this packet to minimize round-trips.
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Vendor-Specific TLV ->
// Optional additional Vendor-Specific TLV exchanges...
<- Vendor-Specific TLV
Vendor Specific TLV ->
<- Result TLV (Success)
Result-TLV (Success) ->
// TLS channel torn down (messages sent in clear text)
<- EAP-Success
Appendix B. Test Vectors
B.1. Key Derivation
PAC KEY: 0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14 Server_hello Random 3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A Client_hello Random 00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00 Master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", server_random + Client_random, 48) 4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29 38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2 Key_block = PRF(Master_secret, "key expansion", server_random + Client_random) 59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44 11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71 Session Key Seed D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
IMCK = T-PRF(SKS,
"Inner Methods Compound Keys",
ISK,
60)
Note: ISK is 32 octets 0's.
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9
04 D0 69 56 72 8B 6B B8 15 EC 57 7B
[SIMCK 1]
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5
MSK = T-PRF(S-IMCKn,
"Session Key Generating Function",
64);
4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33
C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9
27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49
67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3
EMSK = T-PRF(S-IMCKn,
"Extended Session Key Generating Function",
64);
3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55
EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9
76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A
2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9
B.2. Crypto-Binding MIC
[Compound MAC Key 1] 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 15 EC 57 7B [Crypto-Binding TLV] 80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7 [Server Nonce] D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 [Compound MAC] 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
Authors' Addresses
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US EMail: ncamwing@cisco.com David McGrew Cisco Systems San Jose, CA 95134 US EMail: mcgrew@cisco.com Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US EMail: jsalowey@cisco.com Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US EMail: hzhou@cisco.com
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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.