idnits 2.17.1 draft-ietf-dhc-options-uap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes draft-ietf-dhc-options-uap-01.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- No information found for rfcdraft-ietf-dhc-options-uap-01.txt - is the name correct? -- 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 (May 1999) is 9113 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' ** Obsolete normative reference: RFC 2068 (ref. '3') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1738 (ref. '5') (Obsoleted by RFC 4248, RFC 4266) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Drach 3 INTERNET-DRAFT Sun Microsystems 4 Obsoletes: draft-ietf-dhc-options-uap-01.txt November 1998 5 Expires May 1999 7 DHCP Option for User Authentication Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document defines a DHCP [1] option that contains a list of 31 pointers to User Authentication Protocol servers that provide user 32 authentication services for clients that conform to The Open Group 33 Network Computing Client Technical Standard [2]. 35 Introduction 37 The Open Group Network Computing Client Technical Standard, a product 38 of The Open Group's Network Computing Working Group (NCWG), defines a 39 network computing client user authentication facility named the User 40 Authentication Protocol (UAP). 42 UAP provides two levels of authentication, basic and secure. Basic 43 authentication uses the Basic Authentication mechanism defined in the 44 HTTP 1.1 [3] specification. Secure authentication is simply basic 45 authentication encapsulated in an SSLv3 [4] session. 47 In both cases, a UAP client needs to obtain the IP address and port 48 of the UAP service. Additional path information may be required, 49 depending on the implementation of the service. A URL [5] is an 50 excellent mechanism for encapsulation of this information since many 51 UAP servers will be implemented as components within legacy HTTP/SSL 52 servers. 54 Most UAP clients have no local state and are configured when booted 55 through DHCP. No existing DHCP option [6] has a data field that 56 contains a URL. Option 72 contains a list of IP addresses for WWW 57 servers, but it is not adequate since a port and/or path can not be 58 specified. Hence there is a need for an option that contains a list 59 of URLs. 61 User Authentication Protocol Option 63 This option specifies a list of URLs, each pointing to a user 64 authentication service that is capable of processing authentication 65 requests encapsulated in the User Authentication Protocol (UAP). UAP 66 servers can accept either HTTP 1.1 or SSLv3 connections. If the list 67 includes a URL that does not contain a port component, the normal 68 default port is assumed (i.e., port 80 for http and port 443 for 69 https). If the list includes a URL that does not contain a path 70 component, the path /uap is assumed. 72 0 1 2 3 73 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 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Code | Length | URL list 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 Code TBD 80 Length The length of the data field (i.e., URL list) in 81 bytes. 83 URL list A list of one or more URLs separated by the ASCII 84 space character (0x20). 86 References 88 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 89 1997. 91 [2] Technical Standard: Network Computing Client, The Open Group, Docu- 92 ment Number C801, October 1998. 94 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners- 95 Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC-2068, January 96 1997. 98 [4] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol, Version 99 3.0", Netscape Communications Corp., November 1996. Standards 100 Information Base, The Open Group, 101 http://www.db.opengroup.org/sib.htm#SSL_3. 103 [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource 104 Locators (URL)", RFC-1738, December 1994. 106 [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Exten- 107 sions", RFC-2132, March 1997. 109 Security Considerations 111 DHCP currently provides no authentication or security mechanisms. 112 Potential exposures to attack are discussed in section 7 of the DHCP 113 protocol specification. 115 The User Authentication Protocol does not have a means to detect 116 whether or not the client is communicating with a rogue authentica- 117 tion service that the client contacted because it received a forged 118 or otherwise compromised UAP option from a DHCP service whose secu- 119 rity was compromised. Even secure authentication does not provide 120 relief from this type of attack. This security exposure is mitigated 121 by the environmental assumptions documented in the Network Computing 122 Client Technical Standard. 124 Author's Address 126 Steve Drach 127 Sun Microsystems, Inc. 128 901 San Antonio Road 129 Palo Alto, CA 94303 131 Phone: (650) 960-1300 133 EMail: drach@sun.com