child-sa: Don't update outbound policies if they are not installed
[strongswan.git] / 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