Security Architecture for DHCP

[[e-mail]]

Olafur,

I just read draft-ietf-dhc-security-arch-00.txt.

This is a really good start and you hav done a good job.

Do we discuss it here?  Or do we need [e-mail] list?

Questions/Comments:

Is DNSSEC (and which draft are you speaking of) really a key dist
mechanism?  I thought it only stored keys?

Why not use ISAKMP+OAKELY for IPsec where it can be used and possibly
another derivation of ISAKMP for DHCP?

Do we need a new DOI for DHCP under ISAKMP+OAKLEY?

Can you differntiate for us the options for DNSSEC vs ISAKMP or where
they ar integrated?

What about SSL 3.0 or the TLS being worked on now? Though I think IPsec
is more applicable?

It seems to me that the mechanism chosen should also support the server
to server protocol work too.  Do you agree?  If not why not?

ALso if we use IPsec implementors have the Simple and PF2_KEY APIs to
use to implement this for DHCP.  These should also work with IPv4 and
IPv6.  These APIs need work but they are a start.

I assume one problem with IPsec is the use of addresss to parse the SPI
for the SA.

I think public keying is the right approach for DHCP?

How do we define policy?  I assume ISAKMP can do this for us?

Are you thinking X.509 certificates?

Also what about the work in LDAP to provide keys as part of the
directory service work?  How does that compare as a tool vs DNSSEC for
storage of keys?  I think we should at least consider it.

In your authentication protocol overview I think we need to be careful
with this taxonomy that it supports DHCPv6.  The messages and state
machines are different from a concept perspective.  

Relay agents should be treated for that case.  In DHCPv6 we made it so
the packet is not altered in transit from the client to the server for
solicit, request, and reply.  But could not achieve this in the
advertisement response.  In the DHCPv4 case the packet is altered in all
cases I think?  Relays should not drive the entire protocol architecture
for DHCP security and should be treated as a special case.  This way the
architecture will work for DHCP parts where Relays are not needed.

Special case bootp issues too.  They are not needed in DHCPv6 or a
Server-to-Server protocol.

Your references need updating.   IPsec appears to be revamping and the
server-to-server protocol is missing Kim Kinnears work alt-01 which is
being combined with Coles work and SCSP.

I guess this work should be in DHCP but I suggest we get review from the
security area too.

I think for the relay case please see how we did the authentication in
the DHCPv6 exts draft using HMAC-MD5 and in a soon to be released next
draft for exts key selection will be included.  I think this will work
in the Relay case for IPv4 or IPv6 except the digest may have to be
recomputed by DHCPv4 Relays for the clients and for DHCPv6
advertisemenet messages...

What are your plans for a next draft?  

I have an idea maybe for DHCPv6 that will "eliminate" relay agents for
DHCPv6 and reviewing it with Charlie now.  It that works then that
special case for DHCPv6 will be gone.  

good job,
/jim