doc/standards/rfc4739.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          P. Eronen
   8 Request for Comments: 4739                                         Nokia
   9 Category: Experimental                                       J. Korhonen
  10                                                              TeliaSonera
  11                                                            November 2006
  12
  13
  14                    Multiple Authentication Exchanges
  15              in the Internet Key Exchange (IKEv2) Protocol
  16
  17 Status of This Memo
  18
  19    This memo defines an Experimental Protocol for the Internet
  20    community.  It does not specify an Internet standard of any kind.
  21    Discussion and suggestions for improvement are requested.
  22    Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The IETF Trust (2006).
  27
  28 Abstract
  29
  30    The Internet Key Exchange (IKEv2) protocol supports several
  31    mechanisms for authenticating the parties, including signatures with
  32    public-key certificates, shared secrets, and Extensible
  33    Authentication Protocol (EAP) methods.  Currently, each endpoint uses
  34    only one of these mechanisms to authenticate itself.  This document
  35    specifies an extension to IKEv2 that allows the use of multiple
  36    authentication exchanges, using either different mechanisms or the
  37    same mechanism.  This extension allows, for instance, performing
  38    certificate-based authentication of the client host followed by an
  39    EAP authentication of the user.  When backend authentication servers
  40    are used, they can belong to different administrative domains, such
  41    as the network access provider and the service provider.
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Eronen & Korhonen             Experimental                      [Page 1]
  59 \f
  60 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
  61
  62
  63 Table of Contents
  64
  65    1. Introduction ....................................................3
  66       1.1. Usage Scenarios ............................................4
  67       1.2. Terminology ................................................5
  68    2. Solution ........................................................5
  69       2.1. Solution Overview ..........................................5
  70       2.2. Example 1: Multiple EAP Authentications ....................6
  71       2.3. Example 2: Mixed EAP and Certificate Authentications .......7
  72       2.4. Example 3: Multiple Initiator Certificates .................8
  73       2.5. Example 4: Multiple Responder Certificates .................8
  74    3. Payload Formats .................................................9
  75       3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
  76       3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
  77    4. IANA Considerations .............................................9
  78    5. Security Considerations .........................................9
  79    6. Acknowledgments ................................................10
  80    7. References .....................................................10
  81       7.1. Normative References ......................................10
  82       7.2. Informative References ....................................10
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Eronen & Korhonen             Experimental                      [Page 2]
 115 \f
 116 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 117
 118
 119 1.  Introduction
 120
 121    IKEv2 [IKEv2] supports several mechanisms for parties involved in the
 122    IKE_SA (IKE security association).  These include signatures with
 123    public-key certificates, shared secrets, and Extensible
 124    Authentication Protocol (EAP) methods.
 125
 126    Currently, each endpoint uses only one of these mechanisms to
 127    authenticate itself.  However, there are scenarios where making the
 128    authorization decision in IKEv2 (whether to allow access or not)
 129    requires using several of these methods.
 130
 131    For instance, it may be necessary to authenticate both the host
 132    (machine) requesting access, and the user currently using the host.
 133    These two authentications would use two separate sets of credentials
 134    (such as certificates and associated private keys) and might even use
 135    different authentication mechanisms.
 136
 137    To take another example, when an operator is hosting a Virtual
 138    Private Network (VPN) gateway service for a third party, it may be
 139    necessary to authenticate the client to both the operator (for
 140    billing purposes) and the third party's Authentication,
 141    Authorization, and Accounting (AAA) server (for authorizing access to
 142    the third party's internal network).
 143
 144    This document specifies an extension to IKEv2 that allows the use of
 145    multiple authentication exchanges, using either different mechanisms
 146    or the same mechanism.  This extension allows, for instance,
 147    performing certificate-based authentication of the client host
 148    followed by an EAP authentication of the user.
 149
 150    Each authentication exchange requiring communication with backend AAA
 151    servers may be directed to different backend AAA servers, located
 152    even in different administrative domains.  However, details of the
 153    communication between the IKEv2 gateway and the backend
 154    authentication servers are beyond the scope of this document.  In
 155    particular, this document does not specify any changes to existing
 156    AAA protocols, and it does not require the use of any particular AAA
 157    protocol.
 158
 159    In case of several EAP authentications, it is important to notice
 160    that they are not a "sequence" (as described in Section 2.1 of
 161    [EAP]), but separate independent EAP conversations, which are usually
 162    also terminated in different EAP servers.  Multiple authentication
 163    methods within a single EAP conversation are still prohibited as
 164    described in Section 2.1 of [EAP].  Using multiple independent EAP
 165    conversations is similar to the separate Network Access Provider
 166    (NAP) and Internet Service Provider (ISP) authentication exchanges
 167
 168
 169
 170 Eronen & Korhonen             Experimental                      [Page 3]
 171 \f
 172 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 173
 174
 175    planned for [PANA].  The discovery of the appropriate EAP server for
 176    each EAP authentication conversation is based on AAA routing.
 177
 178 1.1.  Usage Scenarios
 179
 180    Figure 1 shows an example architecture of an operator-hosted VPN
 181    scenario that could benefit from a two-phase authentication within
 182    the IKEv2 exchange.  First, the client authenticates towards the
 183    Network Access Provider (NAP) and gets access to the NAP-hosted VPN
 184    gateway.  The first-phase authentication involves the backend AAA
 185    server of the NAP.  After the first authentication, the client
 186    initiates the second authentication round that also involves the
 187    Third Party's backend AAA server.  If both authentications succeed,
 188    the required IPsec tunnels are set up and the client can access
 189    protected networks behind the Third Party.
 190
 191
 192        Client                         *Network Access Provider*
 193      +---------+                    +---------+              +-----+
 194      |         |                    |  NAP's  |              | NAP |
 195      |Protected|     IPsec SAs      | Tunnel  | AAA Protocol | AAA |
 196      |Endpoint |<------------------>|Endpoint |<------------>|Serv/|
 197      |         |                    |         |              |Proxy|
 198      +---------+                    +---------+              +-----+
 199                                        ^                        ^
 200                             IPsec or  /                  AAA    |
 201                         Leased Line  /                 Protocol |
 202                                     /                           |
 203                                    v                            |
 204                            +---------+    *Third Party*         v
 205                            |3rd Party|                       +-----+
 206             Protected      | Tunnel  |                       | 3rd |
 207                Subnet <----|Endpoint |                       |Party|
 208                            |         |                       | AAA |
 209                            +---------+                       +-----+
 210
 211           Figure 1: Two-phase authentication used to gain access to
 212           the Third Party network via Network Access Provider.  AAA
 213           traffic goes through NAP's AAA server.
 214
 215    The NAP's AAA server can be used to proxy the AAA traffic to the
 216    Third Party's backend AAA server.  Alternatively, the AAA traffic
 217    from the NAP's tunnel endpoint could go directly to the Third Party's
 218    backend AAA servers.  However, this is more or less an AAA routing
 219    issue.
 220
 221
 222
 223
 224
 225
 226 Eronen & Korhonen             Experimental                      [Page 4]
 227 \f
 228 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 229
 230
 231 1.2.  Terminology
 232
 233    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 234    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 235    document are to be interpreted as described in [KEYWORDS].
 236
 237    The terms and abbreviations "authenticator", "backend authentication
 238    server", "EAP server", and "peer" in this document are to be
 239    interpreted as described in [EAP].
 240
 241    When messages containing IKEv2 payloads are described, optional
 242    payloads are shown in brackets (for instance, "[FOO]"), and a plus
 243    sign indicates that a payload can be repeated one or more times (for
 244    instance, "FOO+").
 245
 246 2.  Solution
 247
 248 2.1.  Solution Overview
 249
 250    The peers announce support for this IKEv2 extension by including a
 251    MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response
 252    (responder) and the first IKE_AUTH request (initiator).
 253
 254    If both peers support this extension, either of them can announce
 255    that it wishes to have a second authentication by including an
 256    ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that
 257    contains an AUTH payload.  This indicates that the peer sending the
 258    ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of
 259    credentials to the other peer.  The next IKE_AUTH message sent by
 260    this peer will contain a second identity payload (IDi or IDr) and
 261    starts another authentication exchange.  The IKE_AUTH phase is
 262    considered successful only if all the individual authentication
 263    exchanges complete successfully.
 264
 265    It is assumed that both peers know what credentials they want to
 266    present; there is no negotiation about, for instance, what type of
 267    authentication is to be done.  As in IKEv2, EAP-based authentication
 268    is always requested by the initiator (by omitting the AUTH payload).
 269
 270    The AUTH payloads are calculated as specified in [IKEv2] Sections
 271    2.15 and 2.16, where IDi' refers to the latest IDi payload sent by
 272    the initiator, and IDr' refers to the latest IDr payload sent by the
 273    responder.  If EAP methods that do not generate shared keys are used,
 274    it is possible that several AUTH payloads with identical contents are
 275    sent.  When such EAP methods are used, the purpose of the AUTH
 276    payload is simply to delimit the authentication exchanges, and ensure
 277    that the IKE_SA_INIT request/response messages were not modified.
 278
 279
 280
 281
 282 Eronen & Korhonen             Experimental                      [Page 5]
 283 \f
 284 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 285
 286
 287 2.2.  Example 1: Multiple EAP Authentications
 288
 289    This example shows certificate-based authentication of the responder
 290    followed by an EAP authentication exchange (messages 1-10).  When the
 291    first EAP exchange is ending (the initiator is sending its AUTH
 292    payload), the initiator announces that it wishes to have a second
 293    authentication exchange by including an ANOTHER_AUTH_FOLLOWS
 294    notification (message 9).
 295
 296    After this, a second authentication exchange begins.  The initiator
 297    sends a new IDi payload but no AUTH payload (message 11), indicating
 298    that EAP will be used.  After that, another EAP authentication
 299    exchange follows (messages 12-18).
 300
 301       Initiator                   Responder
 302      -----------                 -----------
 303       1. HDR, SA, KE, Ni -->
 304                              <--  2. HDR, SA, KE, Nr, [CERTREQ],
 305                                           N(MULTIPLE_AUTH_SUPPORTED)
 306       3. HDR, SK { IDi, [CERTREQ+], [IDr],
 307                    SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
 308                              <--  4. HDR, SK { IDr, [CERT+], AUTH,
 309                                                EAP(Request) }
 310       5. HDR, SK { EAP(Response) }  -->
 311                              <--  6. HDR, SK { EAP(Request) }
 312       7. HDR, SK { EAP(Response) }  -->
 313                              <--  8. HDR, SK { EAP(Success) }
 314       9. HDR, SK { AUTH,
 315                    N(ANOTHER_AUTH_FOLLOWS) }  -->
 316                              <--  10. HDR, SK { AUTH }
 317       11. HDR, SK { IDi }  -->
 318                              <--  12. HDR, SK { EAP(Request) }
 319       13. HDR, SK { EAP(Response) }  -->
 320                              <--  14. HDR, SK { EAP(Request) }
 321       15. HDR, SK { EAP(Response) }  -->
 322                              <--  16. HDR, SK { EAP(Success) }
 323       17. HDR, SK { AUTH }  -->
 324                              <--  18. HDR, SK { AUTH, SA, TSi, TSr }
 325
 326           Example 1: Certificate-based authentication of the
 327           responder, followed by two EAP authentication exchanges.
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Eronen & Korhonen             Experimental                      [Page 6]
 339 \f
 340 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 341
 342
 343 2.3.  Example 2: Mixed EAP and Certificate Authentications
 344
 345    Another example is shown below: here both the initiator and the
 346    responder are first authenticated using certificates (or shared
 347    secrets); this is followed by an EAP authentication exchange.
 348
 349       Initiator                   Responder
 350      -----------                 -----------
 351       1. HDR, SA, KE, Ni -->
 352                              <--  2. HDR, SA, KE, Nr, [CERTREQ],
 353                                           N(MULTIPLE_AUTH_SUPPORTED)
 354       3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
 355                    SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
 356                    N(ANOTHER_AUTH_FOLLOWS) }  -->
 357                              <--  4. HDR, SK { IDr, [CERT+], AUTH }
 358       5. HDR, SK { IDi }  -->
 359                              <--  6. HDR, SK { EAP(Request) }
 360       7. HDR, SK { EAP(Response) }  -->
 361                              <--  8. HDR, SK { EAP(Request) }
 362       9. HDR, SK { EAP(Response) }  -->
 363                              <--  10. HDR, SK { EAP(Success) }
 364       11. HDR, SK { AUTH }  -->
 365                              <--  12. HDR, SK { AUTH, SA, TSi, TSr }
 366
 367              Example 2: Certificate-based (or shared-secret-based)
 368              authentication of the initiator and the responder,
 369              followed by an EAP authentication exchange.
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Eronen & Korhonen             Experimental                      [Page 7]
 395 \f
 396 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 397
 398
 399 2.4.  Example 3: Multiple Initiator Certificates
 400
 401    This example shows yet another possibility: the initiator has two
 402    different certificates (and associated private keys), and
 403    authenticates both of them to the responder.
 404
 405       Initiator                   Responder
 406      -----------                 -----------
 407       1. HDR, SA, KE, Ni -->
 408                              <--  2. HDR, SA, KE, Nr, [CERTREQ],
 409                                           N(MULTIPLE_AUTH_SUPPORTED)
 410       3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
 411                    SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
 412                    N(ANOTHER_AUTH_FOLLOWS) }  -->
 413                              <--  4. HDR, SK { IDr, [CERT+], AUTH }
 414       5. HDR, SK { IDi, [CERT+], AUTH }  -->
 415                              <--  6. HDR, SK { SA, TSi, TSr }
 416
 417           Example 3: Two certificate-based authentications of the
 418           initiator, and one certificate-based authentication
 419           of the responder.
 420
 421 2.5.  Example 4: Multiple Responder Certificates
 422
 423    This example shows yet another possibility: the responder has two
 424    different certificates (and associated private keys), and
 425    authenticates both of them to the initiator.
 426
 427       Initiator                   Responder
 428      -----------                 -----------
 429       1. HDR, SA, KE, Ni -->
 430                              <--  2. HDR, SA, KE, Nr, [CERTREQ],
 431                                           N(MULTIPLE_AUTH_SUPPORTED)
 432       3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
 433                    SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
 434                              <--  4. HDR, SK { IDr, [CERT+], AUTH,
 435                                                N(ANOTHER_AUTH_FOLLOWS) }
 436       5. HDR, SK { }  -->
 437                              <--  6. HDR, SK { IDr, [CERT+], AUTH,
 438                                                SA, TSi, TSr }
 439
 440           Example 4: Two certificate-based authentications of the
 441           responder, and one certificate-based authentication
 442           of the initiator.
 443
 444
 445
 446
 447
 448
 449
 450 Eronen & Korhonen             Experimental                      [Page 8]
 451 \f
 452 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 453
 454
 455 3.  Payload Formats
 456
 457 3.1.  MULTIPLE_AUTH_SUPPORTED Notify Payload
 458
 459    The MULTIPLE_AUTH_SUPPORTED notification is included in the
 460    IKE_SA_INIT response or the first IKE_AUTH request to indicate that
 461    the peer supports this specification.  The Notify Message Type is
 462    MULTIPLE_AUTH_SUPPORTED (16404).  The Protocol ID and SPI Size fields
 463    MUST be set to zero, and there is no data associated with this Notify
 464    type.
 465
 466 3.2.  ANOTHER_AUTH_FOLLOWS Notify Payload
 467
 468    The ANOTHER_AUTH_FOLLOWS notification payload is included in an
 469    IKE_AUTH message containing an AUTH payload to indicate that the peer
 470    wants to continue with another authentication exchange.  The Notify
 471    Message Type is ANOTHER_AUTH_FOLLOWS (16405).  The Protocol ID and
 472    SPI Size fields MUST be set to zero, and there is no data associated
 473    with this Notify type.
 474
 475 4.  IANA Considerations
 476
 477    This document defines two new IKEv2 notifications,
 478    MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are
 479    allocated from the "IKEv2 Notify Message Types" namespace defined in
 480    [IKEv2].
 481
 482    This document does not define any new namespaces to be managed by
 483    IANA.
 484
 485 5.  Security Considerations
 486
 487    Security considerations for IKEv2 are discussed in [IKEv2].  The
 488    reader is encouraged to pay special attention to considerations
 489    relating to the use of EAP methods that do not generate shared keys.
 490    However, the use of multiple authentication exchanges results in at
 491    least one new security consideration.
 492
 493    In normal IKEv2, the responder authenticates the initiator before
 494    revealing its identity (except when EAP is used).  When multiple
 495    authentication exchanges are used to authenticate the initiator, the
 496    responder has to reveal its identity before all of the initiator
 497    authentication exchanges have been completed.
 498
 499
 500
 501
 502
 503
 504
 505
 506 Eronen & Korhonen             Experimental                      [Page 9]
 507 \f
 508 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 509
 510
 511 6.  Acknowledgments
 512
 513    The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
 514    Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika
 515    Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus
 516    Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable
 517    comments.
 518
 519 7.  References
 520
 521 7.1.  Normative References
 522
 523    [IKEv2]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
 524                RFC 4306, December 2005.
 525
 526    [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
 527                Requirement Levels", RFC 2119, March 1997.
 528
 529 7.2.  Informative References
 530
 531    [EAP]       Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
 532                Levkowetz, "Extensible Authentication Protocol (EAP)",
 533                RFC 3748, June 2004.
 534
 535    [PANA]      Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C.
 536                Wang, "Protocol for Carrying Authentication for Network
 537                Access (PANA) Requirements", RFC 4058, May 2005.
 538
 539 Authors' Addresses
 540
 541    Pasi Eronen
 542    Nokia Research Center
 543    P.O. Box 407
 544    FIN-00045 Nokia Group
 545    Finland
 546
 547    EMail: pasi.eronen@nokia.com
 548
 549
 550    Jouni Korhonen
 551    TeliaSonera
 552    P.O. Box 970
 553    FIN-00051 Sonera
 554    Finland
 555
 556    EMail: jouni.korhonen@teliasonera.com
 557
 558
 559
 560
 561
 562 Eronen & Korhonen             Experimental                     [Page 10]
 563 \f
 564 RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006
 565
 566
 567 Full Copyright Statement
 568
 569    Copyright (C) The IETF Trust (2006).
 570
 571    This document is subject to the rights, licenses and restrictions
 572    contained in BCP 78, and except as set forth therein, the authors
 573    retain all their rights.
 574
 575    This document and the information contained herein are provided on an
 576    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 577    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
 578    AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 579    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 580    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
 581    IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
 582    PURPOSE.
 583
 584 Intellectual Property
 585
 586    The IETF takes no position regarding the validity or scope of any
 587    Intellectual Property Rights or other rights that might be claimed to
 588    pertain to the implementation or use of the technology described in
 589    this document or the extent to which any license under such rights
 590    might or might not be available; nor does it represent that it has
 591    made any independent effort to identify any such rights.  Information
 592    on the procedures with respect to rights in RFC documents can be
 593    found in BCP 78 and BCP 79.
 594
 595    Copies of IPR disclosures made to the IETF Secretariat and any
 596    assurances of licenses to be made available, or the result of an
 597    attempt made to obtain a general license or permission for the use of
 598    such proprietary rights by implementers or users of this
 599    specification can be obtained from the IETF on-line IPR repository at
 600    http://www.ietf.org/ipr.
 601
 602    The IETF invites any interested party to bring to its attention any
 603    copyrights, patents or patent applications, or other proprietary
 604    rights that may cover technology that may be required to implement
 605    this standard.  Please address the information to the IETF at
 606    ietf-ipr@ietf.org.
 607
 608 Acknowledgement
 609
 610    Funding for the RFC Editor function is currently provided by the
 611    Internet Society.
 612
 613
 614
 615
 616
 617
 618 Eronen & Korhonen             Experimental                     [Page 11]
 619 \f