Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

[Mark Stapp <[e-mail]>]

Hello,

it's certainly worthwhile to explore use of asymmetric keys to secure 
dhcpv6, so it's helpful to see this work. but there are a number of 
issues with the details in this draft:

1. it's not clear why the existing extensible authentication option 
couldn't be used. I believe I could map everything proposed for the new 
"Signature Option" into the existing option, so I have to ask: why not 
do that? I suspect that you can make a case that it would be awkward to 
try to fit the CGA parameters data into the body of the authentication 
option, and so make the case for the new CGA params option. but I'd like 
to see that tradeoff discussed.

2. an important benefit of using the existing option and specification 
that supports it is that the text in rfc3315 is much more detailed and 
rigorous than the text in this draft. the 3315 text is clear and correct 
about the actual computations based on the structure of dhcpv6 messages. 
I don't think there'd be much benefit in extending this draft so that it 
duplicates that existing specification text. I'd much rather see a focus 
on the specifics of the steps required to produce and verify the 
key-pair-based hash and signatures.

2a. doing (2) would help get you out of thinking that you depend on the 
ordering of options - the text in 3315 is correct about that. I second 
Bernie's point that there's no need to require special ordering.

3. there are an unusual number of instances of direct quotation from 
RFCs. IMO, it's generally better to refer to RFCs because small quotes 
can be misleading without the context of an entire protocol. it's one 
thing to use quotations if you're trying to establish a clarification of 
the meaning of a specific passage, but I don't think that's what's 
happening here.

4. it would be more useful to describe a general-purpose way to use 
asymmetric key pairs. the only things specific about the CGA application 
as described here is the details of the use of the CGA parameters 
structure and the dependency on seeing the client's original IP source 
address. but isn't that really just a specialized case, that only 
extends the general case in a couple of ways?

5. do you intend this only to be used when DHCPv6 is used to convey 
configuration options? are there any differences required to support 
address configuration, or prefix delegation?

6. what happens in relayed environments - where the client's original IP 
source address is no longer visible to the DHCP server? is this just 
meant to be hop-by-hop integrity protection?

7. I don't see anything here about authorization. anyone who can 
generate a key pair can use this, right? so ... it's just message 
integrity protection? do you propose to configure clients with server or 
relay public keys? something like SEND, would it be interesting to 
authorize relays and servers via certs? or validate clients' keys with 
certs?

Thanks,
Mark

Sheng Jiang wrote:
> A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are 
> welcome!
>  
> Filename:    draft-jiang-dhc-secure-dhcpv6
> Version:    00
> Staging URL:    
> http://www3.ietf.org/proceedings/staging/draft-jiang-dhc-secure-dhcpv6-00.txt
> Title:     Secure DHCPv6 Using CGAs
> Creation_date:    2008-07-04
> WG ID:     Indvidual Submission
> Number_of_pages: 14
> Abstract:
> The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP 
> servers to pass configuration parameters. It offers configuration 
> flexibility. If not secured, DHCPv6 is vulnerable to various attacks  
> particularly fake attack. This document analyzes the security issues of 
> DHCPv6 and specifies security mechanisms, mainly using CGAs.
>  
> Best regards,
> 
> Sheng JIANG, Ph.D.
> 
> IP Research Department, Networking Research Department, Network Product 
> Line, Huawei Technologies Co. Ltd.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg