Re: [dhcwg] comments on draft-ietf-dhc-v4-threat-analysis-00.txt

[Mimi Zohar <zohar@us.ibm.com>]

Mark,

Thank you for taking the time to respond
to the last call.   My comments are prefixed with MZ>.

Mimi


[1] scope

- relay <-> server messages are included in
the scope, but issues
with those messages aren't discussed within the draft. in fact,
section 4.4.2 could be read as excluding them from consideration.

MZ> Somehow during one of the rewrites, this discussion
was removed
from the document. As I recall, we excluded it since
security of the 
relay <-> server messages, could be achieved
through other means 
(e.g. IPSec). 

- the scope includes one-way authentication (server
to client) as
a special case, to permit clients to detect and ignore rogue
servers. this case isn't discussed in the body of the document.

MZ> Section 4 Security Requirements makes the case
for needing
authentication, which in section 4.2 Capabilities
lists the four 
different options: no authentication, mutual authentication,

client authentication, server authentication.  
 

[2] list of threats

- what about forged or spurious RELEASE or DECLINE?
we've seen DOS
attacks that are intended to exhaust the servers' address pools
using forged DECLINEs.
MZ: Good point, will add.

- would it be useful to distinguish the categories
a little
differently? for example, there is a set of issues that are
important in an enterprise network that's using 802.1x, another
set of issues in a home net environment, another set in isp
environments, and another set in public-access network
'hot-spots'. would talking about these concrete situations be
helpful?

MZ:  We tried a number of different ways, nothing
really worked well. 
Bernard Aboba just suggested differentiating them
by server/client issues.  
We haven't tried your suggestion.

[4.3]

- not sure about the analogy to www clients. browsers
don't ship
with certs: they ship with a canned list of cert-signing
authorities. and there's no authentication of the clients at any
significant scale. the servers authenticate to the clients - if
the clients bother to check CRLs.

the dhcp clients would _each_ have to get a cert to
use for some
sort of cert-based rfc3118, and that's the barrier. they don't
really need one for anything else, so asking that their admins
generate one for each of them is probably asking too much.

MZ> I realize that presently it is uncommon for
clients to have
certificates; however, computers are today being shipped
with TCPA
chips, which perform public key cryptography without
exposing the 
private key to the system.

isn't it largely true that the authentication happens
somewhere else -
at the access point, using eap/leap/docsis ranging/etc ? I think this
is something worth discussing in some depth. It's unlikely to be
deployable to force every dhcp client to configure something extra
just for dhcp.

MZ> Agreed when you're speaking about wireless.
 I'm not familiar with docsis.

Is it in-scope to talk about revisions to rfc3118?
section [3.4]
implies that there are shortcomings in the design choice that was made
to piggy-back auth on the existing message exchanges. For example,
adding a couple of messages to allow for negotiation between client
and server, or adding messages that could let the client and server go
through a four-message exchange (carrying EAP, maybe?) might be worth
considering.

MZ> I assume revisions to rf3118 is an option,
but defer to someone else.