Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt

[Paul Duffy <[e-mail]>]

Thank you...we'll have a detailed response Wednesday.

Cheers,

At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote:
>Background: there was a quite a lot of private discussion/conference
>calls a month or two ago on this document, followed by a revised
>document. Here is my review of the current document.
>
>Thomas
>
> >   8.1. TSP's DHCP Server Address Sub-Options
>
>Seems to me that this options does (however subtly) modify DHC client
>behavior. My understanding is that CCC option 1/2, which
>lists a primary/backup DHC server are sent to the CM, which then
>communicates those two addresses to the MTA (a separate entity). The
>MTA then invokes DHC on its own, but is only allowed to talk to the
>servers whos addresses it received from the CM. In normal DHC, the
>client isn't restricted in anyway in what servers it communicates
>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>protocol, albeit subtly and perhaps not signficantly. I am not
>particularly comfortable with this, but would like to hear more from
>the WG on this point. (Also, is my understanding here correct?)
>
> >    Due to specific needs of the MTA configuration process (described in
> >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> >    option.  When requested, both the CM and TSP DHCP servers will
> >    populate this option into DHCP responses.
>
>
>Doesn't the client also provide this option and fill in some info?
>better to say this above (one or two sentences here would suffice). Or
>maybe just merge Section 9 text into the text here.
>
>Should this document add a normative references to
>draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
>referencing it shouldn't be a problem)? Seems like that would make
>sense.
>
> >    - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
> >      [7] section 3.1. Note that a terminating 0 is required.
>
>is compression allowed? (probably not useful -- then say so.)
>
>For CCC option 3, does IANA need to maintain a registry for other
>"types"? An IANA considerations would seem to be  needed. It could say:
>  - allocation of future types requires IETF Consensus (or whatever)
>  - there will be no additional values, IANA does not need to maintain
>    a registry
>  - something else?
>
>The CCC options for configuring Kerberos parameters seems odd to me
>(what kerberos document talks about the need for tuning these
>parameters?). The IESG may want this reviewed by someone with kerberos
>clue. (I'm just saying this so that there are no surprises should this
>issue come up later.)
>
>Also, the kerberos REALM name option seems like one that could easily
>be more general (i.e, not cablelabs specific). But probably too late
>for this. Also:
>
>"Douglas E. Engert" <[e-mail]> writes:
>
> > You should also look at:
> > " Distributing Kerberos KDC and Realm Information with DNS"
> > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt
>
> > Which describes how to find a KDC using DNS. I should point out that
> > W2K, MIT and I think Hiemdal all have this implemented.
>
>I assume that cablelabs is familiar with this but still wants to go
>the DHC route?
>
> >    Cablelabs client devices issue DHCP requests that include DHCP
> >    options 55 and 60.  Option 55 will request the CCC option from the
>
>nit: would be good include neumonic names (e.g., ORO and class ID)
>here rather than just using the option number rather than assuming
>everyone knows the option meaning
>
> >    IANA is requested to register codes for future CableLabs Client
> >    Configuration Sub-options with an "Expert Review" approval policy as
> >    described in RFC 2434 [2]. Future proposed sub-options will be
> >    assigned a numeric code chosen by CableLabs, which will be
> >    documented in the Internet Drafts that describe the sub-options. The
> >    code assignment will be reviewed by a designated expert from the
> >    IETF prior to publication in an RFC.
>
>1) I think it should be IETF consensus, not expert review. these
>    options need to be reviewed by the IETF before they get implemented
>    and cast in stone. IETF Consensus is the safest way to ensure that
>    this happens.
>
>2) IANA chooses the values (as it typically does), not
>    cablelabs. (Having cablelabs chose smells a bit like they want the
>    values early for their implementations and/or specs)
>
> >    13.  Security Considerations
> >
> >    This draft relies on the DHCP protocol [4] for authentication and
> >    security, i.e. it does not provide in excess of what DHCP is (or will
> >    be) providing. It does not expose any security threats beyond what is
> >    currently exposed by other DHCP options.
>
>The security considerations section is inadequate. It should say
>something about the options themselves and what the security
>implications are should the options be spoofed, etc. That is, what are
>the security issues related to the specific options discussed in the
>document? Is it required that some sort of DHC authentication be used
>in order to prevent vulnerabilities (say) to the configuration of the
>kerberos stuff?
>
>Note on the kerberos options, the following comment was made
>(privately):
>
>Jonathan Trostle <[e-mail]> writes:
>
> > Section 13 (Security Considerations) indicates they are relying on
> > the DHCP protocol for authentication and security (should be more
> > precise about what security services).
>
> > If the new option data is manipulated, various DoS attacks are possible.
> > One option, Kerberos realm name, is potentially more serious. By modifying
> > the realm, the attacker can change the user's TSP (if I recall correctly,
> > packetcable uses pkinit where the client authenticates the KDC by the
> > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP
> > can act as a TSP for any user and then have access to the user's VoIP
> > and multimedia data. So it would be a good thing if the Kerberos realm
> > name is protected from modification in the DHCP protocol. Alternatively,
> > changing the realm name could be a means by which one TSP steals customers
> > from another TSP without the customer's permission.
>
>then later,
>
>Jonathan Trostle <[e-mail]> writes:
>
> > Tom,
>
> > Yes, there should be some extra wording in the security considerations at
> > least. I recall an argument that layer 2 encryption protects the link
> > between the modem and the head end, and the DCHP server may be at the head
> > end. But there should definitely be some words indicating that there is
> > protection for the DHCP messages at some layer. If this draft is used in
> > some other scenario (or even in the packetcable scenario possibly) then 
> there
> > is the potential for security vulnerabilities.
>
> > Jonathan
>
>Finally, references should be split into normative/non-normative
>sections.
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg

--

Paul Duffy
Cisco Systems, Inc.
[e-mail]


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