idnits 2.17.1 draft-funk-eap-ttls-v1-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1098. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1104), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2685' is mentioned on line 590, but not defined == Missing Reference: 'RFC3748' is mentioned on line 889, but not defined == Unused Reference: 'RFC1700' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'RFC2548' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'RFC1994' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'RFC2759' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'EAP-PEAP' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'TLS-PSK' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'KEYING' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'IKEv2' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'AAA-EAP' is defined on line 1067, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2548 ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Downref: Normative reference to an Informational RFC: RFC 3579 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 == Outdated reference: A later version (-09) exists of draft-ietf-tls-psk-01 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-16 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-03 Summary: 17 errors (**), 0 flaws (~~), 23 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Paul Funk 3 Internet-Draft Juniper Networks 4 Category: Standards Track Simon Blake-Wilson 5 Basic Commerce & 6 Industries, Inc. 7 March 2006 9 EAP Tunneled TLS Authentication Protocol Version 1 10 (EAP-TTLSv1) 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). All Rights Reserved. 39 Abstract 41 EAP-TTLS is an EAP type that utilizes TLS to establish a secure 42 connection between a client and server, through which additional 43 information may be exchanged. The initial TLS handshake may mutually 44 authenticate client and server; or it may perform a one-way 45 authentication, in which only the server is authenticated to the 46 client. The secure connection established by the initial handshake 47 may then be used to allow the server to authenticate the client 48 using existing, widely-deployed authentication infrastructures such 49 as RADIUS. The authentication of the client may itself be EAP, or it 50 may be another authentication protocol such as PAP, CHAP, MS-CHAP or 51 MS-CHAP-V2. 53 Thus, EAP-TTLS allows legacy password-based authentication protocols 54 to be used against existing authentication databases, while 55 protecting the security of these legacy protocols against 56 eavesdropping, man-in-the-middle and other cryptographic attacks. 58 EAP-TTLS also allows client and server to exchange other information 59 in addition to authentication-related information. 61 This document describes EAP-TTLSv1; that is, version 1 of the EAP- 62 TTLS protocol. It represents a significant enhancement to the 63 original version 0 of the protocol. EAP-TTLSv1 utilizes an extended 64 version of TLS, called TLS/IA (TLS/InnerApplication) as its 65 underlying protocol [TLS/IA]. 67 Table of Contents 69 1. Introduction......................................................3 70 1.1 EAP-TTLSv1....................................................3 71 1.2 Differences From Version 0....................................4 72 2. Motivation........................................................5 73 3. Terminology.......................................................6 74 4. Architectural Model...............................................9 75 4.1 Carrier Protocols.............................................9 76 4.2 Security Relationships.......................................10 77 4.3 Messaging....................................................10 78 4.4 Resulting Security...........................................11 79 5. Protocol Layering Model..........................................11 80 6. EAP-TTLSv1 Overview..............................................12 81 6.1 Session Resumption...........................................13 82 6.1.1 TTLS Server Guidelines for Session Resumption............14 83 7. Generating Keying Material.......................................15 84 8. EAP-TTLSv1 Protocol..............................................15 85 8.1 Packet Format................................................15 86 8.2 EAP-TTLS Start Packet........................................17 87 8.2.1 Version Negotiation......................................17 88 8.2.2 Fragmentation............................................17 89 8.2.3 Acknowledgement Packets..................................18 90 9. Security Claims..................................................18 91 10. Security Considerations..........................................19 92 11. References.......................................................20 93 11.1 Normative References.........................................20 94 11.2 Informative References.......................................21 95 12. Authors' Addresses...............................................22 96 1. Introduction 98 EAP-TTLS is an EAP type that utilizes TLS to establish a secure 99 connection between a client and server, through which additional 100 information may be exchanged. The initial TLS handshake may mutually 101 authenticate client and server; or it may perform a one-way 102 authentication, in which only the server is authenticated to the 103 client. The secure connection established by the initial handshake 104 may then be used to allow the server to authenticate the client 105 using existing, widely-deployed authentication infrastructures such 106 as RADIUS. The authentication of the client may itself be EAP, or it 107 may be another authentication protocol such as PAP, CHAP, MS-CHAP or 108 MS-CHAP-V2. 110 Thus, EAP-TTLS allows legacy password-based authentication protocols 111 to be used against existing authentication databases, while 112 protecting the security of these legacy protocols against 113 eavesdropping, man-in-the-middle and other cryptographic attacks. 115 EAP-TTLS also allows client and server to establish keying material 116 for use in the data connection between the client and access point. 117 The keying material is established implicitly between client and 118 server based on the TLS handshake. 120 This document describes EAP-TTLSv1; that is, version 1 of the EAP- 121 TTLS protocol. It represents a significant enhancement to the 122 original version 0 of the protocol. (EAP-TTLSv0). 124 1.1 EAP-TTLSv1 126 EAP-TTLSv1 utilizes TLS with the Inner Application extension 127 (TLS/IA), as its underlying protocol. In TLS/IA, the TLS handshake 128 is followed by an exchange of messages with record type 129 InnerApplication, in which an arbirary exchange of messages between 130 client and server is conducted under the confidentiality and 131 integrity protection afforded by the TLS handshake. 133 The InnerApplication messages that are exchanged between client and 134 server are encoded as sequences of Attribute-Value-Pairs (AVPs) from 135 the RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 136 provides natural compatibility between TLS/IA applications and 137 widely deployed AAA infrastructures. This namespace is extensible, 138 allowing new AVPs and, thus, new applications to be defined as 139 needed, either by standards bodies or by vendors wishing to define 140 proprietary applications. 142 The AVPs exchanged between client and server typically provide for 143 client authentication, or mutual client-server authentication. 144 However, the AVP exchange accommodates any type of client-server 145 exchange, not just authentication, though authentication may often 146 be the prerequisite that allows other exchanges to proceed. For 147 example, EAP-TTLSv1 may be used to verify endpoint integrity, 148 provision keying material for use in separate data channel 149 communications (e.g. IPsec), provide client credentials for single 150 sign-on, and so on. 152 1.2 Differences From Version 0 154 Version 1 of EAP-TTLS is similar to version 0 in that a TLS 155 handshake is used to protect a subsequent AVP exchange. In version 156 0, the handshake portion of TLS is used to establish a tunnel and 157 the data portion is used to carry AVPs. This approach is similar to 158 that of other tunneled protocols, such as EAP-PEAP and EAP-FAST. 160 In version 1, an extension to TLS, called TLS/IA, is utilized; 161 TLS/IA already provides for a protected AVP exchange following the 162 TLS handshake, in effect producing an "extended" handshake. TLS/IA 163 was developed to allow authentication and other client-server 164 negotiations to occur within TLS itself. Thus, TLS/IA is suitable 165 both as the underlying protocol for EAP methods as well as a means 166 of introducing authentication and other client-server exchanges when 167 TLS is used to protect data communications such as an HTTP 168 conversation. 170 Use of TLS/IA in version 1 of EAP-TTLS provides several improvements 171 over verion 0: 173 - Inner authentications are confirmed by mixing session keys 174 developed from those authentications with the master secret 175 developed during the TLS handshake. This guarantees that the TLS 176 handshake endpoint and the authentication endpoint are one and 177 the same, thus eliminating the Man-in-the-Middle (MitM) attack 178 against tunneled protocols for inner authentications that 179 generate session keys. See [MITM] for information about this 180 attack. 182 - Session keys developed from inner authentications are mixed with 183 the TLS master secret to produce an "inner secret", which is 184 exported by TLS/IA. The inner secret is used to generate the MSK 185 (master session key) exported by EAP-TTLSv1 for use in the 186 subsequent data connection. Use of a session key that is bound to 187 inner session keys guarantees that the subsequent data connection 188 wll not operate except with the authentic client, even if the 189 original TLS master secret were compromised and available to an 190 eavesdropper. 192 - TLS/IA's multi-phase operation allows a subsequent phase to 193 confirm the results of prior phases before proceeding. 195 - A secure final exchange of the result of inner authentication is 196 exchanged between client and server to conclude the EAP-TTLSv1 197 exchange. This precludes any possibility of truncation attack 198 that could occur when the client relies solely on an unprotected 199 EAP-Success message to determine that the server has completed 200 its authentication. 202 2. Motivation 204 Most password-based protocols in use today rely on a hash of the 205 password with a random challenge. Thus, the server issues a 206 challenge, the client hashes that challenge with the password and 207 forwards a response to the server, and the server validates that 208 response against the user's password retrieved from its database. 209 This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- 210 Challenge and EAP/One-Time Password. 212 An issue with such an approach is that an eavesdropper that observes 213 both challenge and response may be able to mount a dictionary 214 attack, in which random passwords are tested against the known 215 challenge to attempt to find one which results in the known 216 response. Because passwords typically have low entropy, such attacks 217 can in practice easily discover many passwords. 219 While this vulnerability has long been understood, it has not been 220 of great concern in environments where eavesdropping attacks are 221 unlikely in practice. For example, users with wired or dial-up 222 connections to their service providers have not been concerned that 223 such connections may be monitored. Users have also been willing to 224 entrust their passwords to their service providers, or at least to 225 allow their service providers to view challenges and hashed 226 responses which are then forwarded to their home authentication 227 servers using, for example, proxy RADIUS, without fear that the 228 service provider will mount dictionary attacks on the observed 229 credentials. Because a user typically has a relationship with a 230 single service provider, such trust is entirely manageable. 232 With the advent of wireless connectivity, however, the situation 233 changes dramatically: 235 - Wireless connections are considerably more susceptible to 236 eavesdropping and man-in-the-middle attacks. These attacks may 237 enable dictionary attacks against low-entropy passwords. In 238 addition, they may enable channel hijacking, in which an attacker 239 gains fraudulent access by seizing control of the communications 240 channel after authentication is complete. 242 - Existing authentication protocols often begin by exchanging the 243 client�s username in the clear. In the context of eavesdropping 244 on the wireless channel, this can compromise the client�s 245 anonymity and locational privacy. 247 - Often in wireless networks, the access point does not reside in 248 the administrative domain of the service provider with which the 249 user has a relationship. For example, the access point may reside 250 in an airport, coffee shop, or hotel in order to provide public 251 access via 802.11. Even if password authentications are protected 252 in the wireless leg, they may still be susceptible to 253 eavesdropping within the untrusted wired network of the access 254 point. 256 - In the traditional wired world, the user typically intentionally 257 connects with a particular service provider by dialing an 258 associated phone number; that service provider may be required to 259 route an authentication to the user's home domain. In a wireless 260 network, however, the user does not get to choose an access 261 domain, and must connect with whichever access point is nearby; 262 providing for the routing of the authentication from an arbitrary 263 access point to the user's home domain may pose a challenge. 265 Thus, the authentication requirements for a wireless environment 266 that EAP-TTLS attempts to address can be summarized as follows: 268 - Legacy password protocols must be supported, to allow easy 269 deployment against existing authentication databases. 271 - Password-based information must not be observable in the 272 communications channel between the client node and a trusted 273 service provider, to protect the user against dictionary attacks. 275 - The user's identity must not be observable in the communications 276 channel between the client node and a trusted service provider, 277 to protect the user's locational privacy against surveillance, 278 undesired acquisition of marketing information, and the like. 280 - The authentication process must result in the distribution of 281 shared keying information to the client and access point to 282 permit encryption and validation of the wireless data connection 283 subsequent to authentication, to secure it against eavesdroppers 284 and prevent channel hijacking. 286 - The authentication mechanism must support roaming among small 287 access domains with which the user has no relationship and which 288 will have limited capabilities for routing authentication 289 requests. 291 3. Terminology 293 AAA 295 Authentication, Authorization and Accounting - functions that are 296 generally required to control access to a network and support 297 billing and auditing. 299 AAA protocol 300 A network protocol used to communicate with AAA servers; examples 301 include RADIUS and Diameter. 303 AAA server 305 A server which performs one or more AAA functions: authenticating 306 a user prior to granting network service, providing authorization 307 (policy) information governing the type of network service the 308 user is to be granted, and accumulating accounting information 309 about actual usage. 311 AAA/H 313 A AAA server in the user's home domain, where authentication and 314 authorization for that user are administered. 316 access point 318 A network device providing users with a point of entry into the 319 network, and which may enforce access control and policy based on 320 information returned by a AAA server. For the purposes of this 321 document, "access point" and "NAS" are architecturally 322 equivalent. "Access point" is used throughout because it is 323 suggestive of devices used for wireless access; "NAS" is used 324 when more traditional forms of access, such as dial-up, are 325 discussed. 327 access domain 329 The domain, including access points and other devices, that 330 provides users with an initial point of entry into the network; 331 for example, a wireless hot spot. 333 client 335 A host or device that connects to a network through an access 336 point. 338 domain 340 A network and associated devices that are under the 341 administrative control of an entity such as a service provider or 342 the user's home organization. 344 link layer protocol 346 A protocol used to carry data between hosts that are connected 347 within a single network segment; examples include PPP and 348 Ethernet. 350 NAI 351 A Network Access Identifier [RFC2486], normally consisting of the 352 name of the user and, optionally, the user's home realm. 354 NAS 356 A network device providing users with a point of entry into the 357 network, and which may enforce access control and policy based on 358 information returned by a AAA server. For the purposes of this 359 document, "access point" and "NAS" are architecturally 360 equivalent. "Access point" is used throughout because it is 361 suggestive of devices used for wireless access; "NAS" is used 362 when more traditional forms of access, such as dial-up, are 363 discussed. 365 proxy 367 A server that is able to route AAA transactions to the 368 appropriate AAA server, possibly in another domain, typically 369 based on the realm portion of an NAI. 371 realm 373 The optional part of an NAI indicating the domain to which a AAA 374 transaction is to be routed, normally the user's home domain. 376 service provider 378 An organization with which a user has a business relationship, 379 that provides network or other services. The service provider may 380 provide the access equipment with which the user connects, may 381 perform authentication or other AAA functions, may proxy AAA 382 transactions to the user's home domain, etc. 384 TTLS server 386 A AAA server which implements EAP-TTLS. This server may also be 387 capable of performing user authentication, or it may proxy the 388 user authentication to a AAA/H. 390 user 392 The person operating the client device. Though the line is often 393 blurred, "user" is intended to refer to the human being who 394 possesses an identity (username), password or other 395 authenticating information, and "client" is intended to refer to 396 the device which makes use of this information to negotiate 397 network access. There may also be clients with no human 398 operators; in this case the term "user" is a convenient 399 abstraction. 401 4. Architectural Model 403 The network architectural model for EAP-TTLS usage and the type of 404 security it provides is shown below. 406 +----------+ +----------+ +----------+ +----------+ 407 | | | | | | | | 408 | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H | 409 | | | point | | server | | server | 410 | | | | | | | | 411 +----------+ +----------+ +----------+ +----------+ 413 <---- secure password authentication tunnel ---> 415 <---- secure data tunnel ----> 417 The entities depicted above are logical entities and may or may not 418 correspond to separate network components. For example, the TTLS 419 server and AAA/H server might be a single entity; the access point 420 and TTLS server might be a single entity; or, indeed, the functions 421 of the access point, TTLS server and AAA/H server might be combined 422 into a single physical device. The above diagram illustrates the 423 division of labor among entities in a general manner and shows how a 424 distributed system might be constructed; however, actual systems 425 might be realized more simply. 427 Note also that one or more AAA proxy servers might be deployed 428 between access point and TTLS server, or between TTLS server and 429 AAA/H server. Such proxies typically perform aggregation or are 430 required for realm-based message routing. However, such servers play 431 no direct role in EAP-TTLS and are therefore not shown. 433 4.1 Carrier Protocols 435 The entities shown above communicate with each other using carrier 436 protocols capable of encapsulating EAP. The client and access point 437 communicate using a link layer carrier protocol such as PPP or 438 EAPOL. The access point, TTLS server and AAA/H server communicate 439 using a AAA carrier protocol such as RADIUS or Diameter. 441 EAP, and therefore EAP-TTLS, must be initiated via the link layer 442 protocol. In PPP or EAPOL, for example, EAP is initiated when the 443 access point sends an EAP-Request/Identity packet to the client. 445 The keying material used to encrypt and authenticate the data 446 connection between the client and access point is developed 447 implicitly between the client and TTLS server as a result of EAP- 448 TTLS negotiation. This keying material must be communicated to the 449 access point by the TTLS server using the AAA carrier protocol. 451 The client and access point must also agree on an 452 encryption/validation algorithm to be used based on the keying 453 material. In some systems, both these devices may be preconfigured 454 with this information, and distribution of the keying material alone 455 is sufficient. Or, the link layer protocol may provide a mechanism 456 for client and access point to negotiate an algorithm. 458 In the most general case, however, it may be necessary for both 459 client and access point to communicate their algorithm preferences 460 to the TTLS server, and for the TTLS server to select one and 461 communicate its choice to both parties. This information would be 462 transported between access point and TTLS server via the AAA 463 protocol, and between client and TTLS server via EAP-TTLS in 464 encrypted form. 466 4.2 Security Relationships 468 The client and access point have no pre-existing security 469 relationship. 471 The access point, TTLS server and AAA/H server are each assumed to 472 have a pre-existing security association with the adjacent entity 473 with which it communicates. With RADIUS, for example, this is 474 achieved using shared secrets. It is essential for such security 475 relationships to permit secure key distribution. 477 The client and AAA/H server have a security relationship based on 478 the user's credentials such as a password. 480 The client and TTLS server may have a one-way security relationship 481 based on the TTLS server's possession of a private key guaranteed by 482 a CA certificate which the user trusts, or may have a mutual 483 security relationship based on certificates for both parties. 485 4.3 Messaging 487 The client and access point initiate an EAP conversation to 488 negotiate the client's access to the network. Typically, the access 489 point issues an EAP-Request/Identity to the client, which responds 490 with an EAP-Response/Identity. Note that the client does not include 491 the user's actual identity in this EAP-Response/Identity packet; the 492 user's identity will not be transmitted until an encrypted channel 493 has been established. 495 The access point now acts as a passthrough device, allowing the TTLS 496 server to negotiate EAP-TTLS with the client directly. 498 During the first phase of the negotiation, the TLS handshake 499 protocol is used to authenticate the TTLS server to the client and, 500 optionally, to authenticate the client to the TTLS server, based on 501 public/private key certificates. As a result of the handshake, 502 client and TTLS server now have shared keying material and an agreed 503 upon TLS record layer cipher suite with which to secure subsequent 504 EAP-TTLS communication. 506 During the second phase of negotiation, client and TTLS server use 507 the secure TLS record layer channel established by the TLS handshake 508 as a tunnel to exchange information encapsulated in attribute-value 509 pairs, to perform additional functions such as client authentication 510 and key distribution for the subsequent data connection. 512 If a tunneled client authentication is performed, the TTLS server 513 de-tunnels and forwards the authentication information to the AAA/H. 514 If the AAA/H performs a challenge, the TTLS server tunnels the 515 challenge information to the client. The AAA/H server may be a 516 legacy device and needs to know nothing about EAP-TTLS; it only 517 needs to be able to authenticate the client based on commonly used 518 authentication protocols. 520 Keying material for the subsequent data connection between client 521 and access point may be generated based on secret information 522 developed during the TLS handshake and subsequent tunneled 523 authentications between client and TTLS server. At the conclusion of 524 a successful authentication, the TTLS server may transmit this 525 keying material to the access point, encrypted based on the existing 526 security associations between those devices (e.g., RADIUS). 528 The client and access point now share keying material which they can 529 use to encrypt data traffic between them. 531 In EAP-TTLSv1, the AVP exchange during the second phase is performed 532 using InnerApplication records via the TLS/IA protocol. This AVP 533 exchange itself may be be multi-phase, with each phase proceeding 534 only if the prior phase resulted in success. 536 4.4 Resulting Security 538 As the diagram above indicates, EAP-TTLS allows user identity and 539 password information to be securely transmitted between client and 540 TTLS server, and performs key distribution to allow network data 541 subsequent to authentication to be securely transmitted between 542 client and access point. 544 5. Protocol Layering Model 546 EAP-TTLSv1 packets are encapsulated within EAP, and EAP in turn 547 requires a carrier protocol to transport it. EAP-TTLSv1 packets 548 themselves encapsulate TLS/IA, which is then used to encapsulate 549 user authentication information. TLS/IA, as an extension to TLS, can 550 be considered encapsulated by TLS. Thus, EAP-TTLSv1 messaging can be 551 described using a layered model, where each layer is encapsulated by 552 the layer beneath it. The following diagram clarifies the 553 relationship between protocols: 555 +--------------------------------------------------------+ 556 | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)| 557 +--------------------------------------------------------+ 558 | Inner Application extension to TLS | 559 +--------------------------------------------------------+ 560 | TLS | 561 +--------------------------------------------------------+ 562 | EAP-TTLS | 563 +--------------------------------------------------------+ 564 | EAP | 565 +--------------------------------------------------------+ 566 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 567 +--------------------------------------------------------+ 569 When the user authentication protocol is itself EAP, the layering is 570 as follows: 572 +--------------------------------------------------------+ 573 | User EAP Authentication Protocol (MD-Challenge, etc.) | 574 +--------------------------------------------------------+ 575 | EAP | 576 +--------------------------------------------------------+ 577 | Inner Application extension to TLS | 578 +--------------------------------------------------------+ 579 | TLS | 580 +--------------------------------------------------------+ 581 | EAP-TTLS | 582 +--------------------------------------------------------+ 583 | EAP | 584 +--------------------------------------------------------+ 585 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 586 +--------------------------------------------------------+ 588 Methods for encapsulating EAP within carrier protocols are already 589 defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to 590 transport EAP between client and access point; RADIUS [RFC2685] or 591 Diameter [RFC3588] are used to transport EAP between access point 592 and TTLS server. 594 6. EAP-TTLSv1 Overview 596 EAP-TTLSv1 is initiated by the server's transmission of a Start 597 packet to the client. 599 The EAP exchange proceeds with transmission of TLS/IA message 600 sequences alternately by client and server, with each message 601 sequence encapsulated in an EAP-TTLSv1 frame. Descriptions of the 602 TLS/IA messages can be found in [TLS/IA]. 604 A successful authentication will result in the server sending a 605 TLS/IA FinalPhaseFinished message and the client responding with 606 it's own FinalPhaseFinished message. 608 The server then sends an EAP-Success to the client to complete the 609 authentication. This message is the standard EAP success message and 610 is sent in the clear. 612 Client and server each computes the MSK (the Master Sesion Key, as 613 defined in [RFC3784]), based on information generated in the TLS/IA 614 exchange. The server may then transmit the MSK to the access point 615 for use in its data communications with the client. 617 If the TLS/IA negotiation fails, the server sends an EAP-Failure to 618 the client. 620 6.1 Session Resumption 622 When a client and TTLS server that have previously negotiated a EAP- 623 TTLSv1 session begin a new EAP-TTLSv1 negotiation, the client and 624 TTLS server may agree to resume the previous session. This 625 significantly reduces the time required to establish the new 626 session. This could occur when the client connects to a new access 627 point, or when an access point requires reauthentication of a 628 connected client. 630 Session resumption is accomplished using the standard TLS mechanism. 631 The client signals its desire to resume a session by including the 632 session ID of the session it wishes to resume in the ClientHello 633 message; the TTLS server signals its willingness to resume that 634 session by echoing that session ID in its ServerHello message. 636 If the TTLS server elects not to resume the session, it simply does 637 not echo the session ID and a new session will be negotiated. This 638 could occur if the TTLS server is configured not to resume sessions, 639 if it has not retained the requested session's state, or if the 640 session is considered stale. A TTLS server may consider the session 641 stale based on its own configuration, or based on session-limiting 642 information received from the AAA/H (e.g., the RADIUS Session- 643 Timeout attribute). 645 Addition messages beyond the TLS handshake may or may not occur 646 within a resumed session. TLS/IA provides a negotiation mechanism 647 allowing client and server to determine whether InnerApplication 648 messages are to ensue upon session resumption. Typically, inner 649 authentications would not be required in a resumed session, as the 650 ability to resume the session may provide sufficient evidence to 651 either party of the identity of the other. However, there may be 652 additional information that needs to be refreshed or renegotiated 653 during a session resumption. 655 When an inner authentication is not performed during a resumed 656 session, the TTLS server will not receive new authorization 657 information from the AAA/H. In this case, the TTLS server must 658 retain authorization information initially returned by the AAA/H for 659 use in resumed sessions. Authorization information might include the 660 maximum time for the session, the maximum allowed bandwidth, packet 661 filter information and the like. The TTLS server is responsible for 662 modifying time values, such as Session-Timeout, appropriately for 663 each resumed session. 665 A TTLS server MUST NOT permit a session to be resumed if that 666 session did not result in a successful completion of the entire 667 TLS/IA exchange, and a client MUST NOT propose the session ID of a 668 failed session for resumption. The consequence of incorrectly 669 implementing this aspect of session resumption would be 670 catastrophic; any attacker could easily gain network access by first 671 initiating a session that succeeds in the TLS handshake but fails 672 the inner authentication, and then resuming that session. 674 [Implementation note: Toolkits that implement TLS often cache 675 resumable TLS sessions automatically. Implementers must take care to 676 override such automatic behavior, and prevent sessions from being 677 cached for possible resumption until the user has been positively 678 authenticated.] 680 A TTLS server MUST NOT permit a session negotiated with different 681 tunneled TLS-based EAP protocol to be resumed in an EAP-TTLSv1 682 session, and a client MUST NOT propose the session ID resulting from 683 such a protocol for resumption in EAP-TTLSv1. Note that previous 684 versions of EAP-TTLS are considered different tunneled TLS-based 685 protocols for the purposes of this paragraph. Thus, a session 686 negotiated using EAP-PEAP, EAP-FAST or EAP-TTLSv0 are not candidate 687 sessions for resumption in EAP-TTLSv1. 689 6.1.1 TTLS Server Guidelines for Session Resumption 691 When a domain comprises multiple TTLS servers, a client's attempt to 692 resume a session may fail because each EAP-TTLS negotiation may be 693 routed to a different TTLS server. 695 One strategy to ensure that subsequent EAP-TTLS negotiations are 696 routed to the original TTLS server is for each TTLS server to encode 697 its own identifying information, for example, IP address, in the 698 session IDs that it generates. This would allow any TTLS server 699 receiving a session resumption request to forward the request to the 700 TTLS server that established the original session. 702 7. Generating Keying Material 704 Upon successful conclusion of an EAP-TTLSv1 negotiation, a 64-octet 705 MSK (Master Session Key) is generated and exported for use in 706 securing the data connection between client and access point. 708 The MSK is generated using the TLS PRF function [RFC2246], with 709 inputs consisting of the inner secret exported by TLS/IA, the ASCII- 710 encoded constant string "ttls v1 keying material", the TLS client 711 random, and the TLS server random. The constant string is not null- 712 terminated. The TLS/IA inner secret, rather than the TLS master 713 secret, is used because it binds session keys from inner 714 authentications with the TLS master secret and therefore provides 715 greater security in the (unlikely) case that an adversary is able to 716 compromise the master secret. 718 MSK = PRF(inner_secret, 719 "ttls v1 keying material", 720 SecurityParameters.client_random + 721 SecurityParameters.server_random) [0..63] 723 Note that the order of client_random and server_random for EAP-TTLS 724 is reversed from that of the TLS protocol [RFC2246]. This ordering 725 follows the key derivation method of EAP-TLS [RFC2716]. Altering the 726 order of randoms avoids namespace collisions between constant 727 strings defined for EAP-TTLSv1 and those defined for the TLS 728 protocol. 730 The inner secret used in the PRF MUST be the one generated at the 731 conclusion of the final InnerApplication phase of TLS/IA; the client 732 random and server random MUST be those established during the TLS 733 handshake. Client and TTLS server generate this keying material 734 independently, and the result is guaranteed to be the same for each 735 if the TLS/IA exchange succeeds. 737 The TTLS server distributes this keying material to the access point 738 via the AAA carrier protocol. When RADIUS is the AAA carrier 739 protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes may be used 740 to distribute the first 32 octets and second 32 octets of the MSK, 741 respectively. 743 8. EAP-TTLSv1 Protocol 745 8.1 Packet Format 747 The EAP-TTLSv1 packet format is shown below. The fields are 748 transmitted left to right. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Code | Identifier | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Flags | Message Length 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 Message Length | Data... 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Code 761 1 for request, 2 for response. 763 Identifier 764 The Identifier field is one octet and aids in matching responses 765 with requests. The Identifier field MUST be changed for each 766 request packet and MUST be echoed in each response packet. 768 Length 769 The Length field is two octets and indicates the number of octets 770 in the entire EAP packet, from the Code field through the Data 771 field. 773 Type 774 21 (EAP-TTLS, all versions) 776 Flags 777 0 1 2 3 4 5 6 7 778 +---+---+---+---+---+---+---+---+ 779 | L | M | S | R | R | V | 780 +---+---+---+---+---+---+---+---+ 782 L = Length included 783 M = More fragments 784 S = Start 785 R = Reserved 786 V = Version (001 for EAP-TTLSv1) 788 The L bit is set to indicate the presence of the four octet TLS 789 Message Length field. The M bit indicates that more fragments are 790 to come. The S bit indicates a Start message. The V bit is set to 791 the version of EAP-TTLS, and is set to 001 for EAP-TTLSv1. 793 Message Length 794 The Message Length field is four octets, and is present only if 795 the L bit is set. This field provides the total length of the raw 796 data message sequence prior to fragmentation. 798 Data 799 For all packets other than a Start packet, the Data field 800 consists of the raw TLS message sequence or fragment thereof. For 801 a Start packet, the Data field may optionally contain an AVP 802 sequence. 804 8.2 EAP-TTLS Start Packet 806 The S bit MUST be set on the first packet sent by the server to 807 initiate the EAP-TTLSv1 protocol. It MUST NOT be set on any other 808 packet. 810 This packet MAY contain additional information in the form of AVPs, 811 which may provide useful hints to the client; for example, the 812 server identity may be useful to the client to allow it to pick the 813 correct TLS session ID for session resumption. Each AVP must begin 814 on a 4-octet boundary relative to the first AVP in the sequence. If 815 an AVP is not a multiple of 4 octets, it must be padded with 0s to 816 the next 4-octet boundary. 818 8.2.1 Version Negotiation 820 The version of EAP-TTLS is negotiated in the first exchange between 821 server and client. The server sets the highest version number of 822 EAP-TTLS that it supports in the V field of its Start message (in 823 the case of EAP-TTLS v1, this is 1). In its first EAP message in 824 response, the client sets the V field to the highest version number 825 that it supports that is no higher than the version number offered 826 by the server. If the client version is not acceptable to the 827 server, it sends an EAP-Failure to terminate the EAP session. 828 Otherwise, the version sent by the client is the version of EAP-TTLS 829 that MUST be used, and both server and client set the V field to 830 that version number in all subsequent EAP messages. 832 8.2.2 Fragmentation 834 Each EAP-TTLSv1 message contains a sequence of TLS messages that 835 represent a single leg of a half-duplex conversation. The EAP 836 carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose constraints 837 on the length of of an EAP message. Therefore it may be necessary to 838 fragment an EAP-TTLSv1 message across multiple EAP messages. 840 Each fragment except for the last MUST have the M bit set, to 841 indicate that more data is to follow; the final fragment MUST NOT 842 have the M bit set. 844 If there are multiple fragments, the first fragment MUST have the L 845 bit set and include the length of the entire raw message prior to 846 fragmentation. Fragments other than the first MUST NOT have the L 847 bit set. 849 Upon receipt of a packet with M bit set, the receiver MUST transmit 850 an Acknowledgement packet. The receiver is responsible for 851 reassembly of fragmented packets. 853 8.2.3 Acknowledgement Packets 855 An Acknowledgement packet is an EAP-TTLSv1 packet with no additional 856 data beyond the Flags octet, and with the L, M and S bits of the 857 Flags octet set to 0. (Note, however, that the V field MUST still be 858 set to the appropriate version number.) 860 An Acknowledgement packet is sent for the following purposes: 862 - Fragment Acknowledgement 864 A Fragment Acknowledgement is sent in response to an EAP packet 865 with M bit set. 867 - Error Alert Acknowledgement 869 Either party may at any time send a TLS error alert to fail the 870 TLS/IA handshake. 872 If the client sends an error alert to the server, no further EAP- 873 TTLS messages are exchanged, and the server sends an EAP-Failure 874 to terminate the conversation. 876 If the server sends an error alert to the client, the client MUST 877 respond with an Acknowledgement packet to allow the conversation 878 to continue. Upon receipt of the Acknowledgement packet, the 879 server sends an EAP-Failure to terminate the conversation. 881 Note that, unlike EAP-TTLSv0, in EAP-TTLSv1 there is no case in 882 which a client sends a packet with data as a result of having no 883 AVPs to send. In EAP-TTLSv1, if no AVPs are to be sent, there will 884 nevertheless be an InnerApplication message carrying zero AVPs, 885 which the client must send. 887 9. Security Claims 889 Pursuant to [RFC3748], security claims for EAP-TTLSv1 are as 890 follows: 892 Authentication mechanism: TLS plus arbitrary additional protected 893 authentication(s) 894 Ciphersuite negotiation: Yes 895 Mutual authentication: Yes, in recommended implementation 896 Integrity protection: Yes 897 Replay protection: Yes 898 Confidentiality: Yes 899 Key derivation: Yes 900 Key strength: 384 bits or higher 901 Dictionary attack prot.: Yes 902 Fast reconnect: Yes 903 Crypt. binding: Yes 904 Session independence: Yes 905 Fragmentation: Yes 906 Channel binding: Supported via AVPs, though optional 908 10. Security Considerations 910 This draft is entirely about security and the security 911 considerations associated with the mechanisms employed in this 912 document should be considered by implementers. 914 The following additional issues are relevant: 916 - Anonymity and privacy. EAP-TTLS does not communicate a username 917 in the clear in the initial EAP-Response/Identity. This feature 918 is designed to support anonymity and location privacy from 919 attackers eavesdropping the network path between the client and 920 the TTLS server. However implementers should be aware that other 921 factors - both within EAP-TTLS and elsewhere - may compromise a 922 user's identity. For example, if a user authenticates with a 923 certificate, the subject name in the certificate may reveal the 924 user's identity. Outside of EAP-TTLS, the client's fixed MAC 925 address, or in the case of wireless connections, the client's 926 radio signature, may also reveal information. Additionally, 927 implementers should be aware that a user's identity is not hidden 928 from the TTLS server and may be included in the clear in AAA 929 messages between the TTLS server and the AAA/H server. 931 - Trust in the TTLS server. EAP-TTLS is designed to allow the use 932 of legacy authentication methods to be extended to mediums like 933 wireless in which eavesdropping the link between the client and 934 the access point is easy. However implementers should be aware of 935 the possibility of attacks by rogue TTLS servers - for example in 936 the event that the inner authentication method is susceptible to 937 dictionary attacks. Therefore it is essential that clients be 938 properly configured to only proceed with inner authentications 939 with trusted TTLS servers, as evidenced by the certificate chain 940 presented by the TTLS server in the TTLS handshake. In general, 941 cipher suites that allow the TTLS server to remain anonymous 942 should be avoided, unless the inner authentication itself 943 provides mutual authentication and is resistant to dictionary 944 attack. 946 - TTLS server certificate compromise. The use of TTLS server 947 certificates within EAP-TTLS makes EAP-TTLS susceptible to attack 948 in the event that a TTLS server's certificate is compromised. - 949 TTLS servers should therefore take care to protect their private 950 key. In addition, certificate revocation methods may be used to 951 mitigate against the possibility of key compromise. [RFC3546] 952 describes a way to integrate one such method - OCSP [RFC2560] - 953 into the TLS handshake - use of this approach may be appropriate 954 within EAP-TTLS. 956 - Listing of data cipher preferences. EAP-TTLS negotiates data 957 cipher suites by having the EAP-TTLS server select the first 958 cipher suite appearing on the client list that also appears on 959 the access point list. In order to maximize security, it is 960 therefore recommended that the client order its list according to 961 security - most secure acceptable cipher suite first, least 962 secure acceptable cipher suite last. 964 - Forward secrecy. With forward secrecy, revelation of a secret 965 does not compromise session keys previously negotiated based on 966 that secret. Thus, when the TLS key exchange algorithm provides 967 forward secrecy, if a TTLS server certificate's private key is 968 eventually stolen or cracked, tunneled user password information 969 will remain secure as long as that certificate is no longer in 970 use. Diffie-Hellman key exchange is an example of an algorithm 971 that provides forward secrecy. A forward secrecy algorithm should 972 be considered if attacks against recorded authentication or data 973 sessions are considered to pose a significant threat. 975 11. References 977 11.1 Normative References 979 [TLS/IA] Funk, P., Blake-Wilson, S., Smith, N., Tschofenig, H. 980 and T. Hardjono, " TLS Inner Application Extension 981 (TLS/IA)", draft-funk-tls-inner-application-extension- 982 02.txt, March 2006. 984 [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 985 1700, October 1994. 987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", RFC 2119, March 1997. 990 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 991 1.0", RFC 2246, November 1998. 993 [RFC2486] Aboba, B., and M. Beadles, "The Network Access 994 Identifier", RFC 2486, January 1999. 996 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 997 RFC 2548, March 1999. 999 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1000 "Remote Authentication Dial In User Service (RADIUS)", 1001 RFC 2865, June 2000. 1003 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 1004 J., and T. Wright, "Transport Layer Security (TLS) 1005 Extensions", RFC 3546, June 2003. 1007 [RFC3579] Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 1008 Dial In User Service) Support For Extensible 1009 Authentication Protocol (EAP)", RFC 3579, September 1010 2003. 1012 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1013 Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 1015 [RFC3784] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 1016 H. Levkowetz, "PPP Extensible Authentication Protocol 1017 (EAP)", RFC 3784, June 2004. 1019 11.2 Informative References 1021 [RFC1661] Simpson, W. (Editor), "The Point-to-Point Protocol 1022 (PPP)", STD 51, RFC 1661, July 1994. 1024 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1025 Protocol (CHAP)", RFC 1994, August 1996. 1027 [RFC2716] Aboba, B., and D. Simon, "PPP EAP TLS Authentication 1028 Protocol", RFC 2716, October 1999. 1030 [RFC2433] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 1031 RFC 2433, October 1998. 1033 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1034 Adams, "Internet X.509 Public Key Infrastructure: Online 1035 Certificate Status Protocol - OCSP", RFC 2560, June 1036 1999. 1038 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1039 RFC 2759, January 2000. 1041 [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 1042 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 1043 2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 1044 2004. 1046 [TLS-PSK] Eronen, P., and H. Tschofenig, "Pre-Shared Key 1047 Ciphersuites for Transport Layer Security (TLS)", draft- 1048 ietf-tls-psk-01.txt, August 2004. 1050 [802.1X] IEEE Standards for Local and Metropolitan Area Networks: 1051 Port based Network Access Control, IEEE Std 802.1X-2001, 1052 June 2001. 1054 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1055 in Tunneled Authentication", 1056 http://www.saunalahti.fi/~asokan/research/mitm.html, 1057 Nokia Research Center, Finland, October 24 2002. 1059 [KEYING] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 1060 Key Management Framework", draft-ietf-eap-keying-01.txt 1061 (work in progress), October 2003. 1063 [IKEv2] C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 1064 draft-ietf-ipsec-ikev2-16.txt (work in progress), 1065 September 2004. 1067 [AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1068 Authentication Protocol (EAP) Application", draft-ietf- 1069 aaa-eap-03.txt (work in progress), October 2003. 1071 12. Authors' Addresses 1073 Questions about this memo can be directed to: 1075 Paul Funk 1076 Juniper Networks 1077 222 Third Street 1078 Cambridge, MA 02142 1079 USA 1080 Phone: +1 617 497-6339 1081 E-mail: pfunk@juniper.net 1083 Simon Blake-Wilson 1084 Basic Commerce & Industries, Inc. 1085 304 Harper Drive, Suite 203 1086 Moorestown, NJ 08057 1087 Phone: +1 856 778-1660 1088 E-mail: sblakewilson@bcisse.com 1090 Disclaimer of Validity 1092 This document and the information contained herein are provided on 1093 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1094 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1095 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1096 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1097 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1100 Copyright Statement 1102 Copyright (C) The Internet Society (2006). This document is subject 1103 to the rights, licenses and restrictions contained in BCP 78, and 1104 except as set forth therein, the authors retain all their rights.