idnits 2.17.1 draft-torvinen-http-digest-aka-v2-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 573. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 5) being 80 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([4], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (October 28, 2004) is 7119 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) == Unused Reference: '7' is defined on line 508, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3310 (ref. '6') -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '7') (Obsoleted by RFC 5226) == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-02 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Torvinen 2 Internet-Draft J. Arkko 3 Expires: April 28, 2005 M. Naslund 4 Ericsson 5 October 28, 2004 7 Hypertext Transfer Protocol (HTTP) Digest Authentication Using 8 Authentication and Key Agreement (AKA) Version-2 9 draft-torvinen-http-digest-aka-v2-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 28, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 HTTP Digest as specified in [4] is known to be vulnerable to 45 man-in-the-middle attacks if the client fails to authenticate the 46 server in TLS, or if the same passwords are used for authentication 47 in some other context without TLS. This is a general problem that 48 exist not just with HTTP Digest but also with other IETF protocols 49 that use tunneled authentication. This document specifies version 2 50 of the HTTP Digest AKA algorithm [6]. This algorithm can be 51 implemented in a way that it is resistant to the man-in-the-middle 52 attack. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. HTTP Digest AKAv2 . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1 Password generation . . . . . . . . . . . . . . . . . . . 6 61 3.2 Session keys . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Example Digest AKAv2 Operation . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 5.1 Multiple Authentication Schemes and Algorithms . . . . . . 8 65 5.2 Session Protection . . . . . . . . . . . . . . . . . . . . 8 66 5.3 Man-in-the-middle attacks . . . . . . . . . . . . . . . . 8 67 5.4 Entropy . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 6.1 Registration Information . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 72 7.2 Informative References . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . 14 76 1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [3]. 82 2. Introduction 84 The Hypertext Transfer Protocol (HTTP) Digest Authentication, 85 described in [4], has been extended in [6] to support Authentication 86 and Key Agreement (AKA) mechanism [8]. AKA mechanism performs 87 authentication and session key distribution in Universal Mobile 88 Telecommunications System (UMTS) networks. HTTP Digest AKA enables 89 the usage of AKA as a one-time password generation mechanism for 90 Digest authentication. 92 HTTP Digest is known to be vulnerable to man-in-the-middle attacks, 93 even when run inside TLS, if the same HTTP Digest authentication 94 credentials are used in some other context without TLS. The attacker 95 may initiate a TLS session with a server, and when the server 96 challenges the attacker with HTTP Digest, the attacker masquerades 97 the server to the victim. If the victim responds to the challenge, 98 the attacker is able to use this response towards the server in HTTP 99 Digest. Note that this attack is an instance of general attack that 100 affects a number of IETF protocols such as PIC. The general problem 101 is discussed in [9] and [10]. 103 Because of the previous vulnerability, the use of HTTP Digest "AKAv1" 104 should be limited to the situations where the client is able to 105 demonstrate that in addition to the AKA response, it possess the AKA 106 session keys. This is possible, for example, if the underlying 107 security protocol uses the AKA generated session keys to protect the 108 authentication response. This is the case for example in the 3GPP IP 109 Multimedia Core Network Subsystem (IMS) where HTTP Digest "AKAv1" is 110 currently applied. However, HTTP Digest "AKAv1" should not be used 111 with tunnelled security protocols that do not utilize the AKA session 112 keys. For example, the use of HTTP Digest "AKAv1" is not necessarily 113 secure with TLS if the server side is authenticated using 114 certificates and the client side is authenticated using HTTP Digest 115 AKA. 117 There are at least four potential solutions to the problem: 119 1. The use of the authentication credentials is limited to one 120 application only. In general, this approach is good and can be 121 recommended from security point of view. However, this will 122 increase the total number of authentication credentials for an 123 end-user, and may cause scalability problems in the server side. 125 2. The keys used in the underlying security protocols are somehow 126 bind to the keys used in the tunneled authentication protocol. 127 However, this would cause problems with the current 128 implementations of underlying security protocols. For example, 129 it is not possible to use the session keys from TLS at 130 application layer. Furthermore, this solution would only solve 131 the problem when HTTP Digest is used over one hop, and leave the 132 problem of using HTTP Digest via multiple hops, e.g. via proxy 133 servers, unsolved. 135 3. Authentication credentials are used in cryptographically 136 different way for each media and/or access network. However, it 137 may be difficult to know which underlying media is used below the 138 application. 140 4. Authentication credentials are used in cryptographically 141 different way for each application. 143 This document specifies a new algorithm version for HTTP Digest AKA, 144 i.e. "AKAv2". "AKAv2" specifies a cryptographically different way 145 to use AKA credentials in use cases that are based either on HTTP 146 Digest authentication or UMTS authentication (cf. approach 4 above). 147 The only difference to "AKAv1" is that in addition to AKA response 148 RES the AKA related session keys, IK and CK, are also used as the 149 password for HTTP Digest. AKAv2 is immune to man-in-the-middle 150 attack described above. However, if AKAv2 is used in some 151 environment both with and without some underlying security, such as 152 TLS, the problem still exists. 154 New HTTP Digest AKA algorithm versions can be registered in IANA 155 based on Expert Review. Documentation of new algorithm versions is 156 not mandated as RFCs. However, "AKAv2" is documented as an RFC 157 because the use of different AKA algorithm versions includes security 158 implications that the implementators should be aware of. The 159 extension version and security implications are presented in this 160 document. 162 2.1 Terminology 164 This chapter explains the terminology used in this document. 166 AKA 168 Authentication and Key Agreement. 170 AKA is a challenge-response based mechanism that uses symmetric 171 cryptography. AKA can be run in a UMTS IM Services Identity 172 Module (ISIM) or in UMTS Subscriber Identity Module (USIM), which 173 reside on a smart card like device that also provides tamper 174 resistant storage of shared secrets. 176 CK 178 Cipher Key. An AKA session key for encryption. 180 CK' 182 Cipher Key. HTTP Digest AKAv2 session key for encryption. CK' is 183 derived from CK using a pseudo-random function. 185 IK 187 Integrity Key. An AKA session key for integrity check. 189 IK' 191 Integrity Key. HTTP Digest AKAv2 session key for integrity check. 192 IK' is derived from IK using a pseudo-random function. 194 ISIM 196 IP Multimedia Services Identity Module. Sometimes ISIM is 197 implemented using USIM. 199 RES 201 Authentication Response. Generated by the ISIM. 203 PRF 205 Pseudo-random function that is used to construct the AKAv2 206 password and related session keys IK' and CK'. In this document, 207 PRF is presented in format KD(secret, data) denoting a keyed 208 digest algorithm (KD) performed to the data "data" with the secret 209 "secret". 211 SIM 213 Subscriber Identity Module. GSM counter part for ISIM and USIM. 215 UMTS 217 Universal Mobile Telecommunications System. 219 USIM 220 UMTS Subscriber Identity Module. UMTS counter part for ISIM and 221 SIM. 223 XRES 225 Expected Authentication Response. In a successful authentication 226 this is equal to RES. 228 3. HTTP Digest AKAv2 230 In general, the Digest AKAv2 operation is identical to the Digest 231 AKAv1 operation described in [6]. This chapter specifies the parts 232 in which Digest AKAv2 is different from Digest AKAv1 operation. The 233 notation used in the Augmented BNF definitions for the new and 234 modified syntax elements in this section is as used in SIP [5], and 235 any elements not defined in this section are as defined in [6]. 237 In order to direct the client into using AKAv2 for authentication 238 instead of other AKA versions or other HTTP Digest algorithms, the 239 AKA version directive of [6] shall have the following new value: 241 aka-version = "AKAv2" 243 The AKA version directive is used as a part of the algorithm field as 244 defined in [6]. 246 Example: algorithm=AKAv2-MD5 248 3.1 Password generation 250 The client shall use base64 encoded [1] parameters PRF(RES||IK||CK, 251 "http-digest-akav2-password") as a "password" when calculating the 252 HTTP Digest response directive for AKAv2. 254 The server shall use base64 encoded [1] parameters PRF(XRES||IK||CK, 255 "http-digest-akav2-password") as a "password" when checking the HTTP 256 Digest response or when calculating the "response-auth" of the 257 "Authentication-Info" header. 259 The pseudo-random function (PRF) used to construct the HTTP Digest 260 password is equal to HMAC [2] using the hash algorithm that is used 261 in producing the digest and the checksum. For example, if the 262 algorithm is AKAv2-MD5, then the PRF is HMAC_MD5. 264 The string "http-digest-akav2-password" included in the key 265 derivation is case sensitive. 267 3.2 Session keys 269 Even though HTTP Digest AKA framework does not specify the use of the 270 session keys IK and CK for confidentiality and integrity protection, 271 the keys may be used for creating additional security within HTTP 272 authentication or some other security mechanism. However, the 273 original session keys IK and CK MUST NOT be directly re-used for such 274 additional security in "AKAv2". Instead, session keys IK' and CK' 275 are derived from the original keys IK and CK in the following way: 277 IK' = PRF(IK, "http-digest-akav2-integritykey") 279 CK' = PRF(CK, "http-digest-akav2-cipherkey") 281 Any application using HTTP authentication framework is allowed to use 282 these masked session keys. The unmaksed session keys MAY also be 283 re-used in some other context if some other application specific 284 strings than "http-digest-akav2-integritykey" or 285 "http-digest-akav2-cipherkey" are used to mask the original session 286 keys. 288 The pseudo-random function (PRF) used to construct the HTTP Digest 289 session keys is equal to HMAC [2] using the hash algorithm that is 290 used in producing the digest and the checksum. For example, if the 291 algorithm is AKAv2-MD5, then the PRF is HMAC_MD5. The algorithm MUST 292 be used in HMAC format as defined in [2]. 294 The strings "http-digest-akav2-integritykey" and 295 "http-digest-akav2-cipherkey" included in the key derivation are case 296 sensitive. 298 4. Example Digest AKAv2 Operation 300 This document does not introduce any changes to the operations of 301 HTTP Digest or HTTP Digest AKA. Examples defined in [6] applies 302 directly to AKAv2 with the following two exceptions: 304 1. The algorithm directive has a prefix "AKAv2" instead of "AKAv1". 306 2. The HTTP Digest password is derived from base64 encoded 307 PRF(RES||IK||CK, "http-digest-akav2-password") or 308 PRF(XRES||IK||CK, "http-digest-akav2-password") instead of (RES) 309 or (XRES) respectively. 311 3. The optional session keys are derived from PRF(IK, 312 "http-digest-akav2-integritykey") and PRF(CK, 313 "http-digest-akav2-cipherkey") instead of IK and CK respectively. 315 Note that the password in "AKAv1" is in binary format. "AKAv2" 316 password is base64 encoded [1]. 318 5. Security Considerations 320 5.1 Multiple Authentication Schemes and Algorithms 322 The rules for an user agent for choosing among multiple 323 authentication schemes and algorithms are as defined in [6] except 324 that the user agent MUST choose "AKAv2" if both "AKAv1" and "AKAv2" 325 are present. 327 Since HTTP Digest is known to be vulnerable for bidding-down attack 328 in environments where multiple authentication schemes and/or 329 algorithms are used, the system implementators should pay special 330 attention for scenarios where both "AKAv1" and "AKAv2" are used. 331 Especially if the AKA generated sessions keys or some other 332 additional security measures to authenticate the clients, such as 333 client certificates, are not used, the use of both AKA algorithm 334 versions should be avoided. 336 5.2 Session Protection 338 Even though "AKAv2" uses the additional integrity (IK) and 339 confidentiality (CK) keys as a part of HTTP Digest AKA password, 340 these session keys may still be used for creating additional security 341 within HTTP authentication or some other security mechanism. This 342 recommendation is based on the assumption that algorithms used in 343 HTTP Digest, such as MD5, are sufficiently strong one-way functions, 344 and consequently HTTP Digest responses leak no or very little 345 computational information about IK and CK. Furthermore, the session 346 keys are masked into IK' and CK' before they can be used for session 347 protection. 349 5.3 Man-in-the-middle attacks 351 [9] describe a "man-in-the-middle" attack related to tunnelled 352 authentication protocols. The attack can occur e.g. in EAP context 353 or any similar contexts where tunnelled authentication is used and 354 where the same authentication credentials are used without protection 355 in some other context or the client fails to authenticate the server. 357 For example, the use of TLS with HTTP Digest authentication (i.e. 358 TLS for server authentication, and subsequent use of HTTP Digest for 359 client authentication) is an instance of such scenario. HTTP 360 challenges and responses can be fetched from and to different TLS 361 tunnels without noticing where they originally came from. 362 Especially, the attack is easy to perform if the client fails to 363 authenticate the server. If the same HTTP credentials are used with 364 unsecured connection, the attack is also easy to perform. 366 This is how the "man-in-the-middle" attack works with HTTP Digest and 367 TLS if the victim (i.e. the client) fails to authenticate the 368 server: 370 1. The victim contacts the attacker using TLS. If the attacker has 371 a valid server certificate, the client may continue talking to 372 the attacker and use some HTTP authentication compatible 373 protocol, such as Session Initiation Protocol (SIP). 375 2. The attacker contacts some real proxy/server also using TLS and 376 some HTTP authentication compatible protocol. The proxy/server 377 responds to the attacker with HTTP Authentication challenge. 379 3. The attacker forwards the HTTP Authentication challenge from the 380 proxy/server to the victim. If the victim is not careful, and 381 check that the identity in the server certificate in TLS matches 382 the realm in the HTTP authentication challenge, it may send a new 383 request which carries a valid response to the HTTP Authentication 384 challenge. 386 4. The attacker may use the response with the victims HTTP Digest 387 username and password to authenticate itself to the proxy/server. 389 The man-in-the-middle attack is not possible if the client compares 390 the identities in the TLS server certificate and the HTTP Digest 391 authentication challenge. Note that with HTTP Basic, the client 392 would send the password to the attacker. 394 Another variant of the "man-in-the-middle" attack is the so-called 395 "interleaving attack". This attack is possible if the HTTP Digest 396 authentication credentials are used in several contexts, and in one 397 of them without protection. 399 This is how the attack could proceed: 401 1. The attacker establishes a TLS tunnel to the proxy/server using 402 one-way server authentication. The attacker sends a request to 403 the proxy/server. 405 2. The proxy/server challenges the attacker with HTTP Digest 406 challenge. 408 3. The attacker challenges the victim in some other context using 409 the challenge carried in the HTTP Digest challenge. The HTTP 410 Digest challenge need to be modified to the format used in the 411 protocol of this other context. 413 4. The victim responds with a response. 415 5. The attacker uses the response from the other context for 416 authentication in HTTP Digest. 418 6. The proxy/server accepts the response, and delivers the service 419 to the attacker. 421 In some circumstances, HTTP Digest AKAv1 may be vulnerable for the 422 interleaving attack. In particular, if ISIM is implemented using 423 USIM the HTTP Digest AKAv1 should not be used with tunneled security 424 protocols unless the AKA related session keys, IK and CK, are somehow 425 used with the solution. 427 HTTP Digest AKAv2 is not vulnerable for this interleaving attack, and 428 it can be used with tunneled security protocols without using the 429 related AKA session keys. 431 5.4 Entropy 433 AKAv1 passwords should only be used as one-time passwords if the 434 entropy of the used RES value is limited (e.g., only 32 bits). For 435 this reason, the reuse of the same RES value in authenticating 436 subsequent requests and responses is not recommended. Furthermore, 437 algorithms such as "MD5-sess", which limit the amount of material 438 hashed with a single key, by producing a session key for 439 authentication, should not be used with AKAv1. 441 Passwords generated using AKAv2 can more securely be used for 442 authenticating subsequent requests and responses because the 443 concatenation of AKA credentials (i.e. RES||IK||CK) makes the 444 passwords significantly longer, and the pseudo-random function 445 heuristically provides an entropy equal to the length of this string, 446 or, the length of the PRF output, whichever is the shortest. The 447 user agent does not need to assume that AKAv2 passwords are limited 448 to one-time use only, and it may try to re-use the AKAv2 passwords 449 with the server. However, note that AKAv2 passwords can not be 450 re-used with HTTP Digest AKAv2 algorithm because such authentication 451 challenge will automatically generate a fresh password. AKAv2 452 passwords can be used with other HTTP Digest algorithms, such as 453 "MD5". 455 The underlying AKA protocol (e.g. UMTS AKA) has been designed to 456 keep CK and IK confidential but will typically send RES in the clear. 457 We note that even if (by some unfortunate missuse of AKA) RES values 458 were revealed, the inclusion of RES in PRF(RES||IK||CK) is still 459 benefitial as it makes pre-calculated dictionaries of IK||CK values 460 rather useless (though such dictionaries are anyway infeasible for 461 typical sizes of IK and CK). 463 6. IANA Considerations 465 This document specifies a new aka-version, "AKAv2", to the 466 aka-version namespace maintained by IANA. The procedure for 467 allocation of new aka-versions is defined in [6]. 469 6.1 Registration Information 471 To: ietf-digest-aka@iana.org 473 Subject: Registration of a new AKA version 475 Version identifier: "AKAv2" 477 Contacts for further information: vesa.torvinen@ericsson.com, 478 jari.arkko@ericsson.com or mats.naslund@ericsson.com 480 7. References 482 7.1 Normative References 484 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 485 Extensions (MIME) Part One: Format of Internet Message Bodies", 486 RFC 2045, November 1996. 488 [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 489 for Message Authentication", RFC 2104, February 1997. 491 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 492 Levels", BCP 14, RFC 2119, March 1997. 494 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 495 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 496 Basic and Digest Access Authentication", RFC 2617, June 1999. 498 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 499 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 500 Session Initiation Protocol", RFC 3261, June 2002. 502 [6] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 503 Protocol (HTTP) Digest Authentication Using Authentication and 504 Key Agreement (AKA)", RFC 3310, September 2002. 506 7.2 Informative References 508 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 509 Considerations Section in RFCs", BCP 26, RFC 2434, October 510 1998. 512 [8] 3rd Generation Partnership Project, "Security Architecture 513 (Release 4)", TS 33.102, December 2001. 515 [9] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-Middle in 516 Tunnelled Authentication Protocols", Cryptology ePrint Archive, 517 http://eprint.iacr.org Report 2002/163, October 2002. 519 [10] Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The 520 Compound Authentication Binding Problem", IETF, Work in 521 progress draft-puthenkulam-eap-binding-02.txt, March 2003. 523 Authors' Addresses 525 Vesa Torvinen 526 Ericsson 527 Joukahaisenkatu 1 528 Turku FIN 20520 529 Finland 531 Phone: +358 40 7230822 532 EMail: vesa.torvinen@ericsson.com 534 Jari Arkko 535 Ericsson 536 Hirsalantie 1 537 Jorvas FIN 02420 538 Finland 540 Phone: +358 40 5079256 541 EMail: jari.arkko@ericsson.com 542 Mats N�slund 543 Ericsson 544 Torshamnsgatan 23 545 Stockholm SE 16480 546 Sweden 548 Phone: +46 8 58533739 549 EMail: mats.naslund@ericsson.com 551 Intellectual Property Statement 553 The IETF takes no position regarding the validity or scope of any 554 Intellectual Property Rights or other rights that might be claimed to 555 pertain to the implementation or use of the technology described in 556 this document or the extent to which any license under such rights 557 might or might not be available; nor does it represent that it has 558 made any independent effort to identify any such rights. Information 559 on the procedures with respect to rights in RFC documents can be 560 found in BCP 78 and BCP 79. 562 Copies of IPR disclosures made to the IETF Secretariat and any 563 assurances of licenses to be made available, or the result of an 564 attempt made to obtain a general license or permission for the use of 565 such proprietary rights by implementers or users of this 566 specification can be obtained from the IETF on-line IPR repository at 567 http://www.ietf.org/ipr. 569 The IETF invites any interested party to bring to its attention any 570 copyrights, patents or patent applications, or other proprietary 571 rights that may cover technology that may be required to implement 572 this standard. Please address the information to the IETF at 573 ietf-ipr@ietf.org. 575 Disclaimer of Validity 577 This document and the information contained herein are provided on an 578 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 579 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 580 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 581 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 582 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 583 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 585 Copyright Statement 587 Copyright (C) The Internet Society (2004). This document is subject 588 to the rights, licenses and restrictions contained in BCP 78, and 589 except as set forth therein, the authors retain all their rights. 591 Acknowledgment 593 Funding for the RFC Editor function is currently provided by the 594 Internet Society.