idnits 2.17.1 draft-varjonen-hip-eap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2009) is 5407 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol Varjonen 3 Internet-Draft Helsinki Institute for Information 4 Intended status: Informational Technology 5 Expires: January 7, 2010 July 6, 2009 7 HIP and User Authentication 8 draft-varjonen-hip-eap-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to format it 15 for publication as an RFC or to translate it into languages other 16 than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 7, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies how to use Extensible Authentication Protocol 50 (EAP) in HIP to incorporate user authentication in the IPsec tunnel 51 creation. This document describes two new parameters for 52 transporting EAP messages inside HIP control packets. The main focus 53 of this document is to describe how to use these parameters to 54 combine needed EAP negotiation in order to authenticate the user. 55 This document also describes how on-path middleboxes can take part in 56 the negotiation as authenticators. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. EAP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. EAP_SIGNED parameter . . . . . . . . . . . . . . . . . . . 6 72 3.2. EAP_UNSIGNED parameter . . . . . . . . . . . . . . . . . . 6 74 4. EAP Parameters and End-Hosts . . . . . . . . . . . . . . . . . 6 76 5. EAP and on-path middleboxes . . . . . . . . . . . . . . . . . 9 78 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Glossary 92 Terminology and notation used in this document is in most parts 93 borrowed from [RFC3748]. 95 AUTHENTICATOR: Is the entity that initiates the authentication. 96 In HIP the authenticator is equivalent to responder but in mutual 97 authentication, where both communicating parties are 98 authenticated, the supplicant can also be the responder. 100 SUPPLICANT: The end of the link that responds to the authenticator 101 in [IEEE-802.1X]. In HIP a supplicant maps to the initiator but 102 in mutual authentication, where both communicating parties are 103 authenticated, supplicant can also be the responder. 105 BACKEND AUTHENTICATION SERVER: A backend authentication server is 106 an entity that provides an authentication service to an 107 authenticator. When used, this server typically executes EAP 108 methods for the authenticator. 110 EAP SERVER: The entity that terminates the EAP authentication 111 method with the peer. In the case where no backend authentication 112 server is used, the EAP server is part of the authenticator. In 113 the case where the authenticator operates in pass-through mode, 114 the EAP server is located on the backend authentication server. 116 2. Introduction 118 Host Identity Protocol (HIP) [RFC4423] offers a cryptographic 119 namespace and a way to negotiate creation of Security Association 120 (SA) between two hosts. By default, SAs are created by contacting 121 the Responder. With HIP firewalls, administrators can achieve access 122 control on the connection attempts. In some cases access control 123 based only on HITs is not enough. Organizations can have mobile 124 employees that need access to the organizations network from outside 125 the network. HIP can be used to authenticate the host, but by 126 default, anyone possessing the host and its keys can create a HIP 127 association. By introducing Extensible Authentication Protocol (EAP, 128 [RFC3748], [RFC5247]) to HIP, we can extend the authentication of the 129 host to include the authentication of the user. 131 The extensible Authentication Protocol (EAP) is a universal 132 authentication framework for point-to-point connections and it has 133 been adapted to work with [IEEE-802.1X]. EAP can also be used in 134 other environments and is not specific to wireless applications. In 135 practice the supplicant triggers the authenticator to start the 136 authentication towards the supplicant and the authentication method 137 is run on the EAP server. It should be noted that the authentication 138 server can be located at the authenticator. Authenticators can 139 degrade or restrict service such as bandwidth limitation up to 140 refusing connections and reporting access violations when 141 authenticator does not successfully authenticate peer. EAP itself is 142 a framework and does not provide any specific authentication method 143 but it can be extended, hence the name. In this document, as an 144 example, we use extension that provides password only authentication 145 [EAP.Pwd] and the challenge-response exchanges from [RFC3748]. 147 In the following illustration, we depict the message flow of EAP 148 between the supplicant, authenticator and the backend authentication 149 server. 151 Supplicant Authenticator Backend 152 | | Authentication 153 | | Server | 154 | -- Start ---------------------> | | 155 | <- Request identity ----------- | | 156 | -- Response identity ---------> | -- Response identity -------> | 157 | | <- Request 1 ---------------- | 158 | <- Request 1 ------------------ | | 159 | -- Response 1 ----------------> | | 160 | | -- Response 1 --------------> | 161 | . | . | 162 | . | . | 163 | . | . | 164 | | <- Request n ---------------- | 165 | <- Request n ------------------ | | 166 | -- Response n ----------------> | | 167 | | -- Response n---------------> | 168 | | <- Success ------------------ | 169 | <- Success -------------------- | | 170 | | | 172 3. EAP Parameters 174 This section defines two parameters to be used when using EAP with 175 HIP. EAP_SIGNED and EAP_UNSIGNED parameters carry EAP messages 176 between HIP end-hosts and middleboxes. EAP_SIGNED and EAP_UNSIGNED 177 parameters are non-critical parameters and they contain EAP header 178 defined in [RFC3748] in section 4. and EAP request, EAP response, EAP 179 success or EAP failure, which are used as described in [RFC3748] in 180 section 4.1. These parameters can be used in R1, I2, R2 and UPDATE 181 control packets. 183 3.1. EAP_SIGNED parameter 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | EAP (Variable length) / 191 / +-+-+-+-+-+-+-+-+ 192 / | Padding | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Type TBD-IANA (998) 196 Length Length in octets, excluding Type, Length, and Padding 197 EAP EAP message, variable length. 198 Padding Any Padding, if necessary, to make the parameter a 199 multiple of 8 bytes as defined in [RFC5201] in 200 section 5.2.1. 202 3.2. EAP_UNSIGNED parameter 204 On-path middleboxes append this parameter to the control packets. 205 Also authenticators that preserve the R1 pre-creation must use this 206 parameter (as discussed in next section). This parameter is 207 identical with EAP_SIGNED parameter differing only by its type number 208 (TBD-IANA (632997)). 210 4. EAP Parameters and End-Hosts 212 This section defines how end-hosts should behave when EAP related 213 parameters are present in HIP control packets. In the following we 214 present the simplest case of EAP usage with challenge-response 215 exchange. Only relevant parameters are depicted, see [RFC3748] 216 section 5 for more details. 218 Initiator Responder 220 I1 221 --------------------------------> 222 Select precomputed R1 223 R1: puzzle, 224 key, sig, SERVICE_OFFER, 225 EAP_UNSIGNED(challenge) 226 <-------------------------------- 227 Check sig Remain stateless 228 Solve puzzle 229 Calculate response 230 I2: solution, 231 EAP_SIGNED(response), 232 SERVICE_ACK, {key}, sig 233 --------------------------------> 234 Compute D-H Check solution 235 Check sig 236 Check response 237 R2: EAP_SIGNED(success), sig 238 <------------------------------- 239 Check sig Calculate session key 240 Change traffic 241 restrictions 242 ESP 243 <------------------------------> 245 Figure 1 247 A HIP Responder pre-creates R1s in order to minimize the expensive 248 cryptographic operations until Responder has established state. 249 Using EAP parameter will prevent this. In order to use pre-created 250 R1s, a Responder can append the EAP_M parameter into the unsigned 251 part of the message. 253 EAP messages may be so large that if included into the R1, I2 or R2 254 control packets, they would exceed the allowed parameter section size 255 or the minimum MTU of the used link. EAP negotiation may be longer 256 than two messages and hence could not be piggybacked in BEX packets. 257 Due to these reasons EAP negotiation may be run after BEX using 258 UPDATE control packets. In practice this means that while the HIP 259 association is created while BEX its in "unauthorized" state in which 260 the usage of the association is limited until the authentication is 261 approved 263 In the following, we present a BEX continued with EAP-based password 264 only authentication [EAP.Pwd] using EAP parameter in UPDATE control 265 packets. Only relevant parameters are depicted. 267 Initiator Responder 268 (EAP peer) (EAP server) 269 I1 270 --------------------------------> 271 Select precomputed R1 272 R1: puzzle, SERVICE_OFFER, 273 key, sig 274 <-------------------------------- 275 Check sig Remain stateless 276 Solve puzzles 277 I2: solution, SERVICE_ACK, 278 {key}, sig 279 --------------------------------> 280 Compute D-H Check solution 281 Check sig 282 R2: sig, 283 EAP_SIGNED(pwd-ID/Request) 284 <------------------------------- 285 Check sig Calculate session key 286 UPDATE: 287 EAP_SIGNED(pwd-ID/Response) 288 -------------------------------> 289 UPDATE: 290 EAP_SIGNED(pwd-Commit/Request) 291 <------------------------------- 292 UPDATE: 293 EAP_SIGNED(pwd-Commit/Response) 294 -------------------------------> 295 UPDATE: 296 EAP_SIGNED(pwd-Confirm/Request) 297 <------------------------------- 298 UPDATE: 299 EAP_SIGNED(pwd-Confirm/Response) 300 -------------------------------> 301 UPDATE: EAP_SIGNED(Success) 302 <------------------------------- 303 Change traffic 304 restrictions 305 ESP 306 <------------------------------> 308 Responder announces service requiring authentication and the method 309 of authentication using the SERVICE_OFFER parameter (defined in 310 [HIP.Servid]) in R1 control packet. Initiator notifies the responder 311 about the agreement with SERVICE_ACK parameter defined in 312 [HIP.Servid]. Responder can use SP field of SERVICE_OFFER parameter 313 to announce the characteristics of the service. For example 314 (depicted in the following), the service requires authentication 315 (REQ), the service is commercial (COM) forwarding service (FOR) and 316 that EAP [RFC3748] is used (bit 9, TBD-IANA). 318 0 1 319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 320 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 321 0 | 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 | 322 1 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 323 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 325 The actual service is identified in the SID field of SERVICE_OFFER 326 parameter. SD field of the SERVICE_OFFER parameter contains needed 327 information on the service itself and specifies which authentication 328 method should be used (in the above example [EAP.Pwd] is used). If 329 the initiator accepts the terms laid out in the SERVICE_OFFER it 330 answers with a SERVICE_ACK parameter. In practice, this exchange 331 acts as an early warning for the peer that the connection will be 332 throttled or otherwise restricted and that the supplicant must 333 authenticate itself in order to access the service. 335 Finally the authenticator (here Responder) completes the negotiation 336 with EAP success message, contained in EAP parameter, to successful 337 authentication and to failure with EAP failure message contained in 338 EAP parameter (as defined in [RFC3748]. 340 5. EAP and on-path middleboxes 342 In the following, we depict the situation where a on-path middlebox 343 needs to authenticate the user using simple challenge-response 344 exchange. The middlebox appends its parameters to the BEX packets 345 traversing through it. Only relevant parameters are depicted. 347 Initiator Middlebox Responder 348 .---------------------. 349 I1, | | I1, 350 --------------------> | | ---------------------> 351 | | 352 R1, EAP_UNSIGNED(*), | Add EAP_UNSIGNED(*) | R1 353 SERVICE_OFFER | and SERVICE_OFFER | 354 <-------------------- | | <--------------------- 355 | | 356 I2, EAP_SIGNED(**), | Verify response | I2, EAP_SIGNED(**), 357 SERVICE_ACK | | SERVICE_ACK 358 --------------------> | | ---------------------> 359 | Change traffic | 360 | restrictions | 361 R2, | | 362 EAP_SIGNED(success) | Add response | R2 363 <-------------------- | | <--------------------- 364 '---------------------' 365 * = Challenge 366 ** = Response 368 In the following we present a BEX continued with EAP authentication 369 with only a password [EAP.Pwd] traversing through a middlebox (Only 370 relevant parameters are depicted). 372 Initiator Middlebox Responder 373 .--------------------. 374 I1, | | I1, 375 ---------------------> | | ---------------------> 376 | | 377 R1, SERVICE_OFFER | Add SERVICE_OFFER | R1 378 <--------------------- | | <--------------------- 379 | | 380 I2, SERVICE_ACK | Verify response | I2, SERVICE_ACK 381 ---------------------> | Let I2 through | ---------------------> 382 | | 383 R2, | Add | 384 EAP_US(pwd-ID/*) | EAP_US(pwd-ID/*) | R2 385 <--------------------- | | <--------------------- 386 UPD, | | UPD, 387 EAP_S(pwd-ID/**), SEQ | | EAP_S(pwd-ID/**), SEQ 388 ---------------------> | | ---------------------> 389 UPD, ACK, | Add pwd-Commit/* | 390 EAP_US(pwd-Commit/*) | | UPD, ACK 391 <--------------------- | | <--------------------- 392 UPD, SEQ, | | UPD, SEQ, 393 EAP(pwd-Commit/**) | | EAP_S(pwd-Commit(**) 394 ---------------------> | | ---------------------> 395 UPD, ACK, | | 396 EAP_US(pwd-Confirm/*) | Add pwd-Confirm/* | UPD, ACK 397 <--------------------- | | <--------------------- 398 UPD, SEQ, | | UPD, SEQ, 399 EAP_S(pwd-Confirm/**) | | EAP_S(pwd-Confirm/**) 400 ---------------------> | | ---------------------> 401 | Change traffic | 402 | restrictions | 403 UPD, ACK, | | 404 EAP_US(success) | Add EAP response | UPD, ACK 405 <--------------------- | | <--------------------- 406 '--------------------' 407 * = Challenge 408 ** = Response 409 EAP_S = EAP_SIGNED 410 EAP_US = EAP_UNSIGNED 412 When the authentication is run after the BEX and the the 413 authenticator is the middlebox, them Initiator must add SEQ parameter 414 to the UPDATE control packets in order to request the Responder to 415 respond with an ACK parameter. 417 With multiple middleboxes the SERVICE_OFFER parameters SD field will 418 differentiates different middleboxes associated with the same 419 service. Otherwise the SID field will be unique (assigned by IANA, 420 see [HIP.Servid]). 422 6. Discussion 424 Most of the devices (phones, PDAs, laptops) are operated by single 425 user hence the main approach described in this document is 426 applicable. Problems arise with multi-user clients. For example, 427 let's consider a case where machine A has users Aa and Ab. When Aa 428 connects to server B, he creates a tunnel between the HITs of A and 429 B. The problem in this, related to the EAP, is that now user Ab can 430 also communicate using the same tunnel. At least two possible 431 solutions exist. First, usage of Simultaneous Multi-Access extension 432 [HIP.Sima], because it allows HIP to use flow binding to identify and 433 separate multiple ongoing upper layer data flows. Second, Local 434 access control measures, that restrict the use of HITs per UID. 436 7. IANA Considerations 438 This document defines the EAP related parameters for the Host 439 Identity Protocol [RFC5201]. These parameter are defined in 440 Section 3. 442 8. Security Considerations 444 Same security considerations apply as for EAP [RFC3748] 446 As an additional measure of protection participants can encapsulate 447 the EAP parameters inside ENCRYPTED parameter defined in [RFC5201] 449 9. Acknowledgements 451 The authors would like to thank M. Komu and T. Heer of fruitful 452 conversations on the subject. 454 10. Normative References 456 [EAP.Pwd] Harkins, D. and G. Zorn, "EAP Authentication Using Only A 457 Password", . 459 [HIP.Servid] 460 Heer, T., Varjonen, S., and H. Wirtz, "Service Identifiers 461 for HIP>", . 463 [HIP.Sima] 464 Pierrel, S., Jokela, P., and J. Melen, "Simultaneous 465 Multi-Access extension to the Host Identity Protocol", 466 . 468 [IEEE-802.1X] 469 Institute of Electrical and Electronics Engineers, "Local 470 and Metropolitan Area Networks: Port-Based Network Access 471 Control", IEEE Standard 802.1X, Sep 2001. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 477 Levkowetz, "Extensible Authentication Protocol (EAP)", 478 RFC 3748, June 2004. 480 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 481 (HIP) Architecture", RFC 4423, May 2006. 483 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 484 "Host Identity Protocol", RFC 5201, April 2008. 486 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 487 Authentication Protocol (EAP) Key Management Framework", 488 RFC 5247, August 2008. 490 Author's Address 492 Samu Varjonen 493 Helsinki Institute for Information Technology 494 Metsnneidonkuja 4 495 Helsinki 496 Finland 498 Fax: +35896949768 499 Email: samu.varjonen@hiit.fi 500 URI: http://www.hiit.fi