idnits 2.17.1 draft-ietf-dhc-suboptions-kdc-serveraddress-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7593 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT K. Luehrs 3 Dynamic Host Configuration Working Group CableLabs 4 Expires December 2003 R. Woundy 5 Comcast Cable 6 J. Bevilacqua 7 YAS Corporation 8 N. Davoust 9 YAS Corporation 10 June 2003 12 KDC Server Address Sub-option 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document defines a new sub-option for the CableLabs Client 43 Configuration (CCC) DHCP option code for conveying the network 44 addresses of Key Distribution Center (KDC) servers. 46 1. Introduction 48 A CCC DHCP Option code providing the KDC server address will be 49 needed for CableHome-compliant residential gateways configured to 50 use Kerberos for authentication as the first step in establishing 51 a secure SNMPv3 link between the PS and the SNMP entity in the 52 cable operator's data network. 54 The CCC DHCP option code will be used to address specific needs of 55 CableLabs client devices during their configuration processes. This 56 document proposes a sub-option for the CCC DHCP option. 58 Configuration of a class of CableLabs client devices described in 59 [2] and [3] will require a DHCP sub-option to provide the client 60 with the network address of a KDC server in the cable operator's 61 data network. The class of devices assumed in [2] and [3] is unlike 62 the class of devices considered in [1], which perform a DNS lookup 63 of the Kerberos Realm name to find the KDC server network address. 65 This document proposes a sub-option of the CCC DHCP option 66 code for use with CableLabs client devices. The proposed sub-option 67 encodes an identifier for the network address of each of one or more 68 Key Distribution Center servers with which the CableLabs client 69 device exchanges security information. 71 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" 72 in this document are to be interpreted as described in RFC 2119 [4]. 74 2. Key Distribution Center IP Address Sub-option 76 CableHome specifications will specify the Key Distribution 77 Center network address encoding as a sub-option of the CCC DHCP 78 Option code. This field will be used to inform the client device of 79 the network address of one or more Key Distribution Center servers. 81 The encoding of the KDC Server Address sub-option will adhere to the 82 format of an IPv4 address. The minimum length for this option is 4 83 octets, and the length MUST always be a multiple of 4. If multiple 84 KDC Servers are listed, they MUST be listed in decreasing order of 85 priority. The format of the KDC Server Address sub-option of the CCC 86 option code is as shown below: 88 SubOpt Len Address 1 Address 2 89 +------+-----+-----+-----+-----+-----+-----+-----+-- 90 | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... 91 +------+-----+-----+-----+-----+-----+-----+-----+-- 93 3. Security Considerations 95 This document relies upon the DHCP protocol [5] for authentication 96 and security, i.e., it does not provide security in excess of what 97 DHCP is (or will be) providing. Potential exposures to attack in 98 the DHCP protocol are discussed in section 7 of the DHCP protocol 99 specification [5] and in Authentication for DHCP Messages [6]. 101 The CCC option can be used to misdirect network traffic by providing 102 incorrect DHCP server addresses, incorrect provisioning server 103 addresses, and incorrect Kerberos realm names to a CableLabs client 104 device. This misdirection can lead to several threat scenarios. A 105 Denial of Service (DoS) attack can result from address information 106 being simply invalid. A man-in-the-middle attack can be mounted by 107 providing addresses to a potential snooper. A malicious service 108 provider can steal customers from the customer selected service 109 provider, by altering the Kerberos realm designation. 111 These threats are mitigated by several factors. 113 Within the cable delivery architecture required by CableLabs' 114 PacketCable, DOCSIS, and CableHome specifications, the DHCP client 115 is connected to a network through a cable modem and the CMTS. The 116 CMTS is explicitly configured with a set of DHCP servers to which 117 DHCP requests are forwarded. Further, a correctly configured CMTS 118 will only allow downstream traffic from specific IP addresses/ 119 ranges. 121 Assuming that server addresses were successfully spoofed to the 122 point that a malicious client device was able to contact a KDC, the 123 client device must still present valid certificates to the KDC 124 before being service enabled. Given the computational overhead of 125 the certificate validation process, this situation could present a 126 DoS opportunity. 128 It is possible for a malicious (although certified) service 129 provider to redirect a customer from the customer's selected service 130 provider. It is assumed that all service providers permitted onto 131 an access providers network are trusted entities that will cooperate 132 to insure peaceful coexistence. If a service provider is found to 133 be redirecting customers, this should be handled as an 134 administrative matter between the access provider and the service 135 provider. 137 Another safeguard that can be taken by service providers to limit 138 their exposure to their KDC server(s) is to configure their network 139 so that the KDC(s) reside on a separate subnetwork. 141 Service providers can further protect their KDC server(s) by placing 142 a firewall in front of the KDC(s)only allowing connections needed 143 for its current provisioning processes. The IP temporary addresses 144 given the client devices from the DHCP server could be sent directly 145 to the firewall from the DHCP server to open a hole for Kerberos 146 messages only for those particular IP addresses for a short period 147 of time. If this was used it would be recommended that service 148 providers authenticate their DHCP server to the KDC as well. This 149 could be done via password authentication rather than digital 150 certificate due to the co-location of the DHCP server to the KDC. 152 Finally, Kerberos requires mutual client-server authentication. 153 Therefore, the client device must authenticate itself with its 154 digital certificate and the KDC is required to authenticate it to 155 the client device. If a hacker tries to redirect the client device 156 by replacing the service provider-configured KDC Server Address 157 sub-option with another IP address, it is not likely to be a valid 158 service provider's KDC server and authentication will fail. 160 4. IANA Considerations 162 The KDC Server Address sub-option described in this document is 163 intended to be a sub-option of the CableLabs Client Configuration 164 (CCC) option described in [1]. IANA is requested to assign and 165 register a sub-option code of the CCC option to the KDC Server 166 Address sub-option. 168 5. Normative References 170 [1] Beser, B. and P. Duffy, "DHCP Option for CableLabs Client 171 Configuration", RFC 3495, March 2003. 173 [2] "CableHome 1.1 Specification SP-CH1.1-I01-030418", CableLabs, 174 April 2003, http://www.cablelabs.com/projects/cablehome/ 175 specifications/. 177 [3] "CableHome 1.0 Specification SP-CH1.0-I04-030411", CableLabs, 178 April 2003, http://www.cablelabs.com/projects/cablehome/ 179 specifications/. 181 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 182 Levels", BCP 14, RFC 2119, March 1997. 184 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 185 1997. 187 [6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 188 3118, June 2001 190 6. Authors' Addresses 192 Kevin Luehrs 193 CableLabs 194 400 Centennial Parkway 195 Louisville, CO 80027 196 Phone: (303) 661-9100 197 EMail: k.luehrs@cablelabs.com 199 Richard Woundy 200 Comcast Cable 201 27 Industrial Drive 202 Chelmsford, MA 01824 203 Phone: (978) 244-4010 204 EMail: richard_woundy@cable.comcast.com 206 John Bevilacqua 207 YAS Corporation 208 300 Brickstone Square 209 Andover, MA 01810 210 Phone: (978) 749-9999 211 EMail: john@yas.com 212 Nancy Davoust 213 YAS Corporation 214 300 Brickstone Square 215 Andover, MA 01810 216 Phone: (978) 749-9999 217 EMail: nancy@yas.com 219 7. Full Copyright Statement 221 Copyright (C) The Internet Society (2003). All Rights Reserved. 223 This document and translations of it may be copied and furnished to 224 others, and derivative works that comment on or otherwise explain it 225 or assist in its implementation may be prepared, copied, published 226 and distributed, in whole or in part, without restriction of any 227 kind, provided that the above copyright notice and this paragraph 228 are included on all such copies and derivative works. However, this 229 document itself may not be modified in any way, such as by removing 230 the copyright notice or references to the Internet Society or other 231 Internet organizations, except as needed for the purpose of develop- 232 ing Internet standards in which case the procedures for copyrights 233 defined in the Internet Standards process must be followed, or as 234 required to translate it into languages other than English. 236 The limited permissions granted above are perpetual and will not be 237 revoked by the Internet Society or its successors or assigns. 239 This document and the information contained herein is provided on an 240 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 241 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 242 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 243 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 244 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 Acknowledgement 248 Funding for the RFC Editor function is currently provided by 249 the Internet Society.