Subject: Questions on draft-gupta-dhcp-auth-00.txt

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 6 Sep 1999 15:55:00 -0400 (EDT)

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

It would seem that the approach would be useful in
scenarios in which there is concern about DHCP and/or
DDNS security (for example, where registration of 
A/PTR records is done by the DHCP server), and where 
inter-domain support is required. These include 
roaming scenarios, such as Mobile IP roaming and 
LAN access offerings. 

One of the issues arising in the draft is how to
support the exchange of X.509 certificates or
certificate chains. This can be done either out
of band or in band. Transport of certificates within 
the DHCP payload is complicated by MTU and 
attribute size issues:

1. X.509 certificates can exceed the minimum 
MTU size, and this is also true for certificate chains
and larger MTU sizes. Thus, it would seem that sending
certificate payloads within DHCP messages may require 
fragmentation.

2. RFC 2132 does not support splitting of values across
multiple options due to the lack of support for guaranteed
ordering. Thus, should the certificate or certificate-chain
exceed the size of a single option, there will be an issue. 
This was addressed in the continuation option draft; what
is the status of this? It is now expired, I believe. 

I would note that in some of the scenarios above, out of
band certificate exchange may be feasible. For example, 
one could conceive of implementation of something akin
to IKE agressive mode with cert authentication within 
Mobile IP, beginning with a Foreign Agent Advertisement
and continuing within the Registration Request/Reply.

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 7 Sep 1999 18:23:28 -0400 (EDT)

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

  Yes, these are the scenarios that motivated the draft.
  Authenticated DHCP is especially important for Mobile IPv6
  because it does not include foreign agents (which are
  part of Mobile IPv4). The access control and AAA interfacing
  functions that a foreign agent can offer in Mobile IPv4 will
  have to be moved elsewhere in Mobile IPv6 and the DHCP server
  is a natural candidate for this. 
  
  DHCP authentication is also relevant for cable modem ISPs
  some of whom currently use DHCP combined with proprietary 
  "login" mechanisms (e.g. see 
  http://people.qualcomm.com/karn/rr/index.html).

> is the status of this? It is now expired, I believe. 

  You are right that X509 certificates will typically not
  fit within the 255-byte option length limit. The continuation
  option draft (by Bill Arbaugh and Angelos Keromytis) offers
  one solution. Unfortunately, this draft seems to have
  expired recently. I had the oppprtunity to discuss this problem
  with Angelos in Oslo and he mentioned that the DHCP working
  group had been exploring another solution as well -- 
  the basic idea is to allow multiple extensions with the same
  option code and append them all before processing. I am new
  to the working group and don't know what the status of this
  proposal is (I don't see a draft descibing it either).
  If options can get reordered arbitrarily, this solution won't
  help. This is certainly an important issue and needs to be
  resolved before we can support in-line certificate exchanges.
  
> and continuing within the Registration Request/Reply. 
  
  True. If the certificates are distributed out-of-band, the
  sender can get away with simply including a certificate hash
  (~ 16 or 20 bytes depending on the hashing algorithm) as an
  identifier of the public key needed to verify its signature.
  The draft defines a KEY_ID type of CERT_MD5_HASH for this
  purpose (one can similarly define CERT_SHA_HASH).
  
  vipul