idnits 2.17.1 draft-ietf-ipsec-dhcp-over-ike-radius-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 70: '...security gateway MUST send the DHCP(OF...' RFC 2119 keyword, line 72: '... security gateway MUST then check that...' RFC 2119 keyword, line 75: '...security gateway MUST NOT leave out th...' RFC 2119 keyword, line 85: '...security gateway MUST reply with DHCP(...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ID#' is mentioned on line 118, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-05 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 Expires: 2 October 2003 4 Using RADIUS backend for DHCP over IKE 6 Status of This Memo 8 This document is a submission to the IETF IP Security Protocol 9 (IPSEC) Working Group. Comments are solicited and should be 10 addressed to the working group mailing list (ipsec@lists.tislabs.com) 11 or to the editor. 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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. 33 Abstract 35 This document describes method of using Remote Authentication Dial In 36 User Service (RADIUS) as a backend for the internet key exchange (IKE) 37 version 2 host configuration protocol. 39 Table of Contents 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 42 2. Using RADIUS backend . . . . . . . . . . . . . . . . . . . . . . 2 43 3. Mapping of DHCP options to RADIUS request attributes . . . . . . 2 44 4. Mapping of RADIUS attributes to DHCP options . . . . . . . . . . 3 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 47 7. Normative References . . . . . . . . . . . . . . . . . . . . . . 3 48 8. Non-Normative References . . . . . . . . . . . . . . . . . . . . 4 49 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 51 1. Introduction 53 The IKEv2 [IKEV2] offers way to put DHCP [RFC2131] packets inside the 54 IKE packet exchange to do the host configuration for the remote access 55 clients. This protocol describes how to use existing RADIUS [RFC2865] 56 server to get the configuration data needed for the IKEv2 host 57 configuration protocol. 59 2. Using RADIUS backend 61 The security gateway using the RADIUS as backend for the configuration, 62 is acting as a protocol converted between DHCP and RADIUS. This can also 63 be seen as if there is minimalistic DHCP server in the security gateway, 64 and that DHCP server is then using the RADIUS server to get the actual 65 IP address. This DCHP server is then also responsible to remembering the 66 configuration given to client, in case client decides to request it 67 again later (i.e when client does RENEW or REBIND). 69 If the client sent DHCP(DISCOVER) to the security gateway, then the 70 security gateway MUST send the DHCP(OFFER) back with the configuration 71 parameters found from the RADIUS attributes. The client will then reply 72 to that with DHCP(REQUEST). The security gateway MUST then check that 73 the paremeters are valid compared to the configuration parameters 74 received earlier from the RADIUS and if so sent back DHCP(ACK). Note 75 that security gateway MUST NOT leave out the DHCP(OFFER) packet, i.e it 76 MUST NOT reply to DHCP(DISCOVER) with DHCP(ACK) even when there would 77 not be anything for the client to do with DHCP(OFFER). This would be 78 against the DHCP protocol. 80 The client may also start directly with DHCP(REQUEST), in which case 81 security security gateway simply verifies that the parameters are valid 82 (if there are no parameters inside then they are valid, and server can 83 reply back immediately with full set of parameters) and replies with 84 DHCP(ACK) with final configuration parameters. If the DHCP(REQUEST) 85 parameters are not valid, the security gateway MUST reply with DHCP(NAK) 86 which will cause the client to start again with DHCP(DISCOVER) payload. 88 3. Mapping of DHCP options to RADIUS request attributes 89 The mapping of the DHCP options in the DHCPDISCOVER or DHCPREQUST 90 payload to the RADIUS attributes is following: 92 DHCP option RADIUS attribute 93 ----------- ---------------- 94 Requested IP address (50) Framed-IP-Address (8) 95 Subnet Mask (1) Framed-IP-Netmask (9) 96 Domain Name Server (6) VendorID [ID#], VSA [#] 97 Hostname (12) VendorID [ID#], VSA [#] 98 NetBIOS Name Servers (44) VendorID [ID#], VSA [#] 99 IP Address Lease Time (51) Session-Timeout (27) or 100 VendorID [ID#], VSA [#] 102 The RADIUS server may also support other DHCP options by using vendor 103 specific attributes. 105 4. Mapping of RADIUS attributes to DHCP options 107 The mapping of the RADIUS attributes to DHCP options in the DHCPOFFER or 108 DHCPACK payload is following: 110 RADIUS attribute DHCP field 111 ----------- ---------------- 112 Framed-IP-Address (8) yiaddr 113 Framed-IP-Netmask (9) Subnet Mask Option (1) 114 VendorID [ID#], VSA [#] Domain Name Server Option (6) 115 VendorID [ID#], VSA [#] Hostname Option (12) 116 VendorID [ID#], VSA [#] NetBIOS Name Servers Option (44) 117 Session-Timeout (27) or IP Address Lease Time (51) 118 VendorID [ID#], VSA [#] 120 The RADIUS server may also support other DHCP options by using vendor 121 specific attributes. 123 The actual values for the Vendor ID and VSA (vendor specific attribute) 124 depends on the RADIUS server vendor. 126 5. Security Considerations 128 The connection between security gateway and RADIUS server migth be 129 vulnerable to different kind of attacks, and that connection should be 130 protected using IPsec or some other means. 132 6. IANA Considerations 134 This document does not have any actions for IANA. 136 7. Normative References 138 [IKEV2] 139 Kaufman C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf- 140 ipsec-ikev2-05.txt, February 2003 142 [RFC2131] 143 Droms R., "Dynamic Host Configuration Protocol", March 1997 145 [RFC2865] 146 Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote 147 Authentication Dial In User Service (RADIUS)", June 2000. 149 8. Non-Normative References 151 9. Authors' Addresses 153 Tero Kivinen 154 SSH Communications Security Corp 155 Fredrikinkatu 42 156 FIN-00100 HELSINKI 157 Finland 158 E-mail: kivinen@ssh.fi 160 -- 161 kivinen@ssh.fi 162 SSH Communications Security http://www.ssh.fi/ 163 SSH IPSEC Toolkit http://www.ssh.fi/ipsec/