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

[Mark Stapp <mjs@cisco.com>]

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg