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

[Thomas Narten <[e-mail]>]

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