draft-smedvinsky-dhc-kerbauth-01.txt [plain text]
DHC Working Group S. Medvinsky
Internet Draft Motorola
Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
Category: Standards Track P.Lalwaney
Expires: January 2001 Nokia
July 2000
Kerberos V Authentication Mode for Uninitialized Clients
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
send comments to the authors.
1. Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] includes an
option that allows authentication of all DHCP messages, as specified
in [2]. This document specifies a DHCP authentication mode based on
Kerberos V tickets. This provides mutual authentication between a
DHCP client and server, as well as authentication of all DHCP
messages.
This document specifies Kerberos message exchanges between an
uninitialized client and the KDC (Key Distribution Center) using an
IAKERB proxy [7] so that the Kerberos key management phase is
decoupled from, and precedes the address allocation and network
configuration phase that uses the DHCP authentication option. In
order to make use of the IAKERB proxy, this document specifies a
transport mechanism that works with an uninitialized client (i.e. a
Kerberos V Authentication Mode for Uninitialized Clients July 2000
client without an assigned IP address). In addition, the document
specifies the format of the Kerberos authenticator to be used with
the DHCP authentication option.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3. Introduction
3.1 Terminology
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
O "Ticket"
A Kerberos term for a record that helps a client authenticate itself
to a server; it contains the client's identity, a session key, a
timestamp, and other information, all sealed using the server's
secret key. It only serves to authenticate a client when presented
along with a fresh Authenticator.
o "Key Distribution Center"
Key Distribution Center, a network service that supplies tickets and
temporary session keys; or an instance of that service or the host
on which it runs. The KDC services both initial ticket and Ticket-
Granting Ticket (TGT) requests. The initial ticket portion is
sometimes referred to as the Authentication Server (or service. The
Ticket-Granting Ticket portion is sometimes referred to as the
Ticket-Granting Server (or service).
o "Realm"
A Kerberos administrative domain that represents a group of
principals registered at a KDC. A single KDC may be responsible for
one or more realms. A fully qualified principal name includes a
realm name along with a principal name unique within that realm.
3.2 Protocol Overview
S. Medvinsky, P. Lalwaney -2-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
DHCP as defined in [1] defines the protocol exchanges for a client
to obtain its IP address and network configuration information from
a DHCP Server. Kerberos V5 as described in [6] defines the protocol
and message exchanges to mutually authenticate two parties. It is
our goal to provide authentication support for DHCP using Kerberos.
This implies that the Kerberos key management exchange has to take
place before a client gets its IP address from the DHCP Server.
Kerberos assumes that the client has a network address and can
contact the Key Distribution Center to obtain its credentials for
authenticated communication with an application server.
In this specification we utilize the key exchange using an IAKERB
proxy described in [7]. This does not require any changes to either
the IAKERB or the Kerberos V5 specification. This document also
specifies a particular transport that allows an uninitialized client
to contact an IAKERB proxy.
The Kerberos ticket returned from the key management exchange
discussed in Section 5 of this document is passed to the DHCP Server
inside the DHCP authentication option with the new Kerberos
authenticator type. This is described in Section 6 of this draft.
3.3 Related Work
A prior Internet Draft [3] outlined the use of Kerberos-based
authentication for DHCP. The proposal tightly coupled the Kerberos
client state machines and the DHCP client state machines. As a
result, the Kerberos key management messages were carried in DHCP
messages, along with the Kerberos authenticators. In addition, the
first DHCP message exchange (request, offer) is not authenticated.
We propose a protocol exchange where Kerberos key management is
decoupled from and precedes authenticated DHCP exchanges. This
implies that the Kerberos ticket returned in the initial key
management exchange could be used to authenticate servers assigning
addresses by non-DHCP address assignment mechanisms like RSIP [4]
and for service specific parameter provisioning mechanisms using SLP
[5].
S. Medvinsky, P. Lalwaney -3-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
4. System Architecture
Client
-------- --------
| | 5.Authenticated DHCP | |
| DHCP |<------------------------>| DHCP |
| client | | server |
| | | |
| | | |
|Kerberos| | |
| Client | | |
-------- --------
^
|
|
|
| -------
------------------------------>| |
Kerberos Key Mgmt | Proxy |
messages: | |
1. AS Request / 2.AS Reply -------
3. TGS Request / 4.TGS Reply ^
| Kerberos
| Key Mgmt messages
v (1, 2, 3, 4)
--------
| |
| KDC |
| |
--------
Figure 1: System blocks and message interactions between them
In this architecture, the DHCP client obtains a Kerberos ticket from
the Key Distribution Center (KDC) using standard Kerberos messages,
as specified in [6]. The client, however, contacts the KDC via a
proxy server, according to the IAKERB mechanism, described in [7].
The are several reasons why a client has to go through this proxy in
order to contact the KDC:
a)The client may not know the host address of the KDC and may be
sending its first request message as a broadcast on a local
network. The KDC may not be located on the local network, and
even if it were - it will be unable to communicate with a client
without an IP address. This document describes a specific
mechanism that may be used by a client to communicate with the
Kerberos proxy.
S. Medvinsky, P. Lalwaney -4-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
b)The client may not know its Kerberos realm name. The proxy is
able to fill in the missing client realm name in an AS Request
message, as specified in IAKERB. Note that in the case that
PKINIT pre-authenticator is used [8], the realm name in the AS
Request may be the KDC realm name and not the clientÆs realm name.
c) The client does not know the realm name of the DHCP server.
According to IAKERB, when the client sends a TGS Request with a
missing server realm name, the proxy will return to the client an
error message containing the missing realm name.
Note that in this case the proxy could return the client a wrong
realm name and the client could be fooled into obtaining a ticket
for the wrong DHCP server (on the same local network). However,
the wrong DHCP server must still be a registered principal in a
KDC database. In some circumstances this may be an acceptable
compromise. Also, see the security considerations section.
IAKERB describes the proxy as part of an application server - the
DHCP server in this case. However, in this document we are not
requiring the proxy to be integrated with the DHCP server. The
same IAKERB mechanisms apply in the more general case, where the
proxy is an independent application. This proxy, however, MUST be
reachable by a client via a local network broadcast.
After a client has obtained a Kerberos ticket for the DHCP server,
it will use it as part of an authentication option in the DHCP
messages. The only extension to the DHCP protocol is the addition
of a new authenticator type based on Kerberos tickets.
4.1 Cross-Realm Authentication
Figure 1 shows a client communicating with a single KDC via a proxy.
However, the DHCP clientÆs realm may be different from the DHCP
serverÆs realm. In that case, the client may need to first contact
the KDC in its local realm to obtain a cross-realm TGT. Then, the
client would use the cross-realm TGT to contact the KDC in the DHCP
serverÆs realm, as specified in [6].
In the following example a client doesnÆt know its realm or the DHCP
serverÆs realm, which happens to be different from the clientÆs
realm. Here are the steps in obtaining the ticket for the DHCP
server (based on [6] and [7]):
1) The client sends AS Request with NULL realm to the proxy.
2) The proxy fills in the realm and forwards the AS Request to
the KDC in the clientÆs realm.
3) The KDC issues a TGT and sends back an AS Reply to the
proxy.
4) The proxy forwards AS Reply to the client.
S. Medvinsky, P. Lalwaney -5-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
5) The client sends TGS Request for a principal name "dhcpsrvr"
with NULL realm to the proxy.
6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
DHCP serverÆs realm to the client.
7) The client sends another TGS Request for a cross-realm TGT
to the proxy.
8) The proxy forwards the TGS Request to the KDC in the
clientÆs realm.
9) The KDC issues a cross-realm TGT and sends back a TGS Reply
to the proxy.
10) The proxy forwards TGS Reply to the client.
11) The client sends a TGS Request to the proxy for a principal
"dhcpsrvr" with the realm name filled in, using a cross-realm
TGT.
12) The proxy forwards TGS Request to the KDC in the DHCP
server's realm.
13) The KDC issues a ticket for the DHCP server and sends TGS
Reply back to the proxy.
14) The proxy forwards TGS Reply to the client.
In a most general case, the client may need to contact any number of
KDCs in different realms before it can get a ticket for the DHCP
server. In each case, the client would contact a KDC via the proxy
server, as specified in Section 5 of this document.
4.2 Public Key Authentication
This specification also allows clients to perform public key
authentication to the KDC, based on the PKINIT specification [8].
In this case, the size of an AS Request and AS Reply messages is
likely to exceed the size of typical link MTU's.
Here is an example, where PKINIT is used by a DHCP client that is
not a registered principal in the KDC principal database:
1) The client sends AS Request with a PKINIT Request pre-
authenticator to the proxy. This includes the clientÆs
signature and X.509 certificate. The KDC realm field is
left as NULL.
2) The proxy fills in the realm and forwards the AS Request to
the KDC in the filled in realm. This is the realm of the
DHCP server. Here, the clientÆs realm is the name of a
Certification Authority - not the same as the KDC realm.
3) The KDC issues a TGT and sends back an AS Reply with a
PKINIT Reply pre-authenticator to the proxy.
4) The proxy forwards the AS Reply to the client.
5) The client sends TGS Request for a principal name "dhcpsrvr"
with the realm found in the TGT to the proxy.
6) The proxy forwards TGS Request to the KDC in the DHCP
serverÆs realm.
7) The KDC issues a ticket for the DHCP server and sends TGS
Reply back to the proxy.
S. Medvinsky, P. Lalwaney -6-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
8) The proxy forwards TGS Reply to the client.
5. Key Management Exchange that Precedes Network Address Allocation
An uninitialized host (e.g. on power-on and reset) does not have a
network address. It does have a link layer address or hardware
address. At this time, the client may not have any information on
its realm or the realm of the address allocation server (DHCP
Server).
In the Kerberos key management exchange, a client gets its ticket
granting ticket (TGT) by contacting the Authentication Server in the
KDC using the AS_Request / Reply messages (shown as messages 1 and 2
in Figure 1). The client then contacts the Ticket Granting Server in
the KDC to get the DHCP server ticket (to be used for mutual
authentication with the DHCP server) using the TGS_REQ / TGS_REP
messages (shown as messages 3 and 4 in the above figure). It is
also possible for the client to obtain a DHCP server ticket directly
with the AS Request / Reply exchange, without the use of the TGT.
In the use of Kerberos for DHCP authentication, the client (a) does
not have an IP/network address (b) does not know he KDCÆs IP address
(c) the KDC may not be on the local network and (d) the client may
not know the DHCP ServerÆs IP address and realm. We therefore
require a Kerberos proxy on the local network to accept broadcast
Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
clients and relay them to the appropriate KDC.
The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
follows:
The request payload contains the client hardware address in
addresses field with a negative value for the address type. Kerberos
v5 [6] allows for the usage of negative address types for "local"
use. Note that IAKERB [7] discourages the use of the addresses field
as network addresses may not be known or may change in situation
where proxies are used. In this draft we incorporate the negative
values permitted in the Kerberos transport in the address type field
of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
be the negative number of the hardware address type "htype" value
(from assigned numbers RFC) used in RFC 2131. The address field of
the message contains the clients hardware address.
The request payload is UDP encapsulated and addressed to port 88 on
the server/proxy. The UDP source port is selected by the client. The
source and destination network addresses are the all-zeroÆs address
and the broadcast address, respectively. For IPv4, the source IP
address is set to 0.0.0.0 and the destination IP address is set to
255.255.255.255. The data link layer header source address
corresponds to the link layer/hardware address of the client. The
S. Medvinsky, P. Lalwaney -7-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
destination link layer address is the broadcast address at the link
layer (e.g. for Ethernet the address is ffffffff).
In the case where AS_REQ message contains a PKINIT pre-authenticator
for public key-based client authentication (based on [8]), the
message will probably not fit into a single UDP packet given typical
link MTU's.
It is assumed that the proxy server on a network is configured with
a list of KDCÆs, their realms and their IP addresses. The proxy
server will act as a client to the KDC and forward standard Kerberos
messages to/from the KDC using unicast UDP or TCP transport
mechanisms, according to [6].
Upon receiving a broadcast request from a client, the proxy MUST
record the clientÆs hardware address that appears as the source
address on the frame as well as in the addresses field of the
request message. Based on the realm of the KDC specified in the
request, the proxy determines the KDC to which this message is
relayed as a unicast message from the proxy to the KDC. In the case
that the client left the KDC realm name as NULL, it is up to the
proxy to first determine the correct realm name and fill it in the
request (according to [7]).
On receiving a request, the KDC formulates a response (AS_REP or
TGS_REP). It includes the clientÆs addresses field in the encrypted
part of the ticket (according to [6]). This response is unicast to
the proxy.
Upon receiving the reply, the proxy MUST first determine the
previously saved hardware address of the client. The proxy
broadcasts the reply on its local network. This is a network layer
broadcast. At the link level, it uses the hardware address obtained
from the addresses field of the request.
The client on receiving the response (link layer destination address
as its hardware address, network layer address is the broadcast
address) must verify that the hardware address in the ticket
corresponds to its link layer address.
Upon receiving a TGS_REP (or an AS_REP with the application server
ticket) from the proxy, the client will have enough information to
securely communicate with the application server (the DHCP Server in
this case), as specified in the following section.
S. Medvinsky, P. Lalwaney -8-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
6. Authenticated Message Exchange Between the DHCP Client and the
DHCP Server
The ticket returned in the TGS response is used by the DHCP client
in the construction of the Kerberos authenticator. The Kerberos
ticket serves two purposes: to establish a shared session key with
the DHCP server, and is also included as part of a Kerberos
authenticator in the DHCP request.
If the size of the authenticator is greater than 255 bytes, the DHCP
authentication option is repeated multiple times. When the values
of all the authentication options are concatenated together, they
will make up the complete authenticator.
Once the session key is established, the Kerberos structure
containing the ticket (AP REQ) can be omitted from the authenticator
for subsequent messages sent by both the DHCP client and the DHCP
server.
The Kerberos authenticator for a DHCP request message is specified
below:
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 | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Replay Detection (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication token (n octets) ... +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of this authenticator is in accordance with [2]. The code
for the authentication option is TBD, and the length field contains
the length of the remainder of the option, starting with the
protocol field.
The value of the protocol field for this authenticator MUST be set
to 2.
The algorithm field MUST take one of the following values:
1 - HMAC-MD5
2 - HMAC-SHA-1
Replay protection field is a monotonically increasing counter field.
When the Kerberos AP REQ structure is present in the authenticator
the counter may be set to any value. The AP REQ contains its own
replay protection mechanism in the form of a timestamp.
S. Medvinsky, P. Lalwaney -9-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
Once the session key has been established and the AP REQ is not
included in the authenticator, this field MUST be monotonically
increasing in the messages sent by the client.
Kerberos authenticator token consists of type-length-value
attributes:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| attribute value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following attributes are included in the Kerberos authenticator
token:
Type Attribute Name Value
--------------------------------------------------------------------
0 Message Integrity Code Depends on the value of the
algorithm field. Its length is
16 bytes for HMAC-MD5 [9, 10]
and 20 bytes for HMAC-SHA-1
[11, 10]. The HMAC key must be
derived from Kerberos session
key found in the Kerberos
ticket according to the key
derivation rules in [6]:
HMAC Key = DK(sess key,
key usage | 0x99)
Here, DK is defined in [12] and
the key usage value for DHCP is
TBD.
The HMAC is calculated over the
entire DHCP message. The
Message Integrity Code
attribute MUST be set to all 0s
for the computation of the
HMAC. Because a DHCP relay
agent may alter the values of
the 'giaddr' and 'hops' fields
in the DHCP message, the
contents of those two fields
MUST also be set to zero for
the computation of the HMAC.
Rules specified in Section 3 of
[2] for the exclusion and
S. Medvinsky, P. Lalwaney -10-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
processing of the relay agent
information are applicable here
too.
This field MUST always be
present in the Kerberos
authenticator.
1 AP_REQ ASN.1 encoding of a Kerberos
AP_REQ message, as specified
in [6]. This MUST be included
by the client when establishing
a new session key. In all
other cases, this attribute
MUST be omitted.
AP_REQ contains the Kerberos ticket for the DHCP server and also
contains information needed by the DHCP server to authenticate the
client. After verifying the AP_REQ and decrypting the Kerberos
ticket, the DHCP server is able to extract a session key which it
now shares with the DHCP client.
The Kerberos authenticator token contains its own replay protection
mechanism inside the AP_REQ structure. The AP_REQ contains a
timestamp that must be within an agreed upon time window at the DHCP
server. However, this does not require the DHCP clients to maintain
an accurate clock between reboots. Kerberos allows clients to
synchronize their clock with the KDC with the help of Kerberos
KRB_AP_ERR_SKEW error message, as specified in [6].
The DHCP server MUST save both the session key and its associated
expiration time found in the Kerberos ticket. Up until the
expiration time, the server must accept client requests with the
Kerberos authenticator that does not include the AP REQ, using the
saved session key in calculating HMAC values.
The Kerberos authenticator inside all DHCP server responses MUST NOT
contain the AP REQ and MUST use the saved Kerberos session key in
calculating HMAC values.
When the session key expires, it is the client's responsibility to
obtain a new ticket from the KDC and to include an AP REQ inside the
Kerberos authenticator for the next DHCP request message.
S. Medvinsky, P. Lalwaney -11-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
7. Detailed message flows for Kerberos and DHCP message Exchanges
The following flow depicts the Kerberos exchange in which a AS REQ
message is used to directly request the DHCP Server ticket. There
are no changes to transport mechanisms below when the additional
phase of using TGS requests/responses with TGTÆs is used.
Client IAKERB Proxy KDC
KB-client-------- AS_REQ ------>
AS REQ Address type = - (htype)
AS REQ Address= hw address
src UDP port = senders port
destination UDP port = 88
src IP = 0.0.0.0
destination IP = 255.255.255.255
src link layer address =
clientÆs HW/link address [e.g Ethernet address]
destination link layer address =
link broadcast address [e.g. ffffffff for Ethernet]
--------------------------->
(unicast to UDP port 88)
<--------------------------
(unicast AS REP)
Encrypted portion of ticket
Includes clients HW address
<---------------AS_REP -----------
Ticket includes clientÆs hardware address
src UDP port = 88
destination UDP port = copied from src port in AS_REQ
src IP = ProxyÆs IP address
destination IP = 255.255.255.255
src link layer address = ProxyÆs HW/link address
destination link layer address =
ClientÆs link layer address from AS_REQ
S. Medvinsky, P. Lalwaney -12-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
The client uses the ticket received from the KDC in the DHCP
Authentication option as described in Section 6.
Client
DHCP-client DHCP Server
------DHCPDISCOVER ---->
(Auth Protocol = 2, includes Kerberos
authenticator with AP REQ )
-----------------------------------
| HMAC | AP REQ |
----------------------------------
| Ticket| Client Authent |
--------------------------
1. Server decrypts ticket
(inside AP REQ) with service
key
2. Server decrypts client
authenticator (inside AP REQ)
and checks content and
checksum to validate the
client.
3. Recompute HMAC with session
key and compare.
<-------DHCPOFFER----------
(Auth Protocol = 2, no AP REQ )
---------DHCPREQUEST------->
(Auth Protocol = 2, no AP REQ)
<--------DHCPACK-------------
(Auth Protocol = 2, no AP REQ )
8. Security Considerations
DHCP clients that do not know the DHCP serverÆs realm name will get
it from the proxy, as specified in IAKERB [7]. Since the proxy is
not authenticated, a DHCP client can be fooled into obtaining a
ticket for the wrong DHCP server in the wrong realm.
S. Medvinsky, P. Lalwaney -13-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
This could happen when the client leaves out the server realm name
in a TGS Request message to the proxy. It is also possible,
however, for a client to directly request a DHCP server ticket with
an AS Request message. In those cases, the same situation occurs
when the client leaves out the realm name in an AS Request.
This wrong DHCP server is still registered as a valid principal in a
database of a KDC that can be trusted by the client. In some
circumstances a client may assume that a DHCP server that is a
Kerberos principal registered with a trusted KDC will not attempt to
deliberately misconfigure a client.
This specification provides a tradeoff between:
1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
which provides for full 2-way authentication at the cost of
an additional configuration parameter.
2) The DHCP clients not requiring any additional configuration
information, besides a password or a key (and a public key
certificate if PKINIT is used). This is at the cost of not
being able to fully authenticate the identity of the DHCP
server.
9. References
[1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
RFC 2131, Bucknell University, March 1997.
[2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
draft-ietf-dhc-authentication-13.txt, June 2000.
[3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
draft-hornstein-dhc-kerbauth-02.txt, February 2000.
[4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
protocol-06.txt, March 2000.
[5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
05.txt, March 2000.
S. Medvinsky, P. Lalwaney -14-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
[7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
draft-ietf-cat-iakerb-03.txt, September 1999.
[8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle, "Public Key Cryptography for Initial Authentication
in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
[9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC 2104, February 1997.
[11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
[12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
[13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
2026.
10. Author's Addresses
Sasha Medvinsky
Motorola
6450 Sequence Drive
San Diego, CA 92121
Email: smedvinsky@gi.com
Poornima Lalwaney
Nokia
12278 Scripps Summit Drive
San Diego, CA 92131
Email: poornima.lalwaney@nokia.com
11. Expiration
This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
expires January 1, 2001.
12. Intellectual Property Notices
S. Medvinsky, P. Lalwaney -15-
Kerberos V Authentication Mode for Uninitialized Clients March 2000
This section contains two notices as required by [13] for
standards track documents. Per [13], section 10.4(A):
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
Per [13] section 10.4(D):
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained in
this document. For more information consult the online list of
claimed rights.
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
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.
S. Medvinsky, P. Lalwaney -16-