RFC 2485

DHCP Option for The Open Group's User Authentication Protocol

πŸ“… published January 1999, from ietf

RFC 2485: DHCP Option for The Open Group's User Authentication Protocol πŸ’–

Okay bestie, here's the title block tea β˜• RFC 2485 from the Network Working Group, written by S. Drach (Steve Drach) at Sun Microsystems. It's on the Standards Track πŸ¦‹, dated January 1999. The header doesn't list anything it obsoletes or updates, so it's a standalone glow-up 🌸

Status of this Memo ✨

So this doc is an Internet standards track protocol spec for the whole Internet community, and it's basically begging for discussion and suggestions πŸ™ For the official standardization state of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone πŸ’…

The Internet Society owns the copyright here (1999). All rights reserved, obviously πŸ”’

Abstract 🌈

This RFC defines a DHCP [1] option. The option carries a list of pointers to User Authentication Protocol servers, and those servers handle user authentication for clients that follow The Open Group Network Computing Client Technical Standard [2]. Main character energy πŸ‘‘

Introduction 🧚

Okay so The Open Group Network Computing Client Technical Standard comes from The Open Group's Network Computing Working Group (NCWG), and it defines a network computing client user authentication facility called the User Authentication Protocol (UAP) πŸ’œ

UAP has two levels of authentication, basic and secure πŸ” Basic authentication uses the Basic Authentication mechanism from the HTTP 1.1 [3] spec. Secure authentication is basically basic authentication wrapped inside an SSLv3 [4] session. It's giving layers πŸ§…

Either way, a UAP client needs the IP address and port of the UAP service. Depending on how the service is implemented, it might also need some path info πŸ—ΊοΈ A URL [5] is the perfect little package for all of that, since lots of UAP servers will live as components inside legacy HTTP/SSL servers. Iconic πŸ’€

Most UAP clients don't keep any local state, and they get configured at boot through DHCP. But no existing DHCP option [6] has a data field that holds a URL 😭 Option 72 has a list of IP addresses for WWW servers, but it isn't enough, because it can't specify a port and/or path. So yeah, we need an option that carries a list of URLs πŸ™Œ

User Authentication Protocol Option πŸ¦‹

This option is a list of URLs. Each one points to a user authentication service that can process authentication requests wrapped in the User Authentication Protocol (UAP). UAP servers can accept either HTTP 1.1 or SSLv3 connections πŸ“

If a URL in the list has no port component, the normal default port gets used: port 80 for http and port 443 for https. If a URL has no path component, the path /uap is assumed 🫢

Here's the layout:

   0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |   URL list
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code is 98 πŸ”’

Length is the length of the data field (aka the URL list) in bytes πŸ“

URL list is one or more URLs separated by the ASCII space character (0x20) 🌸


References πŸ“š

  • [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [2] Technical Standard: Network Computing Client, The Open Group, Document Number C801, October 1998.
  • [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
  • [4] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol, Version 3.0", Netscape Communications Corp., November 1996. Standards Information Base, The Open Group, http://www.db.opengroup.org/sib.htm#SSL_3.
  • [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
  • [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

Security Considerations πŸ’€

Real talk, this part matters 🚨 DHCP currently has no authentication or security mechanisms at all. Potential attack exposures are covered in section 7 of the DHCP protocol spec.

The User Authentication Protocol can't tell whether a client is talking to a rogue authentication service. That happens when the client got a forged or otherwise compromised UAP option from a DHCP service whose security was compromised. Even secure authentication doesn't save you from this one 😱

This exposure is mitigated by the environmental assumptions written down in the Network Computing Client Technical Standard πŸ›‘οΈ

Author's Address πŸ’Œ

   Steve Drach
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: (650) 960-1300
   EMail: drach@sun.com

Copyright (C) The Internet Society (1999). All rights reserved, again because it's that important πŸ’…

This document and its translations can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can be written, copied, published, and distributed, in whole or in part, with no restrictions at all. The one catch is that the above copyright notice and this paragraph have to stay on all those copies and derivative works 🫢 However, the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards, where the Internet Standards process copyright procedures must be followed, or translating it into languages other than English 🌍

The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE πŸ’œ

πŸ“¦ where this page comes from