IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT 2 April 2003 draft-ietf-ipsec-dhcp-over-ike-00.txt Expires: 2 October 2003 DHCP over IKE Status of This Memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 method of getting the IP security (IPsec) remote access client configuration information from the security gateway by tunneling dynamic host configuration protocol (DHCP) packets inside the internet key exchange (IKE) version 2 protocol. T. Kivinen [page 1] INTERNET-DRAFT 2 April 2003 Table of Contents 1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. DHCP-over-IKE protocol . . . . . . . . . . . . . . . . . . . . . 3 4. DHCP packet formatting . . . . . . . . . . . . . . . . . . . . . 6 5. DHCP payload . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Format of DHCPv4 packet . . . . . . . . . . . . . . . . . . . . 7 7. Typical DHCPv4 packet exchange . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 12 9. Non-Normative References . . . . . . . . . . . . . . . . . . . . 12 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 1. Requirements The DHCP-over-IKE protocol described here fullfills the following requirements: o Get the IP address for the client "in time" for use in the Traffic Selectors. o Protocol must be able to be use any method of getting the actual configuration data in the security gateway end. This is including but not limiting to: RADIUS, DHCPv4, LDAP, DHCPv6, RS/RA-stateless-IPv6, Diameter, PIB, or local configuration information database in the security gateway. o The configuration protocol might be tied to the EAP authentication progress, i.e for some cases the authentication of the client must be done first before the security gateway can get the configuration information for that client. o It should be possible for the client to get the same address each time it requests it. This implies some kind of persistent "hardware"/node identifier (note "hardware"/node ID != IKE ID). 2. Introduction The basic protocol is to put the DHCP [RFC2131] packets inside the IKEv2 packets as separate payload(s). This does not imply that either end actually has to use DHCP for configuration, but we are simply reusing the existing packet format, which allows wide variety of configuration options. This also allows us to support all current and future configuration needs as defined in the DHCP protocol. The basic flow of the DHCP exchange is: Server 1 Client Server 2 -------- ------ -------- <----------- DHCPDISCOVER (broadcast) ---------> T. Kivinen [page 2] INTERNET-DRAFT 2 April 2003 DHCPOFFER --------------> <------------------ DHCPOFFER <------------ DHCPREQUST (broadcast) ----------> <-------------------- DHCPACK The DHCPDISCOVER and DHCPOFFER packets might be missing if the client already have configuration and only wants to request that it can actually use it. The actual binding for the addres happens during the DHCPACK packet. 3. DHCP-over-IKE protocol The protocol flow of the DHCP-over-IKE combined with EAP is as follows: Client Security Gateway ------ ---------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr, DHCP} --> <-- HDR, SK {IDr, [CERT,] AUTH, [EAP,] DHCP} (following packets can be repeated as many times as needed) HDR, SK {[EAP,] [DHCP]} --> <-- HDR, SK {[EAP,] [DHCP]} HDR, SK {[EAP,] [AUTH,] [DHCP] } --> <-- HDR, SK {[EAP,] [AUTH,], [DHCP,] SAr2, TSi, TSr } The first two packets are the normal IKE_SA_INIT exchange. The IKE_AUTH phase following that can take as many steps as needed to finish both the EAP and DHCP protocols. The EAP protocol is finished when the security gateway sends EAP(success) packet. The DHCP protocol is finished when the security gateway sends DHCP(ACK) packet. In the first IKE_AUTH packet the client will include the DHCP payload indicating it wants to have configuration from the security gateway. This DHCP payload may either be DHCPDISCOVER (the client does not already have address, i.e it is in DHCP init state) or DHCPREQUST T. Kivinen [page 3] INTERNET-DRAFT 2 April 2003 (client is requesting for previously given address, i.e it is in DHCP init-reboot state). If the first packet is DHCPDISCOVER then the security gateway will eventually reply with DHCPOFFER payload, and then client sends DHCPREQUEST payload. When security gateway replies to the DHCPREQUEST with DHCPACK then the configuration protocol is finished. If the first DHCP payload is DHCPREQUEST, the reply might either be DHCPACK (finishing the configuration) or DHCPNAK, meaning that the client was denied to use of requested address. After DHCPNAK the client MUST start the configuration protocol from the beginning by sending DHCPDISCOVER packet (i.e move to the DHCP init state). If the paramters are not accetable the security gateway SHOULD reply with DHCPNAK instead of waiting for the client to timeout the DHCP rebooting phase and fall back to DHCP init state (i.e back to sending DHCPDISCOVER). The EAP process might be going on before, after or simultaneously to the configuration progress. I.e in case of RADIUS [RFC2865] backend is used then the configuration data might be only known after the authentication process is finished, in which case the security gateway will postpone replying to the DHCPDISCOVER or DHCPREQUEST until EAP prosess is finished. The AUTH payload in the reply to the first IKE_AUTH packet is normal authentication packet of the security gateway, i.e either the signature or the MAC depending which authentication method is used. If the EAP method is such that it creates a shared key between the client and security gateway then the packets having the final EAP payloads MUST also have AUTH payloads created using that shared key. When the security gateway detects that both EAP and DHCP configuration is finished it will send reply packet containing the final EAP or DHCP payload (depending which of those ended last), and payloads needed to complete the CREATE_CHILD_SA (i.e SAr2, and Traffic Selectors). When using DHCP to request configuration data from the security gateway the client MUST use wildcard address range in traffic selectors when starting to create the SA, and the security gateway MUST then narrow the traffic selectors down. I.e the client uses address range from 0.0.0.0 to 255.255.255.255 in TSi and TSr when sending the SAi2. The protocol and port range can be specified, but address normally cannot be, as it is not yet known (the client is requesting it from the security gateway). The security gateway MUST narrow the traffic selectors so that the TSi includes only the configured IP address of the client, and the TSr SHOULD include the subnet(s) accessable through the security gateway. Note, that since the security gateway might be using external configuration backend, the client needs to use normal DHCP retransmission policies when sending the requests. I.e if the security gateway does not reply with a packet containing DHCP payload, the client should send new IKE packet having the same DHCP payload (but new message id), so that security gateway has possibility to sending back the reply T. Kivinen [page 4] INTERNET-DRAFT 2 April 2003 (security gateway cannot send the DHCP packet before client sends next request to it), and if client is trying to use DHCPREQUEST and does not get any reply back (or receives DHCPNAK) then client starts again with DHCPDISCOVER. Security gateway might also send multiple DHCPOFFER packets, and client can select the one that suits it best to be used. The security gateway SHOULD wait for configurable time (few seconds) for the replies from external configuration backends and collect all replies to the reply packet (as separate DHCP payloads) going back to the client. It can also send reply back immediately when it has first reply, to fasten up the process (for example in case where it knows there is only one DHCP server in the network). If no replies are received during that time the security gateway MUST send reply to the IKE packet, without the DHCP payload. Example data flow with new client doing DHCP and one-time-password EAP: Client Security Gateway ------ ---------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi(0.0.0.0-255.255.255.255), TSr(0.0.0.0-255.255.255.255), DHCP(DISCOVER)} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP(OTP-Challenge), DHCP(OFFER, ip=1.2.3.4)} HDR, SK {EAP(OTP-Reply), DHCP(REQUEST, ip=1.2.3.4) } --> <-- HDR, SK {EAP(success), DHCP(ACK, ip=1.2.3.4), SAr2, TSi(1.2.3.4-1.2.3.4), TSr(0.0.0.0- 255.255.255.255)} Another example doing signature authentication for both ends, and client requesting reuse of the previous address: Client Security Gateway ------ ---------------- T. Kivinen [page 5] INTERNET-DRAFT 2 April 2003 HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT], [CERTREQ,] [IDr,] AUTH, SAi2, TSi(0.0.0.0-255.255.255.255), TSr(0.0.0.0-255.255.255.255), DHCP(REQUEST, ip=1.2.3.4)} --> <-- HDR, SK {IDr, [CERT,] AUTH, DHCP(ACK, ip=1.2.3.4), SAr2, TSi(1.2.3.4-1.2.3.4), TSr(0.0.0.0- 255.255.255.255)} 4. DHCP packet formatting The DHCP packet is filled as normally, except the client will use hardware type (htype) of 31 signifying an IPsec tunnel mode virtual interface. The chaddr field MUST include an identifier unique to the virtual subnet. The client MUST use the same chaddr field in all subsequent messages within the same exchange. In addition, the chaddr SHOULD be persistent between reboots so that the DHCP server will be able to re-assign the same address if desired. The hlen and chaddr fields SHOULD be determined as follows: o If one or more LAN interfaces are available, the hlen and chaddr fields SHOULD be determined from the active LAN interface with the lowest interface number. If no active LAN interface is available, then the parameters SHOULD be determined from the LAN interface with the lowest interface number. This enables the chaddr to be persistent between reboots, as long as the LAN interface hardware is not removed. o If there is no LAN interface, the chaddr field SHOULD be determined by concatenating x'4000', the IPv4 address of the interface supplying network connectivity, and an additional octet. The x'4000' value indicates a locally administered unicast MAC address, thus guaranteeing that the constructed chaddr value will not conflict with a globally assigned value. The additional octet (which MAY represent an interface number) SHOULD be persistent between reboots, so that the chaddr value will be persistent across reboots if the assigned IPv4 address remains consistent. T. Kivinen [page 6] INTERNET-DRAFT 2 April 2003 If the above prescription is followed, then the chaddr will always be unique on the virtual subnet provided that the remote host only brings up a single tunnel to the security gateway. Where a LAN interface is available, the chaddr will be globally unique. When a non-LAN interface is available and a unique Internet address is assigned to the remote host, the chaddr will also be globally unique. Where a private IP address is assigned to a non-LAN interface, it will not be globally unique. 5. DHCP payload The DHCP payload, is used to exchange configuration information between IKE peers. The DHCP Payload is defined as follows: 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Packet Type ! ! +-+-+-+-+-+-+-+-+ ! ! ! ~ Configuration Packet ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Packet Type - Type of the DHCP packet. Currently defined types are: Packet Type Value =========== ===== RESERVED 0 DHCPv4 packet [RFC2131] 1 o Configuration Packet (variable length) - Contains the configuration packet. The exact packet format depends of the packet type. The payload type for the DHCP Payload is sixteen (16). This document describes the DHCPv4 packet type, and other documents may later describe other packet formats (for example DHCPv6). If unknown DHCP Payload packet type is received then UNKNOWN-DHCP- PAYLOAD-TYPE notification MUST be sent back. This allows future versions to probe if the newer packet type is supported or not (i.e if server responds with notification, then it is not supported, if it replies or does not reply at all immediately, then it is supported). 6. Format of DHCPv4 packet The typical packet put inside the DHCP Payload will be (described here T. Kivinen [page 7] INTERNET-DRAFT 2 April 2003 only to make it easier for implementators to understand what goes where, see [RFC2131] for full details): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! op ! htype ! hlen ! hops ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! xid ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! secs ! flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ciaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! yiaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! siaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! giaddr ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! chaddr ! ! (16 bytes) ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! sname ! ! (64 bytes) ! ~ ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! file ! ! (128 bytes) ! ~ ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! byte 99 (0x63)!byte 130 (0x82)! byte 83 (0x53)! byte 99 (0x63)! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! opt53 ! option len (1)! opt53 value ! opt50 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! option len (4)! requested IP address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ...... ! opt255 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o op - BOOTP message option code / message type, 1 = BOOTREQUEST (from client to server), 2 = BOOTREPLY (from server to client) o htype - Hardware address type, 31 = IPsec tunnel mode virtual interface [RFC3456]. o hlen - Hardware address length = 6. o hops - Client sets to zero, optionally used by relay agents when T. Kivinen [page 8] INTERNET-DRAFT 2 April 2003 booting via a relay agent. o xid - Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. o secs - Filled in by client, seconds elapsed since client began address acquisition or renewal process. o flags - Flags (normally zero). o ciaddr - Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests, i.e in normal initial exchange always zero, i.e client fill with zeros and the server copies from the request packet. o yiaddr - 'your' (client) IP address. Never filled in by the client, sent by the server to client telling the clients new IP address. o siaddr - IP address of next server to use in bootstrap. Normally zero. o giaddr - Relay agent IP address, used in booting via a relay agent. Packets inside the DHCP payload this is normally set to zero. o chaddr - Client hardware address. Filled in by the client as specified in section 4. o sname - Optional server host name, null terminated string. Normally zero. o file - Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. Normally zero. o byte 99, 130, 83, 99 - Magic cookie. o opt53 - DHCP Message Type. o option len - Length of the option in bytes not including the option tag and this length byte. o opt53 value - Type of the DHCP message. Client normally first send DHCPDISCOVER, and the server replies with DHCPOFFER. Then client finishes the exchange by sending DHCPREQUEST and server verifies that exchange is done by DHCPACK. Type Value ==== ===== DHCPDISCOVER 1 DHCPOFFER 2 DHCPREQUEST 3 T. Kivinen [page 9] INTERNET-DRAFT 2 April 2003 DHCPDECLINE 4 DHCPACK 5 DHCPNAK 6 DHCPRELEASE 7 DHCPINFORM 8 o opt50 - Requested IP Address. Only present in the DHCPREQUEST, when client requests to be allowed to use this IP address. o requested IP address - IP address client requests to use. Client copies the ciaddr field from the DHCPOFFER to here when sending DHCPREQUEST. o opt255 - End of options. Some other useful options [RFC1533] and their formats are: o Pad - opt0, no data. Used for padding. o Subnet mask - opt1, data: 4 subnet mask bytes. o Domain name server - opt6, data: 4 * N address bytes for N dns servers. o Hostname - opt12, data: N bytes of hostname. o NBNS - opt44, data: 4 * N address bytes for N NetBIOS name servers. o IP address lease time - opt51, data: 4 bytes, lease time in seconds. o Server identifier - opt54, data: 4 bytes, address of the DHCP server, send by server, and copied back in client if known. o Parameter request list - opt55, data: N bytes, each byte specifying one option which is requested from the server (client sends this, server tries to put all these options in its reply). o Option overload - opt52, data: 1 byte. Value 1 means that the file field contains options instead of its normal contents. Value 2 means that sname fields contains options, and value 3 means that both of those fields contain options. 7. Typical DHCPv4 packet exchange The client will first create DHCPDISCOVER payload, and fill in the following data: o op - 1 = BOOTPREQUEST o htype - 31 = IPsec tunnel mode virtual interface o hlen - 6 T. Kivinen [page 10] INTERNET-DRAFT 2 April 2003 o xid - random transaction id o chaddr - hardware address, as specified in section 4. o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 1 o Parameter request list option - bytes 55, n, n bytes of option numbers, of which the client wants to request. o End of options - bytes 255 All other fields are filled with zeros. The server will reply with DHCPOFFER payload, with following data: o op - 2 = BOOTREPLY o yiaddr - IP address offered for client o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 2 o Server identifier - bytes 51, 4, IP address identifying the server giving out information (DHCP server, security gateway etc). o Other configuration options. o End of options - bytes 255 All other fields are copied form the DHCPDISCOVER packet. DHCP options are not copied from the DHCPDISCOVER packet. Those first two packets can be ignored if client already has IP address and wants to try to use that one. Client will request to use given address by sending DHCPREQUEST payload, with following data: o op - 1 BOOTREQUEST o htype, hlen, xid, chaddr - same as DHCPDISCOVER (== copied from DHCPOFFER). o yiaddr - filled with zero o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 3 o Requested IP Address - bytes 50, 4, IP address to be requested (i.e the yiaddr from the DHCPOFFER or the old IP address). T. Kivinen [page 11] INTERNET-DRAFT 2 April 2003 o Server identifier - bytes 51, 4, IP address - copied from the DHCPOFFER (if trying to use previous IP address this should be filled with the value from the previous run). o Parameter request list option - bytes 55, n, n bytes of option numbers, of which the client wants to request. o Other options can be copied from the DHCPREQUEST payload. The server will reply with DHCPACK payload, and finish the configuration protocol. The DHCPACK is filled with following data: o op - 2 = BOOTREPLY o yiaddr - IP address offered for client o magic - bytes 99, 130, 83, 99 o DHCP Message Type option - bytes 53, 1, 5 o Server identifier - bytes 51, 4, IP address identifying the server giving out information (DHCP server, security gateway etc). o Other configuration options. o End of options - bytes 255 The option should be same that what was in the DHCPOFFER payload. 8. Normative References [RFC2131] Droms R., "Dynamic Host Configuration Protocol", March 1997 9. Non-Normative References [RFC2865] Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote Authentication Dial In User Service (RADIUS)", June 2000. [RFC1533] Alexander S., and Droms R., "DHCP Options and BOOTP Vendor Extensions", October 1993. [RFC3456] Patel B., B. Adoba, S. Kelly, and Gupta V., "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", January 2003. 10. Authors' Addresses Tero Kivinen SSH Communications Security Corp T. Kivinen [page 12] INTERNET-DRAFT 2 April 2003 Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: kivinen@ssh.fi T. Kivinen [page 13] -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/