draft-dukes-ike-mode-cfg-02.txt

ipsec vpn

INTERNET-DRAFT                                                 D. Dukes 
Expires March 2002                                           R. Pereira 
Document: <draft-dukes-ike-mode-cfg-02.txt>               Cisco Systems 
                                                         September 2001 
 
 
                    The ISAKMP Configuration Method 
                   <draft-dukes-ike-mode-cfg-02.txt> 
 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents at any time. It is inappropriate to use Internet- Drafts 
   as reference material or to cite them other than as "work in 
   progress."  
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This document describes a new ISAKMP method that allows 
   configuration items to be exchanged securely by using both 
   push/acknowledge or request/reply paradigms. 
    
   The authors currently intend this document to be published as an 
   Informational RFC, not a standards-track document, so that the many 
   IPsec implementations that have implemented to earlier drafts of 
   this protocol can have a single stable reference. 
    
   Comments regarding this draft should be sent to ietf-mode-
   [e-mail] or to the authors. 
    
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [2]. 
    
    


  
Dukes, Pereira                                                       1 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
Table of Contents 
   1. Introduction....................................................3 
   1.1. Changes since last revision...................................3 
   1.2. Reader Prerequisites..........................................3 
   2. Configuration Transaction.......................................3 
   3. Configuration Method Exchange and Payload.......................4 
   3.1. Transaction Exchanges.........................................4 
   3.1.1. Protected Exchanges.........................................4 
   3.1.2. Unprotected Exchanges.......................................5 
   3.2. Attribute Payload.............................................5 
   3.3. Configuration Message Types...................................6 
   3.4. Configuration Attributes......................................6 
   3.5. Retransmission................................................9 
   4. Exchange Positioning............................................9 
   5. Specific Uses...................................................9 
   5.1. Requesting an Internal Address................................9 
   5.2. Requesting the Peer苨 Version................................10 
   6. Enterprise Management Considerations...........................11 
   7. Security Considerations........................................11 
   8. References.....................................................11 
   10. Author's Addresses............................................12 
   Full Copyright Statement..........................................13 
    





























  
Dukes, Pereira                                                       2 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
1. Introduction 
    
   The ISAKMP protocol provides a framework to negotiate and generate 
   Security Associations.  While negotiating SAs, it is sometimes quite 
   useful to retrieve certain information from the other peer before 
   the non-ISAKMP SA can be established.  Luckily, ISAKMP is also 
   flexible enough to provide configuration information and do it 
   securely.  This document will present a mechanism to extend ISAKMP 
   to provide such functionality. 
    
1.1. Changes since last revision. 
    
   The last revision of this document was published as "draft-dukes-
   ike-mode-cfg-01.txt", and was originally named "draft-ietf-ipsec-
   isakmp-mode-cfg" 
    
   o Fixed some typo's and cross-references. 
    
1.2. Reader Prerequisites 
    
   It is assumed that the reader is familiar with the terms and 
   concepts described in the "Security Architecture for the Internet 
   Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 
   documents. 
    
   Readers are advised to be familiar with both [IKE] and [ISAKMP] 
   because of the terminology used within this document and the fact 
   that this document is an extension of both of those documents. 
    
    
2. Configuration Transaction 
    
   A "Configuration Transaction" is defined as one or more transaction 
   exchanges each consisting of two messages, the first being either a 
   Set or a Request and the second being either an Acknowledge or a 
   Reply, respectively.  A common identifier is used to identify the 
   configuration transaction between exchanges. 
    
   There are two paradigms to follow for this method. 
    
   o "Request/Reply" allows a host to request information from an 
   informed hosts (a configuration manager).  If the attributes in the 
   Request message are not empty, then these attributes are taken as 
   suggestions for that attribute.  The Reply message MAY wish to 
   choose those values, or return new values.  It MAY also add new 
   attributes and not include some requested attributes. 
    
   A Reply MUST always be sent when a Request is received, even if it 
   is an empty Reply or if there are missing attributes in the Request.  
   This merely means that the requested attributes were not available 
   or unknown. 
    
  
Dukes, Pereira                                                       3 

                   The ISAKMP Configuration Method     September 2001 
 
 
       Initiator              Responder 
       ---------------        -------------- 
       REQUEST          --> 
                        <--   REPLY 
    
   o "Set/Acknowledge" works on the push principle that allows a 
   configuration manager (a host that wishes to send information to 
   another host) to start the configuration transaction.  This code 
   sends attributes that it wants the peer to alter.  The Acknowledge 
   code MUST return the zero length attributes that it accepted.  Those 
   attributes that it did not accept will NOT be sent back in the 
   acknowledgement. 
    
       Initiator              Responder 
       ---------------        ------------------- 
       SET              --> 
                        <--   ACKNOWLEDGE 
    
   Transaction exchanges are completed once the Reply or Acknowledge 
   code is received.  If one is not received, the implementation MAY 
   wish to retransmit the original message as detailed in a later 
   section. 
    
   The initiator and responder are not necessarily the same as the 
   initiator and responder of the ISAKMP exchange. 
    
    
3. Configuration Method Exchange and Payload 
    
3.1. Transaction Exchanges 
    
   A new exchange mode is required for the configuration method.  This 
   exchange is called the "Transaction Exchange" and has a value of 6.  
   This exchange is quite similar to the Information exchange described 
   in [ISAKMP] and [IKE], but allows for multi-exchange transactions 
   instead of being a one-way transmittal of information. 
    
   This specification protects ISAKMP Transaction Exchanges when 
   possible. 
    
    
3.1.1. Protected Exchanges 
    
   Once an ISAKMP security association has been established (and 
   SKEYID_e and SKEYID_a have been generated), the ISAKMP Transaction 
   Exchange is as follows: 
    
        Initiator                        Responder 
       -----------                      ----------- 
        HDR*, HASH, ATTR      --> 
                              <--        HDR*, HASH, ATTR 
    

  
Dukes, Pereira                                                       4 

                   The ISAKMP Configuration Method     September 2001 
 
 
   Where the HASH payload contains the prf output, using SKEYID_a as 
   the key, and the M-ID (ISAKMP header Message ID) unique to this 
   exchange concatenated with all of the payloads after the HASH 
   payload. In other words, the hash for the above exchange is: 
    
       HASH = prf( SKEYID_a, M-ID | ATTR ) 
    
   Multiple ATTR payloads MAY NOT be present in the Transaction 
   Exchange. 
    
   As noted, the message ID in the ISAKMP header-- as used in the prf 
   computation-- is unique to this transaction exchange and MUST NOT be 
   the same as the message ID of another transaction exchange.  The 
   derivation of the initialization vector (IV) for the first message, 
   used with SKEYID_e to encrypt the message, is described in Appendix 
   B of [IKE].  Subsequent IVs are taken from the last ciphertext block 
   of the previous message as described in [IKE]. 
    
    
3.1.2. Unprotected Exchanges 
    
   If the ISAKMP security association has not yet been established at 
   the time of the Transaction Exchange and the information being 
   exchanged is not sensitive, the exchange MAY be done in the clear 
   without an accompanying HASH payload. 
    
        Initiator                        Responder 
       -----------                      ----------- 
        HDR, ATTR           --> 
                            <--          HDR, ATTR 
    
   Multiple ATTR payloads MAY NOT be present in the Transaction 
   Exchange. 
    
    
3.2. Attribute Payload 
    
   A new payload is defined to carry attributes as well as the type of 
   transaction message. 
    
                           1                   2                   3 
       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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     ! Next Payload  !   RESERVED    !         Payload Length        ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     !     Type      !   RESERVED    !           Identifier          ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     !                                                               ! 
     ~                           Attributes                          ~ 
     !                                                               ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The Attributes Payload fields are defined as follows: 
  
Dukes, Pereira                                                       5 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
   o Next Payload (1 octet) - Identifier for the payload type of the 
   next payload in the message.  If the current payload is the last in 
   the message, then this field will be 0. 
    
   o RESERVED (1 octet) - Unused, set to 0. 
    
   o Payload Length (2 octets) - Length in octets of the current 
   payload, including the generic payload header, the transaction-
   specific header and all attributes.  If the length does not match 
   the length of the payload headers plus the attributes, (i.e. an 
   attribute is half contained within this payload) then entire payload 
   MUST be discarded. 
    
   o Attribute Message Type (1 octet) - Specifies the type of message 
   represented by the attributes.  These are defined in the next 
   section. 
    
   o RESERVED (1 octet) - Unused, set to 0. 
    
   o Identifier (2 octets) - An identifier used to reference a 
   configuration transaction within the individual messages. 
    
   o Attributes (variable length) - Zero or more ISAKMP Data Attributes 
   as defined in [ISAKMP].  The attribute types are defined in a later 
   section. 
    
   The payload type for the Attributes Payload is 14. 
    
    
3.3. Configuration Message Types 
    
   These values are to be used within the Type field of an Attribute 
   ISAKMP payload. 
    
    Types                      Value 
   ========================== =========== 
    RESERVED                   0 
    ISAKMP_CFG_REQUEST         1 
    ISAKMP_CFG_REPLY           2 
    ISAKMP_CFG_SET             3 
    ISAKMP_CFG_ACK             4 
    Reserved for Future Use    5-127 
    Reserved for Private Use   128-255 
    
   Messages with unknown types SHOULD be silently discarded. 
    
    
3.4. Configuration Attributes 
    
   Zero or more ISAKMP attributes [ISAKMP] are contained within an 
   Attributes Payload. Zero length attribute values are usually sent in 
   a Request and MUST NOT be sent in a Response. 
  
Dukes, Pereira                                                       6 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
   All IPv6 specific attributes are mandatory only if the 
   implementation supports IPv6 and vice versa for IPv4.  Mandatory 
   attributes are stated below. 
    
   Unknown private attributes SHOULD be silently discarded. 
    
   The following attributes are currently defined: 
    
    Attribute                 Value   Type       Length 
   ========================= ======= ========== ===================== 
    RESERVED                    0 
    INTERNAL_IP4_ADDRESS        1     Variable   0 or 4 octets 
    INTERNAL_IP4_NETMASK        2     Variable   0 or 4 octets 
    INTERNAL_IP4_DNS            3     Variable   0 or 4 octets 
    INTERNAL_IP4_NBNS           4     Variable   0 or 4 octets 
    INTERNAL_ADDRESS_EXPIRY     5     Variable   0 or 4 octets 
    INTERNAL_IP4_DHCP           6     Variable   0 or 4 octets 
    APPLICATION_VERSION         7     Variable   0 or more 
    INTERNAL_IP6_ADDRESS        8     Variable   0 or 16 octets 
    INTERNAL_IP6_NETMASK        9     Variable   0 or 16 octets 
    INTERNAL_IP6_DNS           10     Variable   0 or 16 octets 
    INTERNAL_IP6_NBNS          11     Variable   0 or 16 octets 
    INTERNAL_IP6_DHCP          12     Variable   0 or 16 octets 
    INTERNAL_IP4_SUBNET        13     Variable   0 or 8 octets 
    SUPPORTED_ATTRIBUTES       14     Variable   0 or multiples of 2 
    INTERNAL_IP6_SUBNET        15     Variable   0 or 17 octets