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

From: Mark Stapp <[email-masked]>
Date: Tue, 11 Nov 2003 11:34:23 -0600

I'd like to offer a few comments on the threat analysis draft. Thanks to 
the authors for initiating this discussion and review.

Regards,
Mark

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

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

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

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

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.

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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mimi Zohar <[email-masked]>
Date: Tue, 11 Nov 2003 16:51:41 -0500

Mark,

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

Mimi

[1] scope

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

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.

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]

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.

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

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