load-tester: support extended traffic selector syntax, as in leftsubnet
[strongswan.git] / doc / standards / rfc5998.txt
1
2
3
4
5
6
7 Internet Engineering Task Force (IETF)                         P. Eronen
8 Request for Comments: 5998                                   Independent
9 Updates: 5996                                              H. Tschofenig
10 Category: Standards Track                         Nokia Siemens Networks
11 ISSN: 2070-1721                                               Y. Sheffer
12                                                              Independent
13                                                           September 2010
14
15
16            An Extension for EAP-Only Authentication in IKEv2
17
18 Abstract
19
20    IKEv2 specifies that Extensible Authentication Protocol (EAP)
21    authentication must be used together with responder authentication
22    based on public key signatures.  This is necessary with old EAP
23    methods that provide only unilateral authentication using, e.g., one-
24    time passwords or token cards.
25
26    This document specifies how EAP methods that provide mutual
27    authentication and key agreement can be used to provide extensible
28    responder authentication for IKEv2 based on methods other than public
29    key signatures.
30
31 Status of This Memo
32
33    This is an Internet Standards Track document.
34
35    This document is a product of the Internet Engineering Task Force
36    (IETF).  It represents the consensus of the IETF community.  It has
37    received public review and has been approved for publication by the
38    Internet Engineering Steering Group (IESG).  Further information on
39    Internet Standards is available in Section 2 of RFC 5741.
40
41    Information about the current status of this document, any errata,
42    and how to provide feedback on it may be obtained at
43    http://www.rfc-editor.org/info/rfc5998.
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Eronen, et al.               Standards Track                    [Page 1]
59 \f
60 RFC 5998               Extension for EAP in IKEv2         September 2010
61
62
63 Copyright Notice
64
65    Copyright (c) 2010 IETF Trust and the persons identified as the
66    document authors.  All rights reserved.
67
68    This document is subject to BCP 78 and the IETF Trust's Legal
69    Provisions Relating to IETF Documents
70    (http://trustee.ietf.org/license-info) in effect on the date of
71    publication of this document.  Please review these documents
72    carefully, as they describe your rights and restrictions with respect
73    to this document.  Code Components extracted from this document must
74    include Simplified BSD License text as described in Section 4.e of
75    the Trust Legal Provisions and are provided without warranty as
76    described in the Simplified BSD License.
77
78    This document may contain material from IETF Documents or IETF
79    Contributions published or made publicly available before November
80    10, 2008.  The person(s) controlling the copyright in some of this
81    material may not have granted the IETF Trust the right to allow
82    modifications of such material outside the IETF Standards Process.
83    Without obtaining an adequate license from the person(s) controlling
84    the copyright in such materials, this document may not be modified
85    outside the IETF Standards Process, and derivative works of it may
86    not be created outside the IETF Standards Process, except to format
87    it for publication as an RFC or to translate it into languages other
88    than English.
89
90 1.  Introduction
91
92    The Extensible Authentication Protocol (EAP), defined in [RFC3748],
93    is an authentication framework that supports multiple authentication
94    mechanisms.  Today, EAP has been implemented at end hosts and routers
95    that connect via switched circuits or dial-up lines using PPP
96    [RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11
97    wireless access points [IEEE80211i].
98
99    One of the advantages of the EAP architecture is its flexibility.
100    EAP is used to select a specific authentication mechanism, typically
101    after the authenticator requests more information in order to
102    determine the specific authentication method to be used.  Rather than
103    requiring the authenticator (e.g., wireless LAN access point) to be
104    updated to support each new authentication method, EAP permits the
105    use of a backend authentication server that may implement some or all
106    authentication methods.
107
108
109
110
111
112
113
114 Eronen, et al.               Standards Track                    [Page 2]
115 \f
116 RFC 5998               Extension for EAP in IKEv2         September 2010
117
118
119    IKEv2 ([RFC4306] and [RFC5996]) is a component of IPsec used for
120    performing mutual authentication and establishing and maintaining
121    Security Associations (SAs) for IPsec ESP and Authentication Header
122    (AH).  In addition to supporting authentication using public key
123    signatures and shared secrets, IKEv2 also supports EAP
124    authentication.
125
126    IKEv2 provides EAP authentication since it was recognized that public
127    key signatures and shared secrets are not flexible enough to meet the
128    requirements of many deployment scenarios.  By using EAP, IKEv2 can
129    leverage existing authentication infrastructure and credential
130    databases, since EAP allows users to choose a method suitable for
131    existing credentials, and also makes separation of the IKEv2
132    responder (VPN gateway) from the EAP authentication endpoint (backend
133    Authentication, Authorization, and Accounting (AAA) server) easier.
134
135    Some older EAP methods are designed for unilateral authentication
136    only (that is, EAP peer to EAP server).  These methods are used in
137    conjunction with IKEv2 public-key-based authentication of the
138    responder to the initiator.  It is expected that this approach is
139    especially useful for "road warrior" VPN gateways that use, for
140    instance, one-time passwords or token cards to authenticate the
141    clients.
142
143    However, most newer EAP methods, such as those typically used with
144    IEEE 802.11i wireless LANs, provide mutual authentication and key
145    agreement.  Currently, IKEv2 specifies that these EAP methods must
146    also be used together with responder authentication based on public
147    key signatures.
148
149    In order for the public key signature authentication of the gateway
150    to be effective, a deployment of Public Key Infrastructure (PKI) is
151    required, which has to include management of trust anchors on all
152    supplicants.  In many environments, this is not realistic, and the
153    security of the gateway public key is the same as the security of a
154    self-signed certificate.  Mutually authenticating EAP methods alone
155    can provide a sufficient level of security in many circumstances, and
156    in fact, in some deployments, IEEE 802.11i uses EAP without any PKI
157    for authenticating the Wireless Local Area Network (WLAN) access
158    points.
159
160    This document specifies how EAP methods that offer mutual
161    authentication and key agreement can be used to provide responder
162    authentication in IKEv2 completely based on EAP.
163
164
165
166
167
168
169
170 Eronen, et al.               Standards Track                    [Page 3]
171 \f
172 RFC 5998               Extension for EAP in IKEv2         September 2010
173
174
175 1.1.  Terminology
176
177    All notation in this protocol extension is taken from [RFC4306].
178
179    Numbered messages refer to the IKEv2 message sequence when using EAP.
180
181    Thus:
182
183    o  Message 1 is the request message of IKE_SA_INIT.
184
185    o  Message 2 is the response message of IKE_SA_INIT.
186
187    o  Message 3 is the first request of IKE_AUTH.
188
189    o  Message 4 is the first response of IKE_AUTH.
190
191    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
192    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
193    document are to be interpreted as described in [RFC2119].
194
195 2.  Scenarios
196
197    In this section, we describe two scenarios for extensible
198    authentication within IKEv2.  These scenarios are intended to be
199    illustrative examples rather than specifying how things should be
200    done.
201
202    Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
203    are co-located.  Authenticating the IKEv2 responder using both EAP
204    and public key signatures is redundant.  Offering EAP-based
205    authentication has the advantage that multiple different
206    authentication and key exchange protocols are available with EAP with
207    different security properties (such as strong password-based
208    protocols, protocols offering user identity confidentiality, and many
209    more).
210
211           +------+-----+                            +------------+
212      O    |   IKEv2    |                            |   IKEv2    |
213     /|\   | Initiator  |<---////////////////////--->| Responder  |
214     / \   +------------+          IKEv2             +------------+
215     User  |  EAP Peer  |          Exchange          | EAP Server |
216           +------------+                            +------------+
217
218              Figure 1: EAP and IKEv2 Endpoints Are Co-Located
219
220    Figure 2 shows a typical corporate network access scenario.  The
221    initiator (client) interacts with the responder (VPN gateway) in the
222    corporate network.  The EAP exchange within IKE runs between the
223
224
225
226 Eronen, et al.               Standards Track                    [Page 4]
227 \f
228 RFC 5998               Extension for EAP in IKEv2         September 2010
229
230
231    client and the home AAA server.  As a result of a successful EAP
232    authentication protocol run, session keys are established and sent
233    from the AAA server to the VPN gateway, and then used to authenticate
234    the IKEv2 SA with AUTH payloads.
235
236    The protocol used between the VPN gateway and AAA server could be,
237    for instance, Diameter [RFC4072] or RADIUS [RFC3579].  See Section 6
238    for related security considerations.
239
240                                 +-------------------------------+
241                                 |       Corporate network       |
242                                 |                               |
243                            +-----------+            +--------+  |
244                            |   IKEv2   |     AAA    |  Home  |  |
245      IKEv2      +////----->+ Responder +<---------->+  AAA   |  |
246      Exchange   /          | (VPN GW)  |  (RADIUS/  | Server |  |
247                 /          +-----------+  Diameter) +--------+  |
248                 /               |        carrying EAP           |
249                 |               |                               |
250                 |               +-------------------------------+
251                 v
252          +------+-----+
253      o   |   IKEv2    |
254     /|\  | Initiator  |
255     / \  | VPN client |
256    User  +------------+
257
258                     Figure 2: Corporate Network Access
259
260 3.  Solution
261
262    IKEv2 specifies that when the EAP method establishes a shared secret
263    key, that key is used by both the initiator and responder to generate
264    an AUTH payload (thus authenticating the IKEv2 SA set up by messages
265    1 and 2).
266
267    When used together with public key responder authentication, the
268    responder is, in effect, authenticated using two different methods:
269    the public key signature AUTH payload in message 4, and the EAP-based
270    AUTH payload later.
271
272    If the initiator does not wish to use public-key-based responder
273    authentication, it includes an EAP_ONLY_AUTHENTICATION notification
274    payload (16417) in message 3.  The Protocol ID and Security Parameter
275    Index (SPI) size fields are set to zero, and there is no additional
276    data associated with this notification.
277
278
279
280
281
282 Eronen, et al.               Standards Track                    [Page 5]
283 \f
284 RFC 5998               Extension for EAP in IKEv2         September 2010
285
286
287    If the responder supports this notification and chooses to use it, it
288    omits the public-key-based AUTH payload and CERT payloads from
289    message 4.
290
291    If the responder does not support the EAP_ONLY_AUTHENTICATION
292    notification or does not wish to use it, it ignores the notification
293    payload, and includes the AUTH payload in message 4.  In this case,
294    the initiator MUST verify that payload and any associated
295    certificates, as per [RFC4306].
296
297    When receiving message 4, the initiator MUST verify that the proposed
298    EAP method is allowed by this specification, and MUST abort the
299    protocol immediately otherwise.
300
301    Both the initiator and responder MUST verify that the EAP method
302    actually used provided mutual authentication and established a shared
303    secret key.  The AUTH payloads sent after EAP Success MUST use the
304    EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Section 2.15
305    of [RFC5996]).
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Eronen, et al.               Standards Track                    [Page 6]
339 \f
340 RFC 5998               Extension for EAP in IKEv2         September 2010
341
342
343    An IKEv2 message exchange with this modification is shown below:
344
345       Initiator                   Responder
346      -----------                 -----------
347       HDR, SAi1, KEi, Ni,
348            [N(NAT_DETECTION_SOURCE_IP),
349             N(NAT_DETECTION_DESTINATION_IP)]  -->
350
351                             <--   HDR, SAr1, KEr, Nr, [CERTREQ],
352                                        [N(NAT_DETECTION_SOURCE_IP),
353                                         N(NAT_DETECTION_DESTINATION_IP)]
354
355       HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
356                 N(EAP_ONLY_AUTHENTICATION),
357                 [CP(CFG_REQUEST)] }  -->
358
359                             <--   HDR, SK { IDr, EAP(Request) }
360
361       HDR, SK { EAP(Response) }  -->
362
363                             <--   HDR, SK { EAP(Request) }
364
365       HDR, SK { EAP(Response) }  -->
366
367                             <--   HDR, SK { EAP(Success) }
368
369       HDR, SK { AUTH }  -->
370
371                             <--   HDR, SK { AUTH, SAr2, TSi, TSr,
372                                             [CP(CFG_REPLY] }
373
374    Note: all notation in the above protocol sequence and elsewhere in
375    this specification is as defined in [RFC4306], and see in particular
376    Sec. 1.2 of [RFC4306] for payload types.
377
378    The NAT detection and Configuration payloads are shown for
379    informative purposes only; they do not change how EAP authentication
380    works.
381
382    An IKE SA that was set up with this extension can be resumed using
383    the mechanism described in [RFC5723].  However, session resumption
384    does not change the authentication method.  Therefore, during the
385    IKE_AUTH exchange of the resumed session, this extension MUST NOT be
386    sent by the initiator.
387
388
389
390
391
392
393
394 Eronen, et al.               Standards Track                    [Page 7]
395 \f
396 RFC 5998               Extension for EAP in IKEv2         September 2010
397
398
399 4.  Safe EAP Methods
400
401    EAP methods to be used with this extension MUST have the following
402    properties:
403
404    1.  The method provides mutual authentication of the peers.
405
406    2.  The method is key-generating.
407
408    3.  The method is resistant to dictionary attacks.
409
410    The authors believe that the following EAP methods are secure when
411    used with the current extension.  The list is not inclusive, and
412    there are likely other safe methods that have not been listed here.
413
414    +-------------------------------+-------------------+---------------+
415    | Method Name                   | Allows Channel    | Reference     |
416    |                               | Binding?          |               |
417    +-------------------------------+-------------------+---------------+
418    | EAP-SIM                       | No                | [RFC4186]     |
419    | EAP-AKA                       | Yes               | [RFC4187]     |
420    | EAP-AKA'                      | Yes               | [RFC5448]     |
421    | EAP-GPSK                      | Yes               | [RFC5433]     |
422    | EAP-pwd                       | No                | [RFC5931]     |
423    | EAP-EKE                       | Yes               | [EMU-EAP-EKE] |
424    | EAP-PAX                       | Yes               | [RFC4746]     |
425    | EAP-SAKE                      | No                | [RFC4763]     |
426    | EAP-SRP                       | No                | [EAP-SRP]     |
427    | EAP-POTP (mutual              | Yes               | [RFC4793]     |
428    | authentication variant)       |                   |               |
429    | EAP-TLS                       | No                | [RFC5216]     |
430    | EAP-FAST                      | No                | [RFC4851]     |
431    | EAP-TTLS                      | No                | [RFC5281]     |
432    +-------------------------------+-------------------+---------------+
433
434    The "Allows channel binding?" column denotes protocols where
435    protected identity information may be sent between the EAP endpoints.
436    This third, optional property of the method provides protection
437    against certain types of attacks (see Section 6.2 for an
438    explanation), and therefore in some scenarios, methods that allow for
439    channel binding are to be preferred.  It is noted that at the time of
440    writing, even when such capabilities are provided, they are not fully
441    specified in an interoperable manner.  In particular, no RFC
442    specifies what identities should be sent under the protection of the
443    channel binding mechanism, or what policy is to be used to correlate
444    identities at the different layers.
445
446
447
448
449
450 Eronen, et al.               Standards Track                    [Page 8]
451 \f
452 RFC 5998               Extension for EAP in IKEv2         September 2010
453
454
455 5.  IANA Considerations
456
457    This document defines a new IKEv2 Notification Payload type,
458    EAP_ONLY_AUTHENTICATION, described in Section 3.  This payload has
459    been assigned the type number 16417 from the "Status Types" range.
460
461 6.  Security Considerations
462
463    Security considerations applicable to all EAP methods are discussed
464    in [RFC3748].  The EAP Key Management Framework [RFC5247] deals with
465    issues that arise when EAP is used as a part of a larger system.
466
467 6.1.  Authentication of IKEv2 SA
468
469    It is important to note that the IKEv2 SA is not authenticated by
470    just running an EAP conversation: the crucial step is the AUTH
471    payload based on the EAP-generated key.  Thus, EAP methods that do
472    not provide mutual authentication or establish a shared secret key
473    MUST NOT be used with the modifications presented in this document.
474
475 6.2.  Authentication with Separated IKEv2 Responder / EAP Server
476
477    As described in Section 2, the EAP conversation can terminate either
478    at the IKEv2 responder or at a backend AAA server.
479
480    If the EAP method is terminated at the IKEv2 responder, then no key
481    transport via the AAA infrastructure is required.  Pre-shared secret
482    and public-key-based authentication offered by IKEv2 is then replaced
483    by a wider range of authentication and key exchange methods.
484
485    However, typically EAP will be used with a backend AAA server.  See
486    [RFC5247] for a more complete discussion of the related security
487    issues; here we provide only a short summary.
488
489    When a backend server is used, there are actually two authentication
490    exchanges: the EAP method between the client and the AAA server, and
491    another authentication between the AAA server and IKEv2 gateway.  The
492    AAA server authenticates the client using the selected EAP method,
493    and they establish a session key.  The AAA server then sends this key
494    to the IKEv2 gateway over a connection authenticated using, e.g.,
495    IPsec or Transport Layer Security (TLS).
496
497    Some EAP methods do not have any concept of pass-through
498    authenticator (e.g., Network Access Server (NAS) or IKEv2 gateway)
499    identity, and these two authentications remain quite independent of
500    each other.  That is, after the client has verified the AUTH payload
501    sent by the IKEv2 gateway, it knows that it is talking to SOME
502    gateway trusted by the home AAA server, but not which one.  The
503
504
505
506 Eronen, et al.               Standards Track                    [Page 9]
507 \f
508 RFC 5998               Extension for EAP in IKEv2         September 2010
509
510
511    situation is somewhat similar if a single cryptographic hardware
512    accelerator, containing a single private key, would be shared between
513    multiple IKEv2 gateways (perhaps in some kind of cluster
514    configuration).  In particular, if one of the gateways is
515    compromised, it can impersonate any of the other gateways towards the
516    user (until the compromise is discovered and access rights revoked).
517
518    In some environments it is not desirable to trust the IKEv2 gateways
519    this much (also known as the "Lying NAS Problem").  EAP methods that
520    provide what is called "connection binding" or "channel binding"
521    transport some identity or identities of the gateway (or WLAN access
522    point / NAS) inside the EAP method.  Then the AAA server can check
523    that it is indeed sending the key to the gateway expected by the
524    client.  A potential solution is described in [EAP-SERVICE], see also
525    [EMU-AAAPAY].
526
527    In some deployment configurations, AAA proxies may be present between
528    the IKEv2 gateway and the backend AAA server.  These AAA proxies MUST
529    be trusted for secure operation, and therefore SHOULD be avoided when
530    possible; see Section 2.3.4 of [RFC4072] and Section 4.3.7 of
531    [RFC3579] for more discussion.
532
533 6.3.  Protection of EAP Payloads
534
535    Although the EAP payloads are encrypted and integrity protected with
536    SK_e/SK_a, this does not provide any protection against active
537    attackers.  Until the AUTH payload has been received and verified, a
538    man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
539    modify the EAP payloads.
540
541    In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted
542    nor integrity protected (by the link layer), so EAP methods are
543    typically designed to take that into account.
544
545    In particular, EAP methods that are vulnerable to dictionary attacks
546    when used in WLANs are still vulnerable (to active attackers) when
547    run inside IKEv2.
548
549    The rules in Section 4 are designed to avoid this potential
550    vulnerability.
551
552
553
554
555
556
557
558
559
560
561
562 Eronen, et al.               Standards Track                   [Page 10]
563 \f
564 RFC 5998               Extension for EAP in IKEv2         September 2010
565
566
567 6.4.  Identities and Authenticated Identities
568
569    When using this protocol, each of the peers sends two identity
570    values:
571
572    1.  An identity contained in the IKE ID payload.
573
574    2.  An identity transferred within the specific EAP method's
575        messages.
576
577    (IKEv2 omits the EAP Identity request/response pair, see Section 3.16
578    of [RFC5996].)  The first identity value can be used by the recipient
579    to route AAA messages and/or to select authentication and EAP types.
580    But it is only the second identity that is directly authenticated by
581    the EAP method.  The reader is referred to Section 2.16 of [RFC5996]
582    regarding the need to base IPsec policy decisions on the
583    authenticated identity.  In the context of the extension described
584    here, this guidance on IPsec policy applies both to the
585    authentication of the client by the gateway and vice versa.
586
587 6.5.  User Identity Confidentiality
588
589    IKEv2 provides confidentiality for the initiator identity against
590    passive eavesdroppers, but not against active attackers.  The
591    initiator announces its identity first (in message 3), before the
592    responder has been authenticated.  The usage of EAP in IKEv2 does not
593    change this situation, since the ID payload in message 3 is used
594    instead of the EAP Identity Request/Response exchange.  This is
595    somewhat unfortunate since when EAP is used with public key
596    authentication of the responder, it would be possible to provide
597    active user identity confidentiality for the initiator.
598
599    IKEv2 protects the responder's identity even against active attacks.
600    This property cannot be provided when using EAP.  If public key
601    responder authentication is used in addition to EAP, the responder
602    reveals its identity before authenticating the initiator.  If only
603    EAP is used (as proposed in this document), the situation depends on
604    the EAP method used (in some EAP methods, the server reveals its
605    identity first).
606
607    Hence, if active user identity confidentiality for the responder is
608    required then EAP methods that offer this functionality have to be
609    used (see [RFC3748], Section 7.3).
610
611
612
613
614
615
616
617
618 Eronen, et al.               Standards Track                   [Page 11]
619 \f
620 RFC 5998               Extension for EAP in IKEv2         September 2010
621
622
623 7.  Acknowledgments
624
625    This document borrows some text from [RFC3748], [RFC4306], and
626    [RFC4072].  We would also like to thank Hugo Krawczyk for interesting
627    discussions about this topic, Dan Harkins, and David Harrington for
628    their comments.
629
630 8.  References
631
632 8.1.  Normative References
633
634    [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
635                   Requirement Levels", BCP 14, RFC 2119, March 1997.
636
637    [RFC3748]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
638                   H. Levkowetz, "Extensible Authentication Protocol
639                   (EAP)", RFC 3748, June 2004.
640
641    [RFC4306]      Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
642                   RFC 4306, December 2005.
643
644    [RFC5723]      Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
645                   Protocol Version 2 (IKEv2) Session Resumption",
646                   RFC 5723, January 2010.
647
648    [RFC5996]      Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
649                   "Internet Key Exchange Protocol Version 2 (IKEv2)",
650                   RFC 5996, September 2010.
651
652 8.2.  Informative References
653
654    [EAP-SERVICE]  Arkko, J. and P. Eronen, "Authenticated Service
655                   Information for the Extensible Authentication Protocol
656                   (EAP)", Work in Progress, October 2005.
657
658    [EAP-SRP]      Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-
659                   SHA1 Authentication Protocol", Work in Progress,
660                   July 2001.
661
662    [EMU-AAAPAY]   Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP
663                   Method Support for Transporting AAA Payloads", Work
664                   in Progress, May 2010.
665
666    [EMU-EAP-EKE]  Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer,
667                   "An EAP Authentication Method Based on the EKE
668                   Protocol", Work in Progress, August 2010.
669
670
671
672
673
674 Eronen, et al.               Standards Track                   [Page 12]
675 \f
676 RFC 5998               Extension for EAP in IKEv2         September 2010
677
678
679    [IEEE80211i]   Institute of Electrical and Electronics Engineers,
680                   "IEEE Standard for Information technology -
681                   Telecommunications and information exchange between
682                   systems - Local and metropolitan area networks -
683                   Specific requirements - Part 11: Wireless Medium
684                   Access Control (MAC) and Physical Layer (PHY)
685                   specifications: Amendment 6: Medium Access Control
686                   (MAC) Security Enhancements", IEEE Standard 802.11i-
687                   2004, July 2004.
688
689    [IEEE8021X]    Institute of Electrical and Electronics Engineers,
690                   "Local and Metropolitan Area Networks: Port-Based
691                   Network Access Control", IEEE Standard 802.1X-2001,
692                   2001.
693
694    [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)",
695                   STD 51, RFC 1661, July 1994.
696
697    [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
698                   Authentication Dial In User Service) Support For
699                   Extensible Authentication Protocol (EAP)", RFC 3579,
700                   September 2003.
701
702    [RFC4072]      Eronen, P., Hiller, T., and G. Zorn, "Diameter
703                   Extensible Authentication Protocol (EAP) Application",
704                   RFC 4072, August 2005.
705
706    [RFC4186]      Haverinen, H. and J. Salowey, "Extensible
707                   Authentication Protocol Method for Global System for
708                   Mobile Communications (GSM) Subscriber Identity
709                   Modules (EAP-SIM)", RFC 4186, January 2006.
710
711    [RFC4187]      Arkko, J. and H. Haverinen, "Extensible Authentication
712                   Protocol Method for 3rd Generation Authentication and
713                   Key Agreement (EAP-AKA)", RFC 4187, January 2006.
714
715    [RFC4746]      Clancy, T. and W. Arbaugh, "Extensible Authentication
716                   Protocol (EAP) Password Authenticated Exchange",
717                   RFC 4746, November 2006.
718
719    [RFC4763]      Vanderveen, M. and H. Soliman, "Extensible
720                   Authentication Protocol Method for Shared-secret
721                   Authentication and Key Establishment (EAP-SAKE)",
722                   RFC 4763, November 2006.
723
724    [RFC4793]      Nystroem, M., "The EAP Protected One-Time Password
725                   Protocol (EAP-POTP)", RFC 4793, February 2007.
726
727
728
729
730 Eronen, et al.               Standards Track                   [Page 13]
731 \f
732 RFC 5998               Extension for EAP in IKEv2         September 2010
733
734
735    [RFC4851]      Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
736                   "The Flexible Authentication via Secure Tunneling
737                   Extensible Authentication Protocol Method (EAP-FAST)",
738                   RFC 4851, May 2007.
739
740    [RFC5216]      Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
741                   Authentication Protocol", RFC 5216, March 2008.
742
743    [RFC5247]      Aboba, B., Simon, D., and P. Eronen, "Extensible
744                   Authentication Protocol (EAP) Key Management
745                   Framework", RFC 5247, August 2008.
746
747    [RFC5281]      Funk, P. and S. Blake-Wilson, "Extensible
748                   Authentication Protocol Tunneled Transport Layer
749                   Security Authenticated Protocol Version 0 (EAP-
750                   TTLSv0)", RFC 5281, August 2008.
751
752    [RFC5433]      Clancy, T. and H. Tschofenig, "Extensible
753                   Authentication Protocol - Generalized Pre-Shared Key
754                   (EAP-GPSK) Method", RFC 5433, February 2009.
755
756    [RFC5448]      Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
757                   Extensible Authentication Protocol Method for 3rd
758                   Generation Authentication and Key Agreement (EAP-
759                   AKA')", RFC 5448, May 2009.
760
761    [RFC5931]      Harkins, D. and G. Zorn, "Extensible Authentication
762                   Protocol (EAP) Authentication Using Only A Password",
763                   RFC 5931, August 2010.
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Eronen, et al.               Standards Track                   [Page 14]
787 \f
788 RFC 5998               Extension for EAP in IKEv2         September 2010
789
790
791 Appendix A.  Alternative Approaches
792
793    In this section, we list alternatives that have been considered
794    during the work on this document.  We concluded that the solution
795    presented in Section 3 seems to fit better into IKEv2.
796
797 A.1.  Ignore AUTH Payload at the Initiator
798
799    With this approach, the initiator simply ignores the AUTH payload in
800    message 4 (but obviously must check the second AUTH payload later!).
801    The main advantage of this approach is that no protocol modifications
802    are required and no signature verification is required.  A
803    significant disadvantage is that the EAP method to be used cannot be
804    selected to take this behavior into account.
805
806    The initiator could signal to the responder (using a notification
807    payload) that it did not verify the first AUTH payload.
808
809 A.2.  Unauthenticated Public Keys in AUTH Payload (Message 4)
810
811    Another solution approach suggests the use of unauthenticated public
812    keys in the public key signature AUTH payload (for message 4).
813
814    That is, the initiator verifies the signature in the AUTH payload,
815    but does not verify that the public key indeed belongs to the
816    intended party (using certificates) -- since it doesn't have a PKI
817    that would allow this.  This could be used with X.509 certificates
818    (the initiator ignores all other fields of the certificate except the
819    public key), or "Raw RSA Key" CERT payloads.
820
821    This approach has the advantage that initiators that wish to perform
822    certificate-based responder authentication (in addition to EAP) may
823    do so, without requiring the responder to handle these cases
824    separately.  A disadvantage here, again, is that the EAP method
825    selection cannot take into account the incomplete validation of the
826    responder's certificate.
827
828    If using RSA, the overhead of signature verification is quite small,
829    compared to the g^xy calculation required by the Diffie-Hellman
830    exchange.
831
832 A.3.  Using EAP Derived Session Keys for IKEv2
833
834    It has been proposed that when using an EAP method that provides
835    mutual authentication and key agreement, the IKEv2 Diffie-Hellman
836    exchange could also be omitted.  This would mean that the session
837    keys for IPsec SAs established later would rely only on EAP-provided
838    keys.
839
840
841
842 Eronen, et al.               Standards Track                   [Page 15]
843 \f
844 RFC 5998               Extension for EAP in IKEv2         September 2010
845
846
847    It seems the only benefit of this approach is saving some computation
848    time (g^xy calculation).  This approach requires designing a
849    completely new protocol (which would not resemble IKEv2 anymore); we
850    do not believe that it should be considered.  Nevertheless, we
851    include it for completeness.
852
853 Authors' Addresses
854
855    Pasi Eronen
856    Independent
857
858    EMail: pe@iki.fi
859
860
861    Hannes Tschofenig
862    Nokia Siemens Networks
863    Linnoitustie 6
864    Espoo  02600
865    Finland
866
867    Phone: +358 (50) 4871445
868    EMail: Hannes.Tschofenig@gmx.net
869    URI:   http://www.tschofenig.priv.at
870
871
872    Yaron Sheffer
873    Independent
874
875    EMail: yaronf.ietf@gmail.com
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898 Eronen, et al.               Standards Track                   [Page 16]
899 \f