Subject: Kerberos for DHCP authentication

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Jul 1999 12:49:54 -0400 (EDT)

>Ah!  Still not a problem.  The DHCP server knows what your IP address
>will be.  _It_ asks for a TGT for you, using your IP address, and
>sends it to you in the DHCPOFFER packet, along with a user-to-user
>ticket that you can decrypt with the TGT once you've decrypted it with
>your password (Ken groks exactly how this works - I don't).

Questions: 

1. In the KRB_AS_REQ, I assume that there will be no
pre-auth data, correct? 

Fitting in pre-auth would be nice since you could then
prevent a bogus user from obtaining a ticket/session key package 
that they can then attempt to crack by brute force (since it's 
encrypted in a key derived from the user's password). Also,
you could then support public key authentication via PKINIT. 

2. The addresses field will be set to the
the client address, and the FORWARDABLE flag will be
set, no? The resulting TGT will have the FORWARDED flag set,
correct? 

3. The DHCP server will receive the KRB_AS_REP and
then forward this along in the DHCP Offer. The enclosed
TGT will have the addresses field set to the client address, no?

4. To obtain a user-user ticket, the DHCP server will need to
include the client's TGT as well as it's own in a KRB_AS_REQ.
This message will have the ENC-TKT-IN-SKEY flag set, and will
include the client's TGT in the additional-tickets field. 
 
In order for the DHCP server to obtain the client's
TGT this and an authenticator are included in the 
DHCP REQUEST, no? 

5. Is it possible to support mutual authentication? For
example, does the DHCP Server return an authenticator in
the DHCK ACK?

>Ken actually came up with the idea, so if it works, it's to him that
>you should take your hat off!   :')

This is pretty cool. Hat's off to you, Ken!

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Mon, 26 Jul 1999 07:32:25 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
-----------------------------------------------------------------------------
I hope y'all will forgive me for not answering these messages until now;
I must have caught a nasty bug coming back from the Oslo IETF, and I
was out all this past week from work.

Now, setting the dial on the Wayback machine .... Ted, we talked
about this at the Orlando IETF, right?  IIRC, you wanted to do
Kerberos for DHCP, but you didn't want to add new round-trips to
the protocol.  I came up with this user-to-user based authentication
scheme.

>>your password (Ken groks exactly how this works - I don't).

Just as an explanation:

- The idea in U2U authentication is that two people who only have TGTs
  can authenticate.  Basically, one of the parties agrees to send
  the encrypted part of their TGT to the the other party, who bundles
  them both up and sends them to the KDC as a TGS_REQ, with ENC-TKT-IN-SKEY
  set.  You get back a standard TGS_REP, _except_ that the "server" ticket
  is encrypted with the session key from the "additional" ticket (normally
  it would be encrypted with the principal's key, which in the case of
  a user would be their password, which means that they would have to
  enter it again, which is generally frowned upon).

- My idea (as I remember) was that the DHCP server could do the client's
  AS_REQ for them, take the encrypted part and bundle it up as the
  "additional" ticket and do a TGS_REQ to the KDC; the TGS_REP could
  be used for authentication between the DHCP server and client.  (Yes,
  I'm being terse; sorry Ted :-) ).

>1. In the KRB_AS_REQ, I assume that there will be no

Pretty much so, unfortunately.  You would need the client's key to do
any preauth at this point (since the DHCP server is doing it for you
at this time ...).  Generally preauth involves a couple of round-trips
(hey, you need preauth!  okay, here it is).  I suppose if the client
_knew_ the preauth needed, it could send it in the initial DHCP request.

>set, no? The resulting TGT will have the FORWARDED flag set,

Well, it's not actually required for this to work.

>TGT will have the addresses field set to the client address, no?

Right.

>include the client's TGT in the additional-tickets field. 

Well, it's actually a TGS_REQ.  And now you see the dark secret to

this protocol.  The DHCP server will have to maintain a current
TGT for this to work.  Not rocket science, but it will be a small
bit of work.

>TGT this and an authenticator are included in the 

Just the TGT; you don't need an authenticator for U2U (at this point,
at least, and you don't know enough to generate an authenticator).

>example, does the DHCP Server return an authenticator in

I was thinking that at this point, you would send an AP_REQ, which would
of course include an authenticator.

Hmmm, okay, more is coming back to me now.  I was thinking that it would
look something like:

Client				Server
------------------------------------------------------------
DHCPDICOVER ------------------->
  Includes client principal
  and other information
  for client AS_REQ
				Makes AS_REQ on behalf of client
				Does TGS_REQ for U2U packet

<------------------------------ DHCPOFFER
				Includes AS_REP from client principal
				Includes AP_REQ using U2U TGS_REP info

Client decrypted AS_REP
Client validates AP_REQ (using
session key from AS_REP)

DHCPREQUEST ------------------->

Authenticated, using now-shared
session key (probably use AP_REP).

				AP_REP is validated, mutual authentication
				is complete.

<------------------------------ DHCPACK

				Authenticated maybe with KRB_SAFE.

Does that make sense?

--Ken