Authenticated DHCP IETF DHC Working Group Interim Meeting

Thursday and Friday June 4-5, 1998

(Back to dhcp.org home)

Thanks to Kim Kinnear for recording these minutes...

Meeting Minutes:

Attendees:

Peter Ford	Microsoft		peterf@microsoft.com
Kim Kinnear	American Internet	(781) 276-4587	kinnear@american.com
Glenn Waters	Bay Networks	(613) 722-1921	gwaters@baynetworks.com
Rob Stevens	Join Systems	(650) 321-4006	robs@join.com
Bill Arbaugh	University of Pennsylvania	(410) 465-3432	waa@dsl.cis.upenn.edu
Baiju Patel	Intel	(503) 264-2422	baiju.v.patel@intel.com
Carl Smith	Sun	(650) 786-5181	cs@eng.sun.com
Thomas Narten	IBM	(919) 254-7798
Stewart Kwan	Microsoft	(425) 936-0564	skwan@microsoft.com
Munil Shah	Microsoft
Olafur Gudmundsson	TIS	(301) 854-5794	ogud@tis.com
Robert Watson	TIS		robert+ietf@cyrus.watson.org
Ralph Droms	Bucknell University	(717) 524-1145	droms@bucknell.edu
Mike Dooley	Quadritek Systems		mdooley@quadritek.com
Greg Rabil	Quadritek Systems
Arun Kapur	Quadritek Systems

Scenarios and Requirements:

Morning Session: Thursday 6/4/98

Scenarios:

• Enterprise: corporate network
• Service provider: telco/cableco "home" scenario (The service provider grants all of these addresses, there is no DHCP service in the home.)
• Laptop: One client is portable -- needs go between different instances of either server scenario or between server scenarios.
• Public Lan (IETF: free, Hotel: pay)
• Consultant/Roaming
• Hotelling (within a single enterprise)
• College Campus: wide variety of access points
• Devices that can not do authenication:
  • Legacy systems
  • Client's that cannot keep a persistant state
• Home LAN (differs from service provider case in that the service provider case assumes that the provider grants all of the IP addresses, where the home case has a DHCP server in the home).
• Disconnected (variant of the swithed model)
• Always on scenario (@home, roadrunner)
• Smart home controller
• CLEC -- competitive local access. (e.g., ADSL, LEC)
• Relationship to DNS -- now that the DHCP server knows "for sure" about the client, it opens the door to allowing the DHCP server to update the A record.
• Multiple servers, single administrative domain (authority).
• Unattended machines:
  • Server
  • Kiosk

Requirements:

• Client wants a trusted configuration:
  • Client authenticates configuration received. This is the objective, but the means to do this may well be to authenticate the DHCP server.
  • Client authenticates server. There is some value in doing this beyond the value of just the configuration received -- from an audit trail standpoint at least. Another reason to want to do this is to allow one to bring up a server which is *not* authenticated to some of the clients (say for testing), and then give it the right key so that it is a *real* server for all of the clients.
• Server authenticates (and authorizes) machine
• Server authenticates (and authorizes) user
• Supports access control (?)
• Client should be able to demand authentication from server, and server should be able to demand authentication from client. Not just MUST or SHOULD.
• V4 and/or V6
• Must be deployable in practice, which means:
  • Minimize the number of keys the clients needs, which means that DNS and DHCP identities should potentially be a good approach.
  • Minimize the number of places that the "client" needs to be configured.
• Can re-use previous authentication for lease renewal and init-reboot.
• Must support pure client vs pure server.
• Allow tieing user with an IP address.
• Must at least address denial of service attacks.
• Scaling: global vs local?
• Must be able to bootstrap w/shared secret.
• Scaling computational load.
• Should handle REBINDING for DHCP redundancy solution.

Non-requirements: What we're not going to solve.

• Is this inside domain or not.

Possible Future DHCP Capabilities: These are capabilities that we may want to someday extend the DHCP protocol suite to support as well as capabilities that we need to make sure that any DHCP authentication solution doesn't make these capabilities impossible.

• The "home" network above, where there is a DHCP server in the home, could be very well served by a DHCP capability whereby a DHCP server can allocate subnets as well as just addresses.
• Mobile vehicles -- on board LAN.

Presentations of Proposals

Afternoon Session: Thursday 6/4/98

Shared Secret Authentication of DHCP Messages
Ralph Droms

• Source -- Terminal room BOF with Jeff Schiller and Cristian Huitema
• Goal -- Authentication of source and contents of DHCP messages
• Technique -- Each DHCP message includes a message authentication code (MAC) to provide message authentication
• Analysis
  • Good:
    • MAC easy to compute
    • Shared secret easy to manage within an organization
    • Provides a strawman proposal against which others can be compared.
  • Bad:
    • Requires distribution of key to client through out-of band mechanism
    • Doesn't scale (well) across organization ?
    • Provisions for establishing other types of algorithms.

DHC Security Requirements
Olafur Gudmundsson

The Problem:

• Establishing a correct configuration on the client
  • correct for client operation
  • correct for protocol operation

Consequences:

• Client receiving a bad DHCP settings falls victim to masquerades (bad DNS), sends traffic to a sniffer and not a gateway.
• Dishonest relay may lead clients to a bad if the relay doesn't authenticate.

Inside the Client:

• What should be the client's identity?
• Is it the networking module -- is the hardware address enough?

Client Considerations:

• Before a valid DHCP interaction, the client/host has no ability to interact via IP.

Server Considerations:

• Server may be interested in client's identity.

Security Needs:

• Clients and servers (may have a) need to authenticate each other.
• Server needs to check client's privileges.
• Client checks integrity of the server's message.
• Client and server agree on further security.

Issues:

• Does the relay agent need to authenticate? What are the cases:
  • The client authenticates the relay agent.
  • The relay agent authenticates the client.
  • The server authenticates the relay agent.
  • The relay agent authenticates the server.
• What is the client's identity.

DHCP Authentication
Bill Arbaugh Angelos, D. Keromytis, Distributed Systems Laboratory

Overview of Approach:

• Mobility -> Public Key -> lotsa CPU cycles RSA 1024 (signs/s: 38.8 Verify/s:679.7)
• Limit use of Public Key to initial entry into a new "domain" as a modified station-to-station.
• Save secret exchanged and use in conjunction with a HMAC to optimze future messages withing the "domain". Signed Diffie - Hellman.
• Lifetime has not yet been established. Maybe everytime you come up, maybe not.

Recovery Protocol:

     Client Pca					         Server Pca

	DISCOVER -> cnonce, C client ->		    Vca( Cclient)
	                                            Vcnonce(M)
						                   Y = g^y mod p

	<----------  Y, snonce, cnonce, Cs <- DHCPOFFER

	Vca( Cs)
	cnonce == anonce
	Vs( M )
	X = g^x mod p
	k = Y^x mod p

	DHCPREQUEST ---------->  X, snonce, Y ----->	
						                  Y == Y
						                  snonce == snonce
						                  Vclient( M )
						                  K = X^y mod p

	<-----  Packet, SHA1MACk(Packet) <---- DHCPACK

Prototype:

• Implementation under development Public Key code requires about 32KB X.509 code requires about 60KB
• Fits into Droms' "generic" authentication proposal:
  • Assumes that multiple options are concatenated (is this a standard or a feature). (These things are bigger than the standard option.)
  • Certificate size can certainly be a problem (i.e., MTU fragmentation). (These can certainly be large, someone discussed that they could be 2k easily. A minimal certificate is at least 500 bytes).
  • PKI (public key infrastructure) - (DNSSEC, LDAP, Active Directory) This is always a problem.

Conclusion:

• Builds on standard and well known cytpgraphic protocols.
• Provides the benefit of public key, e.g., mobility without requiring its use with each message. Essentially PK

Issues:

• This more or less fills up a packet, and leaves precious little room in the packet for real DHCP options.
• The individual options may easily be bigger than 255 bytes. (Kim added later that the DHCP panel is supposed to be addressing this issue.)
• Must the server have only a depth-of-one certificate chain? If so, this would bother some people.
• Does the server have a requirement for checking for CRL (certificate revocation lists) asks Olafur? The answer is ....

DHCP Authentication
Baiju Patel

DHCP Functions - These things work now, and MUST continue to work

• Configuration without user intervention
• Support portability
• Work in attended and unattended environments

Threats:

• An adversary DHCP server can do lots of damage.
• Client MUST be able to authenticate server and configuration data.

Security Requirements:

• Client MUST be able to authenticate/trust configuration obtained through DHCP
• Server MUST be able to authenticate client
• Should not break basic usage of DHCP

Requirements:

• For portable systems:
  • Client does not know who the server is.
  • Client has all of the credentials needed to complete secure DHCP protocol in different environment.
  • It should still work

Usage:

• Trusted Network: no authentication
• Intranet (IETF): server is authenticated to a client
• Cable Network: client is authenticated to the server
• Paranoid: both client and server are authenticated.

  Pretty much doesn't address denial of service attack.

Usage:

• Migration issues must be addressed
• Servers should be able to support secure and non-secure DHCP clients
• Secure DHCP clients should be able to try security (and provide warning when there is no security).

Options:

• Cannot simply use IPSEC or TLS
  • Broadcast DISCOVER messages are modified by router
  • UDP
• Define a native secure DHCP protocol
• Use existing protocol to secure DHCP
  • Flexible framework
    
    

IPSEC based solution:

• Define a new DHCP option to request/indicate un-trusted configuration
• From client to server: request

IPSEC Securing DHCP:

• Three phases:
  • Phase 1: Bring up minimal networking using un-trusted DHCP.
  • Phase 2: Establish a security associateion between SDHCP client and server.
  • Phase 3: Use DHCP renew (unicast) using security associate renew lease and get parameters.
• This is interesting, says Baiju, because having the first conversation with a server being authenticated

Phase 1:

• Untrused configuration phrase
  • At end of Phase 1, client does not trust configuration
  • Server does not trust client.

Phase 2:

• Establish secure communications channel (use IPSEC).
  • Use temporty parameters to communicate with the DHCP server.
  • Establish a secure channel (e.g., ISAKMP or other means TBD).
    • Authentication
    • Negotiation
    • Key management
• Security association can live for some time.

Phase 3:

• Secure configuration Phase
  • Renew parameters using DHCP renew
    • Unicast messages using IPSEC.
    • Renew lease of the IP address.
    • Get fresh set of parameters

Flexible Security
-----------------:

Either the client or the server can choose to go from
Phase 1 to Phase 2 -- if neither of them choose to do this,
it runs just like it does today.

• Works well with legacy devices.
  
  
• Work well with devices that simply can't support security, as long as they are run in a environment that can support them.

SDHCP server considerations:

• The SDHCP server must provide only
  • IP address (short lease in minute)
  • Default gateway information (if necessary)

Relay Agent Authentication:

IF (and this isn't clear) authenticating the relay agent is
important, then the server should trust the relay agent.

Baiju doesn't see any reason or way to authenticate the relay
agent to the client.

SDHCP Client Considerations:

Do not bring up full networking capabilities unless:

• Secure connection is established.
• DHCP renew succeds.

What about TFTP?

• The client already has a temporary address.
• Two choices:
  • Use secure communications protocol with TFTP!
  • Have the software loaded signed.

    [There was discussion that this is not really a solution. How do you rework old, signed objects. Just having a signed object isn't enough.] Baiju said -- "I would rather not do this approach."

Conversation:

Peter F: You either need to have a way to handle revoked keys
or short lifetimes.

Baiju: Or ... you authenticate the sender.


Denial of Service:

• Does not attempt to prevent such attacks.
• One can deploy other means to prevent some forms of a denial of service attacks.

DHCP V6 Refresher
Ralph Droms

Solicit Advertise

    -> Server
   /
  /
client <--------> Relay Agent <----> Server
  \
   \
    -> Server

• Client can attach authenticator option
• Message that goes out to DHCP servers may be multicast by the relay agent
• BUT ... relay agent changes DHCP header fields. These changes are less extensive than in DHCPV4.

Request/Reply

    -> Server
   /
  /
client <--------> Relay Agent <- Server


        Server

• Client inserts server address in DHCP header
• Relay agent forwards unchanged

Authenticator Option

• Specifies SPI, replay protection and authenticator
• Key is shared secret defined by security association/SPI
• Only used for REQUEST/REPLY (?)

Evaluation of Proposals

Late Afternoon Session: Thursday 6/4/98

Proposals

---

• Olafurs Architecture.
  • Similar to Ralph's with a key exchange mechanism.
  • Pro:
  • Con:

• Ralph's protocol and security w/shared key.
  • Pro:
    • Shared secrets are simple
  • Con:
    • Doesn't scale beyond a single admin domain. But, says Ralph, a client could have multiple shared secrets and use different domains. Requires one time cost to cofigure a new secret for each domain used.
    • Requires preconfiguration of shared secret.
    • Has difficulty deciding which key to use in different domains. Requires manual intervention to change domains OR a domain negotiation protocol.
    • Too small SPI field (I think Olafur said this).

• Bill's Diffie Hellman in Ralph.

  Viewed as Ralph's extended with a key mechanism.

  • Pro:
  • Con:
    • MTU issue.
    • Identification of CA. Could be fixed if the MTU issue were fixed.
    • Flat cert. (1 tier) Also could be fixed if the MTU issues were fixed.
    • Negotiation chain.
    • Online CA data

• RSA using DNSSEC from Olafur.
  • Pro:
  • Con:
    • Dependency on "a" PKI.
    • No pfs?

• Baiju for IPSEC security.
  • Pro:
    • Leverage.
  • Con:
    • Still suscepttible to flook DOS, computational load could be high.
    • State maintenance? Common implementation of ISAKMP involves state maintained in memory. If the server crashes and the client doesn't, then when the client tries to renew, then the packet will go nowhere. Peter says that this is a bug in IPSEC that needs to be fixed -- the client will think it is sitting on top of an active SA and have no way to determine that the SA is not good anymore. If this should happen, then the client will either timeout, break the connection, and reDISCOVER. Or it will reDISCOVER right away, either way breaking the existing TCP connections.
    • Note that session keys for ISAKMP are currently re-generated periodically. This would help if it were changed.

Big Questions

1. Relay agent <-> Client Authentication appears to be a non-issue
2. DHCPv6 Relay Agent authentication needs study
3. How does a client transfer from one server to another in the REBINDING case. This is an issue with either today's two-server DHCP redundancy situation, and an issue with any inter-server or failover protocol-based DHCP redundancy solution in the future.

Wrapup

Friday Morning, June 5, 1998

Goals for Today

---

• Identify what Peter calls "cutpoints" -- what are the real requirements for this capability.
• Do we really want to handle the general case of any client talking to any server? This is, says Peter, a really hard problem.

Target Space

---

1. "Global" -- any client can walk up to arbitrary domain, things work.

   Implemented by:

   • Certs
   • PKI
2. "Somewhat global" -- any client can walk up to arbitrary domain to which it has had a prior relation.
3. How do the client and server agree on which key/credentials to use:
   • manual
   • DHCP changes
4. "Single domain" -- client can only work in a single domain.

   Implemented by:

   • Minimal changes (define new option)

Desired requirements

---

• Simple online enrollment process for initial connection to domain
• After initial online enrollment, subsequent DHCP interactions should take place without further user/manual intervention.
• We do *not* need to be able to handle an unattended enrollment.
• Pre-enrollment should be possible (i.e., you should be able to enroll a system prior to it being installed in place).

Things to solve

---

• Enrollment process
• PnP Process
• Message Authentication
  • Put it in DHCP Packet
    • Pro:
      • We can implement this whenever we want it.
      • If we infrequently use the keys, then they can last over a long time.
    • Con:
      • We have to figure out how to handle situations that IPSEC has presumably already handled.
  • Use IPSEC
    • Pro:
      • Defined today
    • Con:
      • Today's implementations have extra overhead to support encryption keys.