Subject: Another question on draft-ietf-dhc-authentication-11.txt

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 21 Jul 1999 04:48:12 -0400 (EDT)

Just reread the draft again, and had the following thought:

How are the DHCP servers to verify the 
authentication option and sign messages?

Are we to assume that the DHCP servers have cleartext access
to the shared secret? If we are talking about generating
the secret from a master secret as described in the
Appendix, this might be feasible. However, I don't like
that method much since a master secret shared among
many clients does not have much security value. So I
prefer to think of this as involving a unique shared
secret for each client in which case I think the 
answer to this is "no." 

Will the shared secret will be set via an SNMP v3 MIB? 
If so, this capability is not in the current DHCP MIB. 

Will the DHCP servers will ship the signed DHCP 
packet and proposed response off to a AAA server 
for validation, and signing? This sounds like the
most deployable approach, but encapsulating DHCP
packet payloads in this manner is more than a little
awkward.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jul 1999 10:35:16 -0400 (EDT)

> to the shared secret?

Yes.

> If we are talking about generating the secret from a master secret
> as described in the Appendix, this might be feasible.

This is one alternative, but I like it about as much as you do.

> If so, this capability is not in the current DHCP MIB. 

The authentication draft does not describe the mechanism by which the
client and server will arrive at a shared secret.   This is left up to
a seperate draft that somebody may produce, or to individual
implementors.   Essentially, we didn't feel that we had enough
practical experience to recommend a single mechanism whereby this
would be accomplished, although we definitely left it open that we
might come up with such a mechanism, or several such mechanisms, in
the future.

> packet payloads in this manner is more than a little

This isn't the intention of the draft, AFAIK.  That's not to say you
*couldn't* use some other mechanism, like what you describe, but I
don't think this would be an easy thing to do.

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 21 Jul 1999 11:22:42 -0400 (EDT)

>Yes.

Aside from the case where you only need to store a single master
secret, which isn't very secure, I don't think that this approach
is very practical. In many cases, systems don't support retrieval
of the cleartext password from the directory or wherever they are
stored. Creating another store of user information on the DHCP
server is not something that most customers will like. 

>Essentially, we didn't feel that we had enough
>would be accomplished. 

Just worth noting that companies lookin at deploying this
are often large, so that we could be talking about 100K
shared secrets here. 

>This isn't the intention of the draft, AFAIK.  
>I don't think this would be an easy thing to do.

I would agree with this. However, I don't see another 
alternative that is both reasonably secure and is deployable. 
I would note that Mobile IP took much the same approach
(adding authentication extensions to the Registration request
and response messages) in RFC 2002. However, for carrier
deployments, centralized authentication management is required
and so now they are looking at a challenge-response option.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jul 1999 11:24:42 -0400 (EDT)

> I don't think that this approach is very practical. In many cases,
> systems don't support retrieval of the cleartext password from the
> directory or wherever they are stored.

We weren't expecting to use the same password that the user of the
DHCP client uses for personal authentication - the security
implications of this are not good.

> Creating another store of user information on the DHCP

Understood.  Unfortunately, there's no way to avoid this with a shared
secret/HMAC algorithm.  Ken Hornstein and I discussed a way of using
Kerberos authentication, and we might write a draft for that.  The
current draft does not preclude other alternatives, but it does
provide a mechanism that's not subject to export restrictions and will
work.  We know it's not the ideal solution.  If you're a U.S. citizen,
please write your congresscritters.

> are often large, so that we could be talking about 100K

We're painfully aware of this.

> However, for carrier deployments, centralized authentication
> management is required and so now they are looking at a
> challenge-response option.

Does this involve public key cryptography?

			       _MelloN_

---

From: "William A. Arbaugh" <[email-masked]>
Date: Wed, 21 Jul 1999 12:33:05 -0400 (EDT)

> please write your congresscritters.
I'm not an export expert nor do I speak for the U.S. government, but I
thought that systems whose sole purpose is authentication are exportable
regardless of the crypto involved. I don't know if a license is required
though.

> We're painfully aware of this.
And why the draft was designed to permit public key authentication.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jul 1999 12:34:39 -0400 (EDT)

> regardless of the crypto involved. I don't know if a license is required

In theory, I think you are correct.   In practice, this is something
about which people tend to get nervous.

> And why the draft was designed to permit public key authentication.

Yup.

			       _MelloN_

---

From: [email-masked]
Date: Wed, 21 Jul 1999 14:06:42 -0400 (EDT)

I presented a generalization of the Droms/Arbaugh authentication
  draft in Oslo (draft-gupta-dhcp-auth-00.txt) which supports
  public-key based authentication. It also describes how to support
  roaming -- there are similarities here with your draft titled
  "Certificate based Roaming" (in roamops). Could you please review
  the generalization and post your feedback on whether or not that
  approach is suitable for the scenarios you have in mind.

  thanks for your time,

  vipul

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Jul 1999 03:42:38 -0400 (EDT)

>"Certificate based Roaming" (in roamops). 

Yes, I think that the approaches are similar. The issue 
with securing a DHCP message (or Mobile IP registration for
that matter) with an authentication option is that to
support centralized authentication management (required
by most enterprises and ISPs) you need to not only
encapsulate the message for validation, but also
need to send along the proposed response for signing. 
This is more than a little awkward. In contrast, including
a credential that is verifiable without such proxying 
(such as a Kerberos ticket or public-key signature) 
is cleaner. 

>Could you please review the generalization and post 
>your feedback on whether or not that

I will read the draft in detail and comment on it.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Jul 1999 03:46:13 -0400 (EDT)

>implications of this are not good.

That's fine. However, even if you want to maintain a separate
password for DHCP, I think that customers will want this placed
in a central store, like a directory, rather than being kept
on the DHCP server. 

>Ken Hornstein and I discussed a way of using Kerberos authentication.

I'd be interested to hear more about this. The problem of course
is that typically you won't have a TGT prior to doing a DHCP Discover
so that you can't include a DHCP service ticket in that message. 
Also, you don't have an IP address, and so would need to 
obtain a TGT with no address and presumably a short lifetime.
This can be done by having the DHCP server act as a passthrough
for a conversation between the DHCP Client and the KDC. The problem
is how to actually authenticate to the DHCP service in the short
number of messages that you have available. Hats off to you
if you can make this work without changing the state machine :) 

>Does this involve public key cryptography?

The Challenge-Response draft in Mobile IP WG does not involve public
key crypto, no. The goal of that is simplifying the proxy authentication
case. Of course, public key cryptography is another solution.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jul 1999 10:13:39 -0400 (EDT)

> The problem of course

This is actually not a problem - the current protocol does not
authenticate DHCPDISCOVER messages.

> obtain a TGT with no address and presumably a short lifetime.

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).

> Hats off to you

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

			       _MelloN_

---

From: Vipul Gupta <[email-masked]>
Date: Thu, 22 Jul 1999 13:49:25 -0400 (EDT)

> From: "Bernard Aboba" <[email-masked]>
> To: <[email-masked]>, <[email-masked]>
> 

  I agree. I have been closely involved with an implementation
  of Mobile IP that interfaces to a traditional (secret-key
  style) AAA infrastructure and the interface gets quite
  awkward because a big chunk of the message (the part that
  is covered by the MAC) needs to be passed to the verifier
  as well (along with the MAC). A public-key approach is 
  much cleaner, IMHO.

  What is the current status of the certificate-based roaming
  proposal in roamops? The use of public-keys offers several
  advantages such as non-repudiation (which can go a long way
  towards addressing inter-ISP fraud) but given the large
  installed base of RADIUS-style servers, the switch could
  take a while. Is this what you've been hearing from the ISPs?
  
> I will read the draft in detail and comment on it. 

  Thanks. I look forward to your feedback.
  
  vipul

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 23 Jul 1999 04:14:09 -0400 (EDT)

>  take a while. Is this what you've been hearing from the ISPs?

The current status is that the draft is progressing and appears
to address most security concerns. As a result, I would like
to see the approach applied to other areas, including DHCP and
Mobile IP. 

There are a few elements needed to make this scenario work:

1. PKI support on clients (user cert).
2. PKI support on servers (DHCP or RADIUS server machine cert)
3. Protocol support on clients and servers (e.g. authenticated
   DHCP w/public key option, or EAP support). 

Element #2 is typically not an issue; lots of people have
gotten certificates for servers nowadays, from Verisign or
elsewhere, and most ISPs are comfortable with this. 
Element #3 is typically provided by a vendor, and
is under ISP control and typically represents an
incremental upgrade, so this is usually not an issue. 

The big issue is #1. I was at a conference recently
where the question was asked "if your company has
ever piloted PKI, raise your hand." Around half the
hands went up. Then the speaker asked "How many of
you are ready to roll this out within 12 months?" and only
around half of the original people raised their hand. 

>From this I garner that PKI rollouts are quite formidable,
even for the largest enterprise customers. That doesn't
mean that they won't eventually happen, or that it's
not worthwhile to keep working on this. It just means
that you have to offer both the PKI and a non-PKI
alternative. 

I would note that the Kerberos authentication method
that Ted and Ken have described would also appear to
work for cross-realm authentication and so can enable
roaming in the non-PKI case. 

Here's how I think this would work:

a. After receiving the DHCP DISCOVER, the DHCP server
uses its TGT in order to formulate a KRB_AP_REQ in order to
obtain a cross-realm TGT. 

b. The DHCP server then requests a forwardable 
TGT from the home realm KDC, using the
pre-auth data sent by the user in the DHCP DISCOVER
and the IP address that it will include in the DHCP
Offer. It passes the KRB_AP_REP back to the user
in the DHCP OFFER. 

c. The user then decrypts the KRB_AP_REP and sends
the TGT and an authenticator in the DHCP Request. 

d. The DHCP server uses this TGT along with its own
cross-realm TGT in order to obtain a user-user ticket
for the home realm, which it sends back to the user 
in the DHCP ACK.