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