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

From: Thomas Narten <[email-masked]>
Date: Fri, 11 Oct 2002 13:00:39 -0400

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" <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Paul Duffy <[email-masked]>
Date: Mon, 14 Oct 2002 12:47:39 -0400

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

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Wed, 16 Oct 2002 15:26:10 -0400

Hello Thomas,

Please find responses inline...formed from several conversations with 
various PacketCable participants.

I'll try to have a new draft ready for next week.  We'd greatly appreciate 
your effort to keep this moving along swiftly.

Cheers,

>the WG on this point. (Also, is my understanding here correct?)

RFC 2131 Section 4.4.1 "The time over which the client collects messages 
and the mechanism used to select one DHCPOFFER are implementation 
dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

>maybe just merge Section 9 text into the text here.

No, an MTA DHCP client never populates CCC option content into its any if 
its requests.  The PacketCable MTA provisioning  specification (section 7) 
contains detailed descriptions of when the CCC option is/is not populated 
into DHCP messaging.

PacketCable's intent is to specify option syntax in the draft/RFC, while 
referring to the PacketCable MTA prov specification for usage 
details.  Otherwise, we're going to end up pulling large pieces of the 
PacketCable provisioning spec into this draft...lots of duplication between 
the documents (which I thought we agreed was undesirable).

That said, I can add a sentence or two stating that the client never 
populates CCC option content into DHCP request messages.

>referencing it shouldn't be a problem)? Seems like that would make

As stated in the IETF draft writer's guidelines and the beginning of the 
our draft..."It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as work in progress".  I took this to 
mean referencing non RFC docs is prohibited.  Attempting to maximize the 
speed at which this draft might progress through the IETF process, I tried 
to adhere as faithfully as possible to those guidelines...PacketCable did 
not consider ANY drafts for reference within this draft.

If you feel inclusion of this draft is a hard requirement, PacketCable will 
have to open this issue with the manufacturers...further delaying the 
progress of this draft (not good for us).  I'm also going to need an RFC # 
for the ref ?

>is compression allowed? (probably not useful -- then say so.)

Agreed. PacketCable will state compression "is/is not" allowed in the draft 
(following discussion with the MTA manufacturers).

>  - there will be no additional values, IANA does not need to maintain

Agreed. No additional values are planned. PacketCable will state "IANA does 
not need to maintain a registry".

>clue. (I'm just saying this so that there are no surprises should this

This is a specific need of a PacketCable MTA.  It does not present any 
issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs 
specific, so PacketCable does not see this causing any issues with non 
Cablelabs devices.

>be more general (i.e, not cablelabs specific). But probably too late

Agreed, too late.  PacketCable simply can not absorb the delay that would 
result if we split the realm name sub-option out into a distinct DHCP 
option draft.

>I assume that cablelabs is familiar with this but still wants to go

1. Agreed, we prefer to stick to the DHCP route.
2. PacketCable does not see where this draft applies.  This draft appears 
to describe how one uses DNS to turn a realm name into a KDC 
address.  CCC.6 describes how the realm name initially arrives at the MTA .
3. Again, this would be citing a draft (which I understood to be not 
acceptable)

>everyone knows the option meaning

Agreed.  I'll spell out the names.

>    values early for their implementations and/or specs)

I'll defer comment on this issue to the Cablelabs folks.

> > is the potential for security vulnerabilities.

Agree that the security section could use some beefing up.

>Finally, references should be split into normative/non-normative

nit: I have a single reference section primarily because I followed the 
example of many other drafts/RFCs...assuming this would be adequate.

I'll split it.

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Thu, 17 Oct 2002 12:57:21 -0400

Thomas,

Pall's comment re: unicasting a REQUEST prompted me to re-read the relevant 
section of 2131 and the PacketCable MTA prov spec.  I now have a better 
sense of where the confusion is rooted...

>dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

The PacketCable MTA prov spec, as it is currently worded, could give the 
reader the impression that an MTA unicasts its DHCP REQUEST to a specific 
server identified via CCC.1/.2.  This is not the intent, nor how the 
present implementations currently operate.

The MTA applies CCC.1/.2 as a filter to all received OFFERS, selects one, 
then broadcasts its REQUEST (per RFC 2131).

PacketCable is modifying the MTA prov spec (in the next few days) to 
clearly state that the REQUEST is broadcast.

Good point Pall !

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Oct 2002 12:15:27 -0400

Paul Duffy <[email-masked]> writes:

> RFC 2131 Section 4.4.1 "The time over which the client collects
> messages and the mechanism used to select one DHCPOFFER are
> implementation dependent".  PacketCable does not feel CCC.1/.2 in
> any way modifies the RFC.

OK, I think we're OK then. What would be good is if the words in the
document communicated clearly what is going on (at a high-level) so
its clear how the option is used (at a high-level) and that the usage
is consistent with the DHC specs.

> the documents (which I thought we agreed was undesirable).

Right.

> populates CCC option content into DHCP request messages.

This is all I'm asking for. So that at a high-level one can understand
what is going on. The details can be elsewhere.

> progress of this draft (not good for us).  I'm also going to need an RFC # 

Note: dhc-concat has been approved by the IESG, so this document
doesn't need to wait for it.

The question is, should this document require the other as well? Seems
to me like that might be useful. Hence, I asked.

> specific, so PacketCable does not see this causing any issues with non 

If there are no issues with the kerberos RFCs, why do you need an
option to tune how they behave?

In terms of how to proceed, you might consider posting proposed text
for each of the items prior to reissuing the draft. That way, you're
more likely to get quick review of the new wording and that might save
on the need for an additional revision.

Thomas

---

From: Paul Duffy <[email-masked]>
Date: Tue, 22 Oct 2002 22:43:58 -0400

Thomas,

Inline please...

>to me like that might be useful. Hence, I asked.

I assume you mean "should the CCC option require concat".  We're discussing 
this at PacketCable.

>option to tune how they behave?

Several comments from various PacketCable team members:

"Kerberos-5 protocol (RFC-1510) does not define any specific backoff and 
retry algorithm. Consequently, all specifics of the backoff and retry 
mechanism for AS- and AP-exchange are defined by the PacketCable security 
spec, and involves the parameters supplied by the DHCP Server to 
parameterize the Kerberos Authentication for Provisioning Service."

Further...

"None of the subsequent IETF drafts such as Kerberos clarifications define 
it either - I don't think that a specific retry mechanism was ever 
considered to be in scope of the Kerberos IETF working group."

Thus the need for the sub-options.

>for each of the items prior to reissuing the draft.

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]