added support for %prompt-ing private key passhprases in strokes "ipsec secrets"
[strongswan.git] / doc / standards / draft-eronen-ipsec-ikev2-eap-auth-05.txt
1
2
3
4 Network Working Group                                          P. Eronen
5 Internet-Draft                                                     Nokia
6 Expires: December 28, 2006                                 H. Tschofenig
7                                                                  Siemens
8                                                            June 26, 2006
9
10
11                Extension for EAP Authentication in IKEv2
12                 draft-eronen-ipsec-ikev2-eap-auth-05.txt
13
14 Status of this Memo
15
16    By submitting this Internet-Draft, each author represents that any
17    applicable patent or other IPR claims of which he or she is aware
18    have been or will be disclosed, and any of which he or she becomes
19    aware will be disclosed, in accordance with Section 6 of BCP 79.
20
21    Internet-Drafts are working documents of the Internet Engineering
22    Task Force (IETF), its areas, and its working groups.  Note that
23    other groups may also distribute working documents as Internet-
24    Drafts.
25
26    Internet-Drafts are draft documents valid for a maximum of six months
27    and may be updated, replaced, or obsoleted by other documents at any
28    time.  It is inappropriate to use Internet-Drafts as reference
29    material or to cite them other than as "work in progress."
30
31    The list of current Internet-Drafts can be accessed at
32    http://www.ietf.org/ietf/1id-abstracts.txt.
33
34    The list of Internet-Draft Shadow Directories can be accessed at
35    http://www.ietf.org/shadow.html.
36
37    This Internet-Draft will expire on December 28, 2006.
38
39 Copyright Notice
40
41    Copyright (C) The Internet Society (2006).
42
43 Abstract
44
45    IKEv2 specifies that EAP authentication must be used together with
46    public key signature based responder authentication.  This is
47    necessary with old EAP methods that provide only unilateral
48    authentication using, e.g., one-time passwords or token cards.
49
50    This document specifies how EAP methods that provide mutual
51    authentication and key agreement can be used to provide extensible
52
53
54
55 Eronen & Tschofenig     Expires December 28, 2006               [Page 1]
56 \f
57 Internet-Draft         Extension for EAP in IKEv2              June 2006
58
59
60    responder authentication for IKEv2 based on other methods than public
61    key signatures.
62
63
64 1.  Introduction
65
66    The Extensible Authentication Protocol (EAP), defined in [4], is an
67    authentication framework which supports multiple authentication
68    mechanisms.  Today, EAP has been implemented at end hosts and routers
69    that connect via switched circuits or dial-up lines using PPP [13],
70    IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
71    [11].
72
73    One of the advantages of the EAP architecture is its flexibility.
74    EAP is used to select a specific authentication mechanism, typically
75    after the authenticator requests more information in order to
76    determine the specific authentication method to be used.  Rather than
77    requiring the authenticator (e.g., wireless LAN access point) to be
78    updated to support each new authentication method, EAP permits the
79    use of a backend authentication server which may implement some or
80    all authentication methods.
81
82    IKEv2 [3] is a component of IPsec used for performing mutual
83    authentication and establishing and maintaining security associations
84    for IPsec ESP and AH.  In addition to supporting authentication using
85    public key signatures and shared secrets, IKEv2 also supports EAP
86    authentication.
87
88    IKEv2 provides EAP authentication since it was recognized that public
89    key signatures and shared secrets are not flexible enough to meet the
90    requirements of many deployment scenarios.  By using EAP, IKEv2 can
91    leverage existing authentication infrastructure and credential
92    databases, since EAP allows users to choose a method suitable for
93    existing credentials, and also makes separation of the IKEv2
94    responder (VPN gateway) from the EAP authentication endpoint (backend
95    AAA server) easier.
96
97    Some older EAP methods are designed for unilateral authentication
98    only (that is, EAP peer to EAP server).  These methods are used in
99    conjunction with IKEv2 public key based authentication of the
100    responder to the initiator.  It is expected that this approach is
101    especially useful for "road warrior" VPN gateways that use, for
102    instance, one-time passwords or token cards to authenticate the
103    clients.
104
105    However, most newer EAP methods, such as those typically used with
106    IEEE 802.11i wireless LANs, provide mutual authentication and key
107    agreement.  Currently, IKEv2 specifies that also these EAP methods
108
109
110
111 Eronen & Tschofenig     Expires December 28, 2006               [Page 2]
112 \f
113 Internet-Draft         Extension for EAP in IKEv2              June 2006
114
115
116    must be used together with public key signature based responder
117    authentication.
118
119    In some environments, requiring the deployment of PKI for just this
120    purpose can be counterproductive.  Deploying new infrastructure can
121    be expensive, and it may weaken security by creating new
122    vulnerabilities.  Mutually authenticating EAP methods alone can
123    provide a sufficient level of security in many circumstances, and
124    indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
125    WLAN access points.
126
127    This document specifies how EAP methods that offer mutual
128    authentication and key agreement can be used to provide responder
129    authentication in IKEv2 completely based on EAP.
130
131 1.1.  Terminology
132
133    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135    document are to be interpreted as described in [2].
136
137
138 2.  Scenarios
139
140    In this section we describe two scenarios for extensible
141    authentication within IKEv2.  These scenarios are intended to be
142    illustrative examples rather than specifying how things should be
143    done.
144
145    Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
146    are co-located.  Authenticating the IKEv2 responder using both EAP
147    and public key signatures is redundant.  Offering EAP based
148    authentication has the advantage that multiple different
149    authentication and key exchange protocols are available with EAP with
150    different security properties (such as strong password based
151    protocols, protocols offering user identity confidentiality and many
152    more).  As an example it is possible to use GSS-API support within
153    EAP [6] to support Kerberos based authentication which effectively
154    replaces the need for KINK [14].
155
156           +------+-----+                            +------------+
157      O    |   IKEv2    |                            |   IKEv2    |
158     /|\   | Initiator  |<---////////////////////--->| Responder  |
159     / \   +------------+          IKEv2             +------------+
160     User  |  EAP Peer  |          Exchange          | EAP Server |
161           +------------+                            +------------+
162
163    Figure 1: EAP and IKEv2 endpoints are co-located
164
165
166
167 Eronen & Tschofenig     Expires December 28, 2006               [Page 3]
168 \f
169 Internet-Draft         Extension for EAP in IKEv2              June 2006
170
171
172    Figure 2 shows a typical corporate network access scenario.  The
173    initiator (client) interacts with the responder (VPN gateway) in the
174    corporate network.  The EAP exchange within IKE runs between the
175    client and the home AAA server.  As a result of a successful EAP
176    authentication protocol run, session keys are established and sent
177    from the AAA server to the VPN gateway, and then used to authenticate
178    the IKEv2 SA with AUTH payloads.
179
180    The protocol used between the VPN gateway and AAA server could be,
181    for instance, Diameter [4] or RADIUS [5].  See Section 5 for related
182    security considerations.
183
184                                 +-------------------------------+
185                                 |       Corporate network       |
186                                 |                               |
187                            +-----------+            +--------+  |
188                            |   IKEv2   |     AAA    |  Home  |  |
189      IKEv2      +////----->+ Responder +<---------->+  AAA   |  |
190      Exchange   /          | (VPN GW)  |  (RADIUS/  | Server |  |
191                 /          +-----------+  Diameter) +--------+  |
192                 /               |        carrying EAP           |
193                 |               |                               |
194                 |               +-------------------------------+
195                 v
196          +------+-----+
197      o   |   IKEv2    |
198     /|\  | Initiator  |
199     / \  | VPN client |
200    User  +------------+
201
202    Figure 2: Corporate Network Access
203
204
205 3.  Solution
206
207    IKEv2 specifies that when the EAP method establishes a shared secret
208    key, that key is used by both the initiator and responder to generate
209    an AUTH payload (thus authenticating the IKEv2 SA set up by messages
210    1 and 2).
211
212    When used together with public key responder authentication, the
213    responder is in effect authenticated using two different methods: the
214    public key signature AUTH payload in message 4, and the EAP-based
215    AUTH payload later.
216
217    If the initiator does not wish to use public key based responder
218    authentication, it includes an EAP_ONLY_AUTHENTICATION notification
219    payload (type TBD-BY-IANA) in message 3.  The SPI size field is set
220
221
222
223 Eronen & Tschofenig     Expires December 28, 2006               [Page 4]
224 \f
225 Internet-Draft         Extension for EAP in IKEv2              June 2006
226
227
228    to zero, and there is no additional data associated with this
229    notification.
230
231    If the responder supports this notification, it omits the public key
232    based AUTH payload and CERT payloads from message 4.
233
234    If the responder does not support the EAP_ONLY_AUTHENTICATION
235    notification, it ignores the notification payload, and includes the
236    AUTH payload in message 4.  In this case the initiator can, based on
237    its local policy, choose to either ignore the AUTH payload, or verify
238    it and any associated certificates as usual.
239
240    Both the initiator and responder MUST verify that the EAP method
241    actually used provided mutual authentication and established a shared
242    secret key.  The AUTH payloads sent after EAP Success MUST use the
243    EAP-generated key, and MUST NOT use SK_pi or SK_pr.
244
245    An IKEv2 message exchange with this modification is shown below:
246
247
248       Initiator                   Responder
249      -----------                 -----------
250       HDR, SAi1, KEi, Ni,
251            [N(NAT_DETECTION_SOURCE_IP),
252             N(NAT_DETECTION_DESTINATION_IP)]  -->
253
254                             <--   HDR, SAr1, KEr, Nr, [CERTREQ],
255                                        [N(NAT_DETECTION_SOURCE_IP),
256                                         N(NAT_DETECTION_DESTINATION_IP)]
257
258       HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
259                 N(EAP_ONLY_AUTHENTICATION),
260                 [CP(CFG_REQUEST)] }  -->
261
262                             <--   HDR, SK { IDr, EAP(Request) }
263
264       HDR, SK { EAP(Response) }  -->
265
266                             <--   HDR, SK { EAP(Request) }
267
268       HDR, SK { EAP(Response) }  -->
269
270                             <--   HDR, SK { EAP(Success) }
271
272       HDR, SK { AUTH }  -->
273
274                             <--   HDR, SK { AUTH, SAr2, TSi, TSr,
275                                             [CP(CFG_REPLY] }
276
277
278
279 Eronen & Tschofenig     Expires December 28, 2006               [Page 5]
280 \f
281 Internet-Draft         Extension for EAP in IKEv2              June 2006
282
283
284    The NAT detection and Configuration payloads are shown for
285    informative purposes only; they do not change how EAP authentication
286    works.
287
288
289 4.  IANA considerations
290
291    This document defines a new IKEv2 Notification Payload type,
292    EAP_ONLY_AUTHENTICATION, described in Section 3.  This payload must
293    be assigned a new type number from the "status types" range.
294
295    This document does not define any new namespaces to be managed by
296    IANA.
297
298
299 5.  Security Considerations
300
301    Security considerations applicable to all EAP methods are discussed
302    in [1].  The EAP Key Management Framework [7] deals with issues that
303    arise when EAP is used as a part of a larger system.
304
305 5.1.  Authentication of IKEv2 SA
306
307    It is important to note that the IKEv2 SA is not authenticated by
308    just running an EAP conversation: the crucial step is the AUTH
309    payload based on the EAP-generated key.  Thus, EAP methods that do
310    not provide mutual authentication or establish a shared secret key
311    MUST NOT be used with the modifications presented in this document.
312
313 5.2.  Authentication with separated IKEv2 responder/EAP server
314
315    As described in Section 2, the EAP conversation can terminate either
316    at the IKEv2 responder or at a backend AAA server.
317
318    If the EAP method terminates at the IKEv2 responder then no key
319    transport via the AAA infrastructure is required.  Pre-shared secret
320    and public key based authentication offered by IKEv2 is then replaced
321    by a wider range of authentication and key exchange methods.
322
323    However, typically EAP will be used with a backend AAA server.  See
324    [7] for a more complete discussion of the related security issues;
325    here we provide only a short summary.
326
327    When a backend server is used, there are actually two authentication
328    exchanges: the EAP method between the client and the AAA server, and
329    another authentication between the AAA server and IKEv2 gateway.  The
330    AAA server authenticates the client using the selected EAP method,
331    and they establish a session key.  The AAA server then sends this key
332
333
334
335 Eronen & Tschofenig     Expires December 28, 2006               [Page 6]
336 \f
337 Internet-Draft         Extension for EAP in IKEv2              June 2006
338
339
340    to the IKEv2 gateway over a connection authenticated using, e.g.,
341    IPsec or TLS.
342
343    Some EAP methods do not have any concept of pass-through
344    authenticator (e.g., NAS or IKEv2 gateway) identity, and these two
345    authentications remain quite independent of each other.  That is,
346    after the client has verified the AUTH payload sent by the IKEv2
347    gateway, it knows that it is talking to SOME gateway trusted by the
348    home AAA server, but not which one.  The situation is somewhat
349    similar if a single cryptographic hardware accelerator, containing a
350    single private key, would be shared between multiple IKEv2 gateways
351    (perhaps in some kind of cluster configuration).  In particular, if
352    one of the gateways is compromised, it can impersonate any of the
353    other gateways towards the user (until the compromise is discovered
354    and access rights revoked).
355
356    In some environments it is not desirable to trust the IKEv2 gateways
357    this much (also known as the "Lying NAS Problem").  EAP methods that
358    provide what is called "connection binding" or "channel binding"
359    transport some identity or identities of the gateway (or WLAN access
360    point/NAS) inside the EAP method.  Then the AAA server can check that
361    it is indeed sending the key to the gateway expected by the client.
362    A potential solution is described in [16].
363
364    In some deployment configurations, AAA proxies may be present between
365    the IKEv2 gateway and the backend AAA server.  These AAA proxies MUST
366    be trusted for secure operation, and therefore SHOULD be avoided when
367    possible; see [4] and [7] for more discussion.
368
369 5.3.  Protection of EAP payloads
370
371    Although the EAP payloads are encrypted and integrity protected with
372    SK_e/SK_a, this does not provide any protection against active
373    attackers.  Until the AUTH payload has been received and verified, a
374    man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
375    modify the EAP payloads.
376
377    In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
378    integrity protected (by the link layer), so EAP methods are typically
379    designed to take that into account.
380
381    In particular, EAP methods that are vulnerable to dictionary attacks
382    when used in WLANs are still vulnerable (to active attackers) when
383    run inside IKEv2.
384
385 5.4.  User identity confidentiality
386
387    IKEv2 provides confidentiality for the initiator identity against
388
389
390
391 Eronen & Tschofenig     Expires December 28, 2006               [Page 7]
392 \f
393 Internet-Draft         Extension for EAP in IKEv2              June 2006
394
395
396    passive eavesdroppers, but not against active attackers.  The
397    initiator announces its identity first (in message #3), before the
398    responder has been authenticated.  The usage of EAP in IKEv2 does not
399    change this situation, since the ID payload in message #3 is used
400    instead of the EAP Identity Request/Response exchange.  This is
401    somewhat unfortunate since when EAP is used with public key
402    authentication of the responder, it would be possible to provide
403    active user identity confidentiality for the initiator.
404
405    IKEv2 protects the responder identity even against active attacks.
406    This property cannot be provided when using EAP.  If public key
407    responder authentication is used in addition to EAP, the responder
408    reveals its identity before authenticating the initiator.  If only
409    EAP is used (as proposed in this document), the situation depends on
410    the EAP method used (in some EAP methods, the server reveals its
411    identity first).
412
413    Hence, if active user identity confidentiality for the initiator is
414    required then EAP methods that offer this functionality have to be
415    used (see [1], Section 7.3).
416
417
418 6.  Acknowledgments
419
420    This document borrows some text from [1], [3], and [4].  We would
421    also like to thank Hugo Krawczyk for interesting discussions about
422    this topic.
423
424
425 7.  References
426
427 7.1.  Normative References
428
429    [1]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
430         Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
431         June 2004.
432
433    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
434         Levels", RFC 2119, March 1997.
435
436    [3]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
437         December 2005.
438
439    [4]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
440         Authentication Protocol (EAP) Application", RFC 4072,
441         August 2005.
442
443
444
445
446
447 Eronen & Tschofenig     Expires December 28, 2006               [Page 8]
448 \f
449 Internet-Draft         Extension for EAP in IKEv2              June 2006
450
451
452 7.2.  Informative References
453
454    [5]   Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
455          In User Service) Support For Extensible Authentication Protocol
456          (EAP)", RFC 3579, September 2003.
457
458    [6]   Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
459          draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
460
461    [7]   Aboba, B., "Extensible Authentication Protocol (EAP) Key
462          Management Framework", draft-ietf-eap-keying-13 (work in
463          progress), May 2006.
464
465    [8]   Forsberg, D., "Protocol for Carrying Authentication for Network
466          Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
467          March 2006.
468
469    [9]   Institute of Electrical and Electronics Engineers, "Local and
470          Metropolitan Area Networks: Port-Based Network Access Control",
471          IEEE Standard 802.1X-2001, 2001.
472
473    [10]  Institute of Electrical and Electronics Engineers, "Information
474          technology - Telecommunications and information exchange
475          between systems - Local and metropolitan area networks -
476          Specific Requirements Part 11: Wireless LAN Medium Access
477          Control (MAC) and Physical Layer (PHY) Specifications", IEEE
478          Standard 802.11-1999, 1999.
479
480    [11]  Institute of Electrical and Electronics Engineers, "IEEE
481          Standard for Information technology - Telecommunications and
482          information exchange between systems - Local and metropolitan
483          area networks - Specific requirements - Part 11: Wireless
484          Medium Access Control (MAC) and Physical Layer (PHY)
485          specifications: Amendment 6: Medium Access Control (MAC)
486          Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
487
488    [12]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
489          Authentication Dial In User Service (RADIUS)", RFC 2865,
490          June 2000.
491
492    [13]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
493          RFC 1661, July 1994.
494
495    [14]  Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
496          "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
497          March 2006.
498
499    [15]  Tschofenig, H., "EAP IKEv2 Method",
500
501
502
503 Eronen & Tschofenig     Expires December 28, 2006               [Page 9]
504 \f
505 Internet-Draft         Extension for EAP in IKEv2              June 2006
506
507
508          draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
509
510    [16]  Arkko, J. and P. Eronen, "Authenticated Service Information for
511          the Extensible Authentication Protocol  (EAP)",
512          draft-arkko-eap-service-identity-auth-04 (work in progress),
513          October 2005.
514
515
516 Appendix A.  Alternative Approaches
517
518    In this section we list alternatives which have been considered
519    during the work on this document.  Finally, the solution presented in
520    Section 3 seems to fit better into IKEv2.
521
522 A.1.  Ignore AUTH payload at the initiator
523
524    With this approach, the initiator simply ignores the AUTH payload in
525    message #4 (but obviously must check the second AUTH payload later!).
526    The main advantage of this approach is that no protocol modifications
527    are required and no signature verification is required.
528
529    The initiator could signal the responder (using a NOTIFY payload)
530    that it did not verify the first AUTH payload.
531
532 A.2.  Unauthenticated PKs in AUTH payload (message 4)
533
534    The first solution approach suggests the use of unauthenticated
535    public keys in the public key signature AUTH payload (for message 4).
536
537    That is, the initiator verifies the signature in the AUTH payload,
538    but does not verify that the public key indeed belongs to the
539    intended party (using certificates)--since it doesn't have a PKI that
540    would allow this.  This could be used with X.509 certificates (the
541    initiator ignores all other fields of the certificate except the
542    public key), or "Raw RSA Key" CERT payloads.
543
544    This approach has the advantage that initiators that wish to perform
545    certificate-based responder authentication (in addition to EAP) may
546    do so, without requiring the responder to handle these cases
547    separately.
548
549    If using RSA, the overhead of signature verification is quite small
550    (compared to g^xy calculation).
551
552 A.3.  Use EAP derived session keys for IKEv2
553
554    It has been proposed that when using an EAP methods that provides
555    mutual authentication and key agreement, the IKEv2 Diffie-Hellman
556
557
558
559 Eronen & Tschofenig     Expires December 28, 2006              [Page 10]
560 \f
561 Internet-Draft         Extension for EAP in IKEv2              June 2006
562
563
564    exchange could also be omitted.  This would mean that the sessions
565    keys for IPsec SAs established later would rely only on EAP-provided
566    keys.
567
568    It seems the only benefit of this approach is saving some computation
569    time (g^xy calculation).  This approach requires designing a
570    completely new protocol (which would not resemble IKEv2 anymore) we
571    do not believe that it should be considered.  Nevertheless, we
572    include it for completeness.
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615 Eronen & Tschofenig     Expires December 28, 2006              [Page 11]
616 \f
617 Internet-Draft         Extension for EAP in IKEv2              June 2006
618
619
620 Authors' Addresses
621
622    Pasi Eronen
623    Nokia Research Center
624    P.O. Box 407
625    FIN-00045 Nokia Group
626    Finland
627
628    Email: pasi.eronen@nokia.com
629
630
631    Hannes Tschofenig
632    Siemens
633    Otto-Hahn-Ring 6
634    Munich, Bayern  81739
635    Germany
636
637    Email: Hannes.Tschofenig@siemens.com
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671 Eronen & Tschofenig     Expires December 28, 2006              [Page 12]
672 \f
673 Internet-Draft         Extension for EAP in IKEv2              June 2006
674
675
676 Intellectual Property Statement
677
678    The IETF takes no position regarding the validity or scope of any
679    Intellectual Property Rights or other rights that might be claimed to
680    pertain to the implementation or use of the technology described in
681    this document or the extent to which any license under such rights
682    might or might not be available; nor does it represent that it has
683    made any independent effort to identify any such rights.  Information
684    on the procedures with respect to rights in RFC documents can be
685    found in BCP 78 and BCP 79.
686
687    Copies of IPR disclosures made to the IETF Secretariat and any
688    assurances of licenses to be made available, or the result of an
689    attempt made to obtain a general license or permission for the use of
690    such proprietary rights by implementers or users of this
691    specification can be obtained from the IETF on-line IPR repository at
692    http://www.ietf.org/ipr.
693
694    The IETF invites any interested party to bring to its attention any
695    copyrights, patents or patent applications, or other proprietary
696    rights that may cover technology that may be required to implement
697    this standard.  Please address the information to the IETF at
698    ietf-ipr@ietf.org.
699
700
701 Disclaimer of Validity
702
703    This document and the information contained herein are provided on an
704    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
705    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
706    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
707    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
708    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
709    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
710
711
712 Copyright Statement
713
714    Copyright (C) The Internet Society (2006).  This document is subject
715    to the rights, licenses and restrictions contained in BCP 78, and
716    except as set forth therein, the authors retain all their rights.
717
718
719 Acknowledgment
720
721    Funding for the RFC Editor function is currently provided by the
722    Internet Society.
723
724
725
726
727 Eronen & Tschofenig     Expires December 28, 2006              [Page 13]
728 \f
729