Subject: Questions on authentication draft

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 1 Jun 1999 21:46:48 -0400 (EDT)

Some questions on the authentication draft:

1. The draft describes protocols 0 and 1. 
Is it correct to assume that these
MUST be implemented?

2. I am curious as to how a client and
server agree to use a new protocol. One
possibility is for the DHCP client to indicate
the desired protocol in the DHCPDISCOVER. Then
only servers which offer that protocol will respond
with DHCPOFFERs. If no servers implement that
protocol, then no servers will respond.

Since the client may not know what administrative
domain it is in when it issues the DHCPOFFER, it
is possible for it to guess wrong. If no servers
respond then it will never find out what domain
it is in. Therefore this approach may not be best.

Another possibility is for the client to only
indicate a mandatory protocol in the DHCPDISCOVER. 
The server can then use a mandatory protocol in
the DHCPOFFER, while also including an option indicating
what authentication protocols it will allow the
client to do, and its administrative domain. 

The offered protocols could be based on the client's identity 
as determined from the chaddr or 'client identifier' 
option. The client would then choose one of the 
offered protocols, and formulate an authentication option
appropriate for the administrative domain
indicated by the server. Note that in this
case, the client could use a different protocol
in the DHCPREQUEST than in the DHCPDISCOVER, 
or used by the server in the DHCPOFFER. 

One question that arises is whether the server 
should use the same protocol that the client 
used in the DHCPREQUEST in authenticating 
its DHCPACK, or whether it will always use
a mandatory protocol.  

3. In the case of DHCPINFORM, the client has 
already obtained an IP address, and therefore 
has typically figured out what administrative 
domain it is in. Thus, it should know what 
protocol is appropriate, and can indicate this in the
authentication option included in the DHCPINFORM. 
Is the server required to use the same protocol 
as in the DHCPINFORM in authenticating its DHCPACK or can
it use another protocol? 

If the server cannot support the chosen client protocol, 
but finds the DHCPINFORM otherwise acceptable, and
does support authentication, then it can send a DHCPACK
authenticated with one of the mandatory protocols. If
the server cannot support authentication at all, then
it will send an unauthenticated DHCPACK. This case indicates
misconfiguration since the client should know what administrative
domain it is in. If the client is set to accept 
unauthenticated server messages it will process this 
message. However, if it is set to not accept 
unauthenticated messages, then it will silently
discard the DHCPACK. Does this make sense?

4. I am curious as to the architecture that is used
by DHCP servers in order to support extensibility. For
example, does the DHCP server need to be modified in order
to support a new protocol, or can it act as a passthrough?

5. Is the possibility of a DHCP proxy handled?
This was introduced in the subnet selection draft as
well as in draft-ietf-dhc-agent-options-05.txt. For 
example, the latter draft introduced the possibility 
of a relay agent inserting options. Possibilities
include:

a. We decide now that the idea of a DHCP proxy doesn't
make sense, and therefore explicitly decide not
to support this in the authentication draft (or
in any future document). 

b. The possibility of a DHCP proxy is taken into
account in the authentication draft, so that it
will not have to be reworked in the future. 

For example, the authentication hash could 
be applied up to and including the authentication 
option. The relay agent could then insert 
(but never remove) options after this, but 
they would not be covered by the authentication 
hash.

---

From: "William A. Arbaugh" <[email-masked]>
Date: Thu, 3 Jun 1999 15:15:20 -0400 (EDT)

> Is it correct to assume that these

I feel that Protocol 1 MUST be implemented. Honestly, I don't see much use
for Protocol 0 given that a secret has already been exchanged- you might
as well use the stronger protocol.  The only advantage that I see Protocol
0 having is implementation size.  What's the feeling of the list?

> its DHCPACK, or whether it will always use
I'm open to having the server respond with another authentication protocol
if it already has a security association established with it in that
protocol. If the server is designed to always use the "best available"
authentication mechanism, then this is a nice capability. A problem,
however, is that if the client and server are out of sync with their
security associations then you have a potential livelock situation.

> discard the DHCPACK. Does this make sense?
I think the best approach with INFORM is to have the server respond with
the same authentication mechanism.  If the server doesn't support that
mechanism, then it should respond with a DHCPNAK and force the client back
to INIT. The DHCPNAK should be authenticated if any security associations
exist between the client and server.

> to support a new protocol, or can it act as a passthrough?

Not a bad idea ... sort of like apache modules.

> they would not be covered by the authentication 

I'm working on addressing the relay agent interactions right now. I'll
post my proposed text on it next week.

Bill

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 3 Jun 1999 19:56:56 -0400 (EDT)

>0 having is implementation size.  What's the feeling of the list?

Well, given that protocol 0 is essentially passing a clear text secret,
I'd vote for eliminating it entirely, rather than making it optional.

>A problem, however, is that if the client and server are out of
>sync with their security associations then you have a potential livelock
situation.

Yup. That's why I think it's important to allow the server to indicate
which protocols it supports in a DHCPNAK. That way, a client that
guesses wrong can try again with better knowledge.

>exist between the client and server.

I assume that the DHCPNAK would include an option describing what
protocols the server supports, so as to give the client a decent shot
at success the second time around? And would the DHCPNAK be authenticated
via protocol 1 in this case?

>post my proposed text on it next week.

You might want to take a look at how Mobile IP handled similar issues
with the mobile agent, foreign agent and home agent in the registration
authentication options. Basically, there is are mobile-foreign,
foreign-home and mobile-home authentication options, which are
to be added in a strict order and allow addition of options with
appropriate authentication hash coverage for each.