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

["Bernie Volz (volz)" <[e-mail]>]

Sean:

Regarding point 1 and 2, the AUTH option was designed to carry
authentication data. What that data is and how it is used depends on the
*protocol* field. The existing protocols are just the CURRENTLY defined
possibilities. New protocols can define new mechanisms. As 21.2 of RFC
3315 states:

   The Authentication option provides a framework for multiple
   authentication protocols.  Two such protocols are defined here.
   Other protocols defined in the future will be specified in separate
   documents.

---

>However, in that
>way, it is much more complicated for verifier to tell what contents are
>covered by this signature or not (especially when more options are
added
>during transmission).

As I keep trying to tell you this does NOT happen in DHCPv6. Messages
are ENCAPSULATED; options are not "added" along the way (such as is done
in DHCPv4 with the relay-agent option). Once a message is formed (yes,
the entity forming the message adds options), that's it - nothing else
(no other entity) adds anything to the message. And, having the complete
message be part of the "signature" is the proper way to go.

For DHCPv6, the intent was that the way one handles options that have
positional requirements is to ENCAPSULATE them within other options.
That's why we have IA options (IA_NA, IA_TA, and IA_PD) which
encapsulate the addresses (prefixes) and why those IAADDR/IAPREFIX
options can encapsulate other options. The ordering of options at a
particular level is immaterial and should NEVER need to be in any
specific order.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Sean Shuo Shen
Sent: Thursday, July 10, 2008 6:19 AM
To: Mark Stapp (mjs); 'Sheng Jiang'
Cc: [e-mail]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi Mark,
Thanks for the detailed comments. Please see answers in lines.

>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:

Before going through each problem, it will be helpful to clarify a
point:
the mechanism we proposed is not just an alternate auth which uses
asymmetric keys (instead of symmetric keys), it also prevent IP spoofing
because CGA (rfc3972) provides bound between public key and IP address.

>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.

There was a similar discussion with Bernie Volz yesterday and the day
before
yesterday. For unknown reasons, mails from Sheng did not show up on the
mail
list. However, we paste some discussion context the following: 

Overall, we are aiming to provide additional security on top of current
DHCPv6 by using CGA. A CGA address is designed cryptographically bound
with
the client (or server) public key, this public/private key pair can be
used
to provide IP address verification and data integrity WITHOUT any
separate
key management mechanisms. (I don't think any current DHC options can do
IP
address verification.)

When CGA is used as a secure and identity-bound IPv6 address, no extra
authentication key mechanism is needed. Also public key management is
very
easy and does not need to transmit key related material in plaintext
like
DHCP AUTH does. In summary, the newly proposed Signature Option can
achieve
the same security purposes with a simpler and safer foundations - key
management.

Additionally, CGA can be used not particularly for DHCPv6, but also used
for
other scenarios when a save and identity-bound IPv6 address (like SEND)
is
desired.

>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.

The same answer for point 1. We provide new security mechanisms
DIFFERENT
from the current. 
According to the verifications, there are rigorous descriptions in
rfc3971
and rfc3972. Surely we can make a clear reference or give short
descriptions
for sender/receiver activities.

>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.

The order design is to simplify the verification processing at the
receiver
side. It is certainly doable if the signature option is somewhere in the
middle and still protect message contents after itself. However, in that
way, it is much more complicated for verifier to tell what contents are
covered by this signature or not (especially when more options are added
during transmission).

>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.

The reason we do these direct quotations is because DHCPv6 has more
security
issues than our mechanism can solve. What we are quoting is what DHCPv6
[RFC3315] states as security issues and we can solve it.

>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?

As we state at the beginning, our proposal is not only substitute
symmetric
key with asymmetric key, but also verification of IP address and simpler
also safer key management.

>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?

Any scenarios that the sender can use certain source address rather than
unspecific addresses can be protected.

>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?

Reply agents will add its own CGA option and Signature option out of
encapsulated client/server DHCP message.

>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?

I think you are talking about authentication of the message sender. This
is
exactly what the signature does. A malicious node can certainly generate
a
key pair, sign the message with private key and send the public key with
the
message. But the receiver can find out that this public key is not
trustworthy according to local public key list or certs. Certificate is
a
safe way to use asymmetric cryptosystem and it's not the only way.


Thank you!

Sheng & Sean




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-0
0.tx
t
> 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


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