crypto/dist/ipsec-tools/src/racoon/rfc/draft-dukes-ike-mode-cfg-02.txt

   1
   2
   3
   4 INTERNET-DRAFT                                                 D. Dukes
   5 Expires March 2002                                           R. Pereira
   6 Document: <draft-dukes-ike-mode-cfg-02.txt>               Cisco Systems
   7                                                          September 2001
   8
   9
  10                     The ISAKMP Configuration Method
  11                    <draft-dukes-ike-mode-cfg-02.txt>
  12
  13
  14
  15 Status of this Memo
  16
  17    This document is an Internet-Draft and is in full conformance with
  18    all provisions of Section 10 of RFC2026 [1].
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups. Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts. Internet-Drafts are draft documents valid for a maximum of
  24    six months and may be updated, replaced, or obsoleted by other
  25    documents at any time. It is inappropriate to use Internet- Drafts
  26    as reference material or to cite them other than as "work in
  27    progress."
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/ietf/1id-abstracts.txt
  30    The list of Internet-Draft Shadow Directories can be accessed at
  31    http://www.ietf.org/shadow.html.
  32
  33
  34 Abstract
  35
  36    This document describes a new ISAKMP method that allows
  37    configuration items to be exchanged securely by using both
  38    push/acknowledge or request/reply paradigms.
  39
  40    The authors currently intend this document to be published as an
  41    Informational RFC, not a standards-track document, so that the many
  42    IPsec implementations that have implemented to earlier drafts of
  43    this protocol can have a single stable reference.
  44
  45    Comments regarding this draft should be sent to ietf-mode-
  46    cfg@vpnc.org or to the authors.
  47
  48
  49 Conventions used in this document
  50
  51    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  52    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
  53    this document are to be interpreted as described in RFC-2119 [2].
  54
  55
  56
  57
  58
  59 Dukes, Pereira                                                       1
  60 \f
  61                    The ISAKMP Configuration Method     September 2001
  62
  63
  64
  65 Table of Contents
  66    1. Introduction....................................................3
  67    1.1. Changes since last revision...................................3
  68    1.2. Reader Prerequisites..........................................3
  69    2. Configuration Transaction.......................................3
  70    3. Configuration Method Exchange and Payload.......................4
  71    3.1. Transaction Exchanges.........................................4
  72    3.1.1. Protected Exchanges.........................................4
  73    3.1.2. Unprotected Exchanges.......................................5
  74    3.2. Attribute Payload.............................................5
  75    3.3. Configuration Message Types...................................6
  76    3.4. Configuration Attributes......................................6
  77    3.5. Retransmission................................................9
  78    4. Exchange Positioning............................................9
  79    5. Specific Uses...................................................9
  80    5.1. Requesting an Internal Address................................9
  81    5.2. Requesting the Peer’s Version................................10
  82    6. Enterprise Management Considerations...........................11
  83    7. Security Considerations........................................11
  84    8. References.....................................................11
  85    10. Author's Addresses............................................12
  86    Full Copyright Statement..........................................13
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118 Dukes, Pereira                                                       2
 119 \f
 120                    The ISAKMP Configuration Method     September 2001
 121
 122
 123
 124 1. Introduction
 125
 126    The ISAKMP protocol provides a framework to negotiate and generate
 127    Security Associations.  While negotiating SAs, it is sometimes quite
 128    useful to retrieve certain information from the other peer before
 129    the non-ISAKMP SA can be established.  Luckily, ISAKMP is also
 130    flexible enough to provide configuration information and do it
 131    securely.  This document will present a mechanism to extend ISAKMP
 132    to provide such functionality.
 133
 134 1.1. Changes since last revision.
 135
 136    The last revision of this document was published as "draft-dukes-
 137    ike-mode-cfg-01.txt", and was originally named "draft-ietf-ipsec-
 138    isakmp-mode-cfg"
 139
 140    o Fixed some typo's and cross-references.
 141
 142 1.2. Reader Prerequisites
 143
 144    It is assumed that the reader is familiar with the terms and
 145    concepts described in the "Security Architecture for the Internet
 146    Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97]
 147    documents.
 148
 149    Readers are advised to be familiar with both [IKE] and [ISAKMP]
 150    because of the terminology used within this document and the fact
 151    that this document is an extension of both of those documents.
 152
 153
 154 2. Configuration Transaction
 155
 156    A "Configuration Transaction" is defined as one or more transaction
 157    exchanges each consisting of two messages, the first being either a
 158    Set or a Request and the second being either an Acknowledge or a
 159    Reply, respectively.  A common identifier is used to identify the
 160    configuration transaction between exchanges.
 161
 162    There are two paradigms to follow for this method.
 163
 164    o "Request/Reply" allows a host to request information from an
 165    informed hosts (a configuration manager).  If the attributes in the
 166    Request message are not empty, then these attributes are taken as
 167    suggestions for that attribute.  The Reply message MAY wish to
 168    choose those values, or return new values.  It MAY also add new
 169    attributes and not include some requested attributes.
 170
 171    A Reply MUST always be sent when a Request is received, even if it
 172    is an empty Reply or if there are missing attributes in the Request.
 173    This merely means that the requested attributes were not available
 174    or unknown.
 175
 176
 177 Dukes, Pereira                                                       3
 178 \f
 179                    The ISAKMP Configuration Method     September 2001
 180
 181
 182        Initiator              Responder
 183        ---------------        --------------
 184        REQUEST          -->
 185                         <--   REPLY
 186
 187    o "Set/Acknowledge" works on the push principle that allows a
 188    configuration manager (a host that wishes to send information to
 189    another host) to start the configuration transaction.  This code
 190    sends attributes that it wants the peer to alter.  The Acknowledge
 191    code MUST return the zero length attributes that it accepted.  Those
 192    attributes that it did not accept will NOT be sent back in the
 193    acknowledgement.
 194
 195        Initiator              Responder
 196        ---------------        -------------------
 197        SET              -->
 198                         <--   ACKNOWLEDGE
 199
 200    Transaction exchanges are completed once the Reply or Acknowledge
 201    code is received.  If one is not received, the implementation MAY
 202    wish to retransmit the original message as detailed in a later
 203    section.
 204
 205    The initiator and responder are not necessarily the same as the
 206    initiator and responder of the ISAKMP exchange.
 207
 208
 209 3. Configuration Method Exchange and Payload
 210
 211 3.1. Transaction Exchanges
 212
 213    A new exchange mode is required for the configuration method.  This
 214    exchange is called the "Transaction Exchange" and has a value of 6.
 215    This exchange is quite similar to the Information exchange described
 216    in [ISAKMP] and [IKE], but allows for multi-exchange transactions
 217    instead of being a one-way transmittal of information.
 218
 219    This specification protects ISAKMP Transaction Exchanges when
 220    possible.
 221
 222
 223 3.1.1. Protected Exchanges
 224
 225    Once an ISAKMP security association has been established (and
 226    SKEYID_e and SKEYID_a have been generated), the ISAKMP Transaction
 227    Exchange is as follows:
 228
 229         Initiator                        Responder
 230        -----------                      -----------
 231         HDR*, HASH, ATTR      -->
 232                               <--        HDR*, HASH, ATTR
 233
 234
 235
 236 Dukes, Pereira                                                       4
 237 \f
 238                    The ISAKMP Configuration Method     September 2001
 239
 240
 241    Where the HASH payload contains the prf output, using SKEYID_a as
 242    the key, and the M-ID (ISAKMP header Message ID) unique to this
 243    exchange concatenated with all of the payloads after the HASH
 244    payload. In other words, the hash for the above exchange is:
 245
 246        HASH = prf( SKEYID_a, M-ID | ATTR )
 247
 248    Multiple ATTR payloads MAY NOT be present in the Transaction
 249    Exchange.
 250
 251    As noted, the message ID in the ISAKMP header-- as used in the prf
 252    computation-- is unique to this transaction exchange and MUST NOT be
 253    the same as the message ID of another transaction exchange.  The
 254    derivation of the initialization vector (IV) for the first message,
 255    used with SKEYID_e to encrypt the message, is described in Appendix
 256    B of [IKE].  Subsequent IVs are taken from the last ciphertext block
 257    of the previous message as described in [IKE].
 258
 259
 260 3.1.2. Unprotected Exchanges
 261
 262    If the ISAKMP security association has not yet been established at
 263    the time of the Transaction Exchange and the information being
 264    exchanged is not sensitive, the exchange MAY be done in the clear
 265    without an accompanying HASH payload.
 266
 267         Initiator                        Responder
 268        -----------                      -----------
 269         HDR, ATTR           -->
 270                             <--          HDR, ATTR
 271
 272    Multiple ATTR payloads MAY NOT be present in the Transaction
 273    Exchange.
 274
 275
 276 3.2. Attribute Payload
 277
 278    A new payload is defined to carry attributes as well as the type of
 279    transaction message.
 280
 281                            1                   2                   3
 282        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 283      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 284      ! Next Payload  !   RESERVED    !         Payload Length        !
 285      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 286      !     Type      !   RESERVED    !           Identifier          !
 287      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 288      !                                                               !
 289      ~                           Attributes                          ~
 290      !                                                               !
 291      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 292
 293    The Attributes Payload fields are defined as follows:
 294
 295 Dukes, Pereira                                                       5
 296 \f
 297                    The ISAKMP Configuration Method     September 2001
 298
 299
 300
 301    o Next Payload (1 octet) - Identifier for the payload type of the
 302    next payload in the message.  If the current payload is the last in
 303    the message, then this field will be 0.
 304
 305    o RESERVED (1 octet) - Unused, set to 0.
 306
 307    o Payload Length (2 octets) - Length in octets of the current
 308    payload, including the generic payload header, the transaction-
 309    specific header and all attributes.  If the length does not match
 310    the length of the payload headers plus the attributes, (i.e. an
 311    attribute is half contained within this payload) then entire payload
 312    MUST be discarded.
 313
 314    o Attribute Message Type (1 octet) - Specifies the type of message
 315    represented by the attributes.  These are defined in the next
 316    section.
 317
 318    o RESERVED (1 octet) - Unused, set to 0.
 319
 320    o Identifier (2 octets) - An identifier used to reference a
 321    configuration transaction within the individual messages.
 322
 323    o Attributes (variable length) - Zero or more ISAKMP Data Attributes
 324    as defined in [ISAKMP].  The attribute types are defined in a later
 325    section.
 326
 327    The payload type for the Attributes Payload is 14.
 328
 329
 330 3.3. Configuration Message Types
 331
 332    These values are to be used within the Type field of an Attribute
 333    ISAKMP payload.
 334
 335     Types                      Value
 336    ========================== ===========
 337     RESERVED                   0
 338     ISAKMP_CFG_REQUEST         1
 339     ISAKMP_CFG_REPLY           2
 340     ISAKMP_CFG_SET             3
 341     ISAKMP_CFG_ACK             4
 342     Reserved for Future Use    5-127
 343     Reserved for Private Use   128-255
 344
 345    Messages with unknown types SHOULD be silently discarded.
 346
 347
 348 3.4. Configuration Attributes
 349
 350    Zero or more ISAKMP attributes [ISAKMP] are contained within an
 351    Attributes Payload. Zero length attribute values are usually sent in
 352    a Request and MUST NOT be sent in a Response.
 353
 354 Dukes, Pereira                                                       6
 355 \f
 356                    The ISAKMP Configuration Method     September 2001
 357
 358
 359
 360    All IPv6 specific attributes are mandatory only if the
 361    implementation supports IPv6 and vice versa for IPv4.  Mandatory
 362    attributes are stated below.
 363
 364    Unknown private attributes SHOULD be silently discarded.
 365
 366    The following attributes are currently defined:
 367
 368     Attribute                 Value   Type       Length
 369    ========================= ======= ========== =====================
 370     RESERVED                    0
 371     INTERNAL_IP4_ADDRESS        1     Variable   0 or 4 octets
 372     INTERNAL_IP4_NETMASK        2     Variable   0 or 4 octets
 373     INTERNAL_IP4_DNS            3     Variable   0 or 4 octets
 374     INTERNAL_IP4_NBNS           4     Variable   0 or 4 octets
 375     INTERNAL_ADDRESS_EXPIRY     5     Variable   0 or 4 octets
 376     INTERNAL_IP4_DHCP           6     Variable   0 or 4 octets
 377     APPLICATION_VERSION         7     Variable   0 or more
 378     INTERNAL_IP6_ADDRESS        8     Variable   0 or 16 octets
 379     INTERNAL_IP6_NETMASK        9     Variable   0 or 16 octets
 380     INTERNAL_IP6_DNS           10     Variable   0 or 16 octets
 381     INTERNAL_IP6_NBNS          11     Variable   0 or 16 octets
 382     INTERNAL_IP6_DHCP          12     Variable   0 or 16 octets
 383     INTERNAL_IP4_SUBNET        13     Variable   0 or 8 octets
 384     SUPPORTED_ATTRIBUTES       14     Variable   0 or multiples of 2
 385     INTERNAL_IP6_SUBNET        15     Variable   0 or 17 octets
 386     Reserved for future use    16-16383
 387     Reserved for private use   16384-32767
 388
 389    o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Specifies an address
 390    within the internal network.  This address is sometimes called a red
 391    node address or a private address and MAY be a private address on
 392    the Internet.  Multiple internal addresses MAY be requested by
 393    requesting multiple internal address attributes.  The responder MAY
 394    only send up to the number of addresses requested.
 395
 396    The requested address is valid until the expiry time defined with
 397    the INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that
 398    was used to secure the request expires.  The address MAY also expire
 399    when the IPSec (phase 2) SA expires, if the request is associated
 400    with a phase 2 negotiation.  If no ISAKMP SA was used to secure the
 401    request, then the response MUST include an
 402    expiry or the host MUST expire the SA after an implementation-
 403    defined time.
 404
 405    An implementation MUST support this attribute.
 406
 407    o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal
 408    network's netmask.  Only one netmask is allowed in the request and
 409    reply messages (e.g. 255.255.255.0) and it MUST be used only with an
 410    INTERNAL_ADDRESS attribute.
 411
 412
 413 Dukes, Pereira                                                       7
 414 \f
 415                    The ISAKMP Configuration Method     September 2001
 416
 417
 418    An implementation MUST support this attribute.
 419
 420    o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
 421    server within the network.  Multiple DNS servers MAY be requested.
 422    The responder MAY respond with zero or more DNS server attributes.
 423
 424    o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a
 425    NetBios Name Server (WINS) within the network.  Multiple NBNS
 426    servers MAY be requested.  The responder MAY respond with zero or
 427    more NBNS server attributes.
 428
 429    o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the
 430    host can use the internal IP address.  The host MUST renew the IP
 431    address before this expiry time.  Only one attribute MAY be present
 432    in the reply.
 433
 434    An implementation MUST support this attribute.
 435
 436    o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
 437    any internal DHCP requests to the address contained within the
 438    attribute.  Multiple DHCP servers MAY be requested.  The responder
 439    MAY respond with zero or more DHCP server attributes.
 440
 441    o APPLICATION_VERSION - The version or application information of
 442    the IPSec host.  This is a string of printable ASCII characters that
 443    is NOT null terminated.
 444
 445    This attribute does not need to be secured.
 446
 447    An implementation MUST support this attribute.
 448
 449    o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
 450    device protects.  This attribute is made up of two fields; the first
 451    being an IP address and the second being a netmask.  Multiple sub-
 452    networks MAY be requested.  The responder MAY  respond with zero or
 453    more sub-network attributes.
 454
 455    An implementation MUST support this attribute.
 456
 457    o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
 458    must be zero length and specifies a query to the responder to reply
 459    back with all of the attributes that it supports.  The response
 460    contains an attribute that contains a set of attribute identifiers
 461    each in 2 octets.  The length divided by 2 (bytes) would state the
 462    number of supported attributes contained in the response.
 463
 464    An implementation MUST support this attribute.
 465
 466    o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
 467    device protects.  This attribute is made up of two fields; the first
 468    being a 16 octet IPv6 address the second being a one octet prefix-
 469    mask as defined in [ADDRIPV6].  Multiple sub-networks MAY be
 470
 471
 472 Dukes, Pereira                                                       8
 473 \f
 474                    The ISAKMP Configuration Method     September 2001
 475
 476
 477    requested.  The responder MAY respond with zero or more sub-network
 478    attributes.
 479
 480    An implementation MUST support this attribute.
 481
 482    Note that no recommendations are made in this document how an
 483    implementation actually figures out what information to send in a
 484    reply.  i.e. we do not recommend any specific method of (an edge
 485    device) determining which DNS server should be returned to a
 486    requesting host.
 487
 488
 489 3.5. Retransmission
 490
 491    Retransmission SHOULD follow the same retransmission rules used with
 492    standard ISAKMP messages.
 493
 494
 495 4. Exchange Positioning
 496
 497    The exchange and messages defined within this document MAY appear at
 498    any time.  Because of security considerations with most attributes,
 499    the exchange SHOULD be secured with an ISAKMP phase 1 SA.
 500
 501    Depending on the type of transaction and the information being
 502    exchanged, the exchange MAY be dependant on an ISAKMP phase 1 SA
 503    negotiation, a phase 2 SA negotiation, or none of the above.
 504
 505    The next section details specific functions and their position
 506    within an ISAKMP negotiation.
 507
 508
 509 5. Specific Uses
 510
 511    The following descriptions detail how to perform specific functions
 512    using this protocol.  Other functions are possible and thus this
 513    list is not a complete list of all of the possibilities.  While
 514    other functions are possible, the functions listed below MUST be
 515    performed as detailed in this document to preserve interoperability
 516    among different vendor's implementations.
 517
 518
 519 5.1. Requesting an Internal Address
 520
 521    This function provides address allocation to a remote host trying to
 522    tunnel into a network protected by an edge device.   The remote host
 523    requests an address and optionally other information concerning the
 524    internal network from the edge device.  The edge device procures an
 525    internal address for the remote host from any number of sources such
 526    as a DHCP/BOOTP server or its own address pool.
 527
 528     Initiator                           Responder
 529    -----------------------------       -------------------------------
 530
 531 Dukes, Pereira                                                       9
 532 \f
 533                    The ISAKMP Configuration Method     September 2001
 534
 535
 536     HDR*, HASH, ATTR1(REQUEST)    -->
 537                                   <--   HDR*, HASH, ATTR2(REPLY)
 538     ATTR1(REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
 539    (either IPv4 or IPv6) but MAY also contain any number of additional
 540    attributes that it wants returned in the response.
 541
 542    For example:
 543    ATTR1(REQUEST) =
 544      INTERNAL_ADDRESS(0.0.0.0)
 545      INTERNAL_NETMASK(0.0.0.0)
 546      INTERNAL_DNS(0.0.0.0)
 547
 548    ATTR2(REPLY) =
 549      INTERNAL_ADDRESS(192.168.219.202)
 550      INTERNAL_NETMASK(255.255.255.0)
 551      INTERNAL_SUBNET(291.168.219.0/255.255.255.0)
 552
 553    All returned values will be implementation dependent.  As can be
 554    seen in the above example, the edge device MAY also send other
 555    attributes that were not included in the REQUEST and MAY ignore the
 556    non-mandatory attributes that it does not support.
 557
 558    This Transaction Exchange MUST occur after an ISAKMP phase 1 SA is
 559    already established and before an ISAKMP phase 2 negotiation has
 560    started, since that negotiation requires the internal address.
 561
 562    Initial Negotiation:
 563      MainMode or AggressiveMode
 564      TransactionMode (IP Address request)
 565      QuickMode(s)
 566
 567    Subsequent address requests would be done without the phase 1
 568    negotiation when there already exists a phase 1 SA.
 569
 570    Subsequent Negotiations:
 571      TransactionMode (IP Address request)
 572      QuickMode(s)
 573
 574 5.2. Requesting the Peer's Version
 575
 576    An IPSec host wishing to inquire about the other peer's version
 577    information (with or without security) MUST use this method.
 578
 579     Initiator                           Responder
 580    -----------------------------       --------------------------
 581     HDR, ATTR1(REQUEST)           -->
 582                                   <--   HDR, ATTR2(REPLY)
 583
 584    ATTR1(REQUEST) =
 585      APPLICATION_VERSION("")
 586
 587    ATTR2(REPLY) =
 588      APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")
 589
 590 Dukes, Pereira                                                      10
 591 \f
 592                    The ISAKMP Configuration Method     September 2001
 593
 594
 595
 596    The return text string will be implementation dependent.  This
 597    transaction MAY be done at any time and with or without any other
 598    ISAKMP exchange and because the version information MAY be deemed
 599    not sensitive, security is optional.
 600
 601
 602 6. Enterprise Management Considerations
 603
 604    The method defined in this document SHOULD NOT be used for wide
 605    scale management.  Its main intent is to provide a bootstrap
 606    mechanism to exchange information within IPSec.  While it MAY be
 607    useful to use such a method of exchange information to some outlying
 608    IPSec hosts or small networks, existing management protocols such as
 609    DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] should be
 610    considered for enterprise management as well as subsequent
 611    information exchanges.
 612
 613
 614 7. Security Considerations
 615
 616    This entire draft discusses a new ISAKMP configuration method to
 617    allow IPSec-enabled entities to acquire and share configuration
 618    information.
 619
 620    The draft mandates that this exchange should normally occur after
 621    the Phase I Security Association has been set up and that the entire
 622    exchange be protected by that Phase I SA.  Thus the exchange is as
 623    secure as any Phase II SA negotiation.
 624
 625    This exchange MAY be secured (encrypted and authenticated) by other
 626    means as well, such as pre-configured ESP [ESP] or data-link
 627    security.
 628
 629
 630 8. References
 631
 632
 633    [1]         Bradner, S., "The Internet Standards Process -- Revision
 634                3", BCP 9, RFC 2026, October 1996.
 635
 636    [2]         Bradner, S., "Key words for use in RFCs to Indicate
 637                Requirement Levels", BCP 14, RFC 2119, March 1997
 638
 639    [Thayer97]  R. Thayer, N. Doraswamy, R. Glenn. "IP Security Document
 640                Roadmap", RFC2411
 641
 642    [ArchSec]   S. Kent, R. Atkinson, "Security Architecture for the
 643                Internet Protocol", RFC2401
 644
 645    [ISAKMP]    D. Maughan, M. Schertler, M. Schneider, J. Turner,
 646                "Internet Security Association and Key Management
 647                Protocol", RFC2408
 648
 649 Dukes, Pereira                                                      11
 650 \f
 651                    The ISAKMP Configuration Method     September 2001
 652
 653
 654
 655    [IKE]       D. Harkins, D. Carrel, "The Internet Key Exchange
 656                (IKE)", RFC2409
 657
 658    [DHCP]      R. Droms, "Dynamic Host Configuration Protocol",
 659                RFC2131
 660
 661    [RADIUS]    C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
 662                Authentication Dial In User Service (RADIUS)", RFC2138
 663
 664    [LDAP]      M. Wahl, T. Howes, S. Kille., "Lightweight Directory
 665                Access Protocol (v3)", RFC2251
 666
 667    [ESP]       S. Kent, "IP Encapsulating Security Payload (ESP)",
 668                RFC2406
 669
 670    [ADDRIPV6]  Hinden, R., "IP Version 6 Addressing Architecture",
 671                RFC 2373, July 1998.
 672
 673
 674 9. Acknowledgments
 675
 676    The editors would like to thank Sanjay Anand, Baiju V. Patel,
 677    Stephane Beaulieu, Tim Jenkins, Peter Ford, Bob Moskowitz and Shawn
 678    Mamros.
 679
 680
 681 10. Author's Addresses
 682
 683    Darren Dukes
 684    Cisco Systems Co.
 685    365 March Road
 686    Kanata, ON, Canada
 687    Phone: 1-613-271-3679
 688    Email: ddukes@cisco.com
 689
 690    Roy Pereira
 691    Cisco Systems, Inc.
 692    170 Tasman Drive
 693    San Jose, CA, USA
 694    Phone: 1-408-526-6793
 695    Email: royp@cisco.com
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708 Dukes, Pereira                                                      12
 709 \f
 710                    The ISAKMP Configuration Method     September 2001
 711
 712
 713
 714 Full Copyright Statement
 715
 716    "Copyright (C) The Internet Society (date). All Rights Reserved.
 717    This document and translations of it may be copied and furnished to
 718    others, and derivative works that comment on or otherwise explain it
 719    or assist in its implementation may be prepared, copied, published
 720    and distributed, in whole or in part, without restriction of any
 721    kind, provided that the above copyright notice and this paragraph
 722    are included on all such copies and derivative works. However, this
 723    document itself may not be modified in any way, such as by removing
 724    the copyright notice or references to the Internet Society or other
 725    Internet organizations, except as needed for the purpose of
 726    developing Internet standards in which case the procedures for
 727    copyrights defined in the Internet Standards process must be
 728    followed, or as required to translate it into
 729
 730
 731    This Internet Draft expires September 2001
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767 Dukes, Pereira                                                      13
 768 \f
 769