Network Working Group                                           S. Drach
INTERNET-DRAFT                                          Sun Microsystems
Obsoletes: draft-ietf-dhc-options-uap-01.txt               November 1998
                                                        Expires May 1999


              DHCP Option for User Authentication Protocol
                  <draft-ietf-dhc-options-uap-02.txt>

Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This document defines a DHCP [1] option that contains a list of
   pointers to User Authentication Protocol servers that provide user
   authentication services for clients that conform to The Open Group
   Network Computing Client Technical Standard [2].

Introduction

   The Open Group Network Computing Client Technical Standard, a product
   of The Open Group's Network Computing Working Group (NCWG), defines a
   network computing client user authentication facility named the User
   Authentication Protocol (UAP).

   UAP provides two levels of authentication, basic and secure.  Basic
   authentication uses the Basic Authentication mechanism defined in the
   HTTP 1.1 [3] specification.  Secure authentication is simply basic
   authentication encapsulated in an SSLv3 [4] session.

   In both cases, a UAP client needs to obtain the IP address and port
   of the UAP service.  Additional path information may be required,



Drach                                                           [Page 1]


INTERNET-DRAFT        User Authentication Protocol         November 1998


   depending on the implementation of the service.  A URL [5] is an
   excellent mechanism for encapsulation of this information since many
   UAP servers will be implemented as components within legacy HTTP/SSL
   servers.

   Most UAP clients have no local state and are configured when booted
   through DHCP.  No existing DHCP option [6] has a data field that
   contains a URL.  Option 72 contains a list of IP addresses for WWW
   servers, but it is not adequate since a port and/or path can not be
   specified.  Hence there is a need for an option that contains a list
   of URLs.

User Authentication Protocol Option

   This option specifies a list of URLs, each pointing to a user
   authentication service that is capable of processing authentication
   requests encapsulated in the User Authentication Protocol (UAP).  UAP
   servers can accept either HTTP 1.1 or SSLv3 connections.  If the list
   includes a URL that does not contain a port component, the normal
   default port is assumed (i.e., port 80 for http and port 443 for
   https).  If the list includes a URL that does not contain a path
   component, the path /uap is assumed.

   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            TBD

      Length          The length of the data field (i.e., URL list) in
                      bytes.

      URL list        A list of 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, Docu-
     ment Number C801, October 1998.





Drach                                                           [Page 2]


INTERNET-DRAFT        User Authentication Protocol         November 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 Exten-
     sions", RFC-2132, March 1997.

Security Considerations

   DHCP currently provides no authentication or security mechanisms.
   Potential exposures to attack are discussed in section 7 of the DHCP
   protocol specification.

   The User Authentication Protocol does not have a means to detect
   whether or not the client is communicating with a rogue authentica-
   tion service that the client contacted because it received a forged
   or otherwise compromised UAP option from a DHCP service whose secu-
   rity was compromised.  Even secure authentication does not provide
   relief from this type of attack.  This security exposure is mitigated
   by the environmental assumptions documented 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








Drach                                                           [Page 3]