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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2008 06:50:26 -0400

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. It is not aiming to
replace AUTH option.

The AUTH option is a means to communicate authentication related
information. New authentication protocols can be defined. By defining
new types, different (or no) key management mechanisms may be needed
depending on what that new authentication protocol requires.

	Regarding to the "last" option, as you said, we put the
signature option to be last one in order to protect payload and options
before it. If some option appears after signature option, its data
integrity can not be guaranteed by the user who generates the message.
In relay scenario, a relay agent might add an option behind the original
DHCP message (in this case, there is an option after original DHCP
message signature option), but the relay agent will also generate
another signature option to protect the whole relay message, thus the
signature option is still the last one.

That isn't how DHCPv6 works. A relay agent ENCAPSULATES the relayed
message in a Relay Message option and hence never adds an option to the
client's (or previous relay's) message.

- Bernie

________________________________

From: Sheng Jiang [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 5:18 AM
To: Bernie Volz (volz); [email-masked]
Cc: [email-masked]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi, Bernie,
 
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. It is not aiming to replace AUTH
option.
 
Regarding to the "last" option, as you said, we put the signature option
to be last one in order to protect payload and options before it. If
some option appears after signature option, its data integrity can not
be guaranteed by the user who generates the message. In relay scenario,
a relay agent might add an option behind the original DHCP message (in
this case, there is an option after original DHCP message signature
option), but the relay agent will also generate another signature option
to protect the whole relay message, thus the signature option is still
the last one.
 
Best regards,

Sheng & Sean

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

________________________________

	From: Bernie Volz (volz) [mailto:[email-masked]] 
	Sent: Monday, July 07, 2008 9:36 PM
	To: Sheng Jiang; [email-masked]
	Subject: RE: [dhcwg] A new draft of
draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

	While I probably should study the CGA RFC (3972), I'm wondering
why the standard RFC 3315 AUTH option wasn't used for this purpose (ie,
drop the OPTION_SIGNATURE and specify how the AUTH option from RFC 3315
can be used instead)? Or is there a reason why both CGA and AUTH might
be used together?
	 
	Requiring an option to be "last" is a terrible idea and should
be avoided. Also, why does it matter where the option is? The point it I
think to take the entire DHCPv6 message and apply the hashing to it.
DHCPv6 doesn't use relay-agent options as DHCPv4, so there's no reason
to "stop" at any point.
	 
	- Bernie

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sheng Jiang
	Sent: Friday, July 04, 2008 4:59 AM
	To: [email-masked]
	Subject: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

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

---

From: Sean Shuo Shen <[email-masked]>
Date: Wed, 09 Jul 2008 09:54:23 +0800

Hi, Bernie,

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. It is not aiming to replace AUTH option.

The AUTH option is a means to communicate authentication related
information. New authentication protocols can be defined. By defining new
types, different (or no) key management mechanisms may be needed depending
on what that new authentication protocol requires.

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

Regarding to the "last" option, as you said, we put the signature option to
be last one in order to protect payload and options before it. If some
option appears after signature option, its data integrity can not be
guaranteed by the user who generates the message. In relay scenario, a relay
agent might add an option behind the original DHCP message (in this case,
there is an option after original DHCP message signature option), but the
relay agent will also generate another signature option to protect the whole
relay message, thus the signature option is still the last one.

That isn't how DHCPv6 works. A relay agent ENCAPSULATES the relayed message
in a Relay Message option and hence never adds an option to the client's (or
previous relay's) message.

You are right; the relay agent never adds an option to the client's message.
What we mean is that relay agent might add an interface ID option to the
relay message, this interface ID option will be behind the relay message
option which encapsulates the relayed message. Such a sample relay message
will look like:

relay message (MSG type, hop count, link-address, peer-address)  + relay
message option (containing relayed message) + interface ID option + CGA
signature option

Thank you!

Sheng&Sean

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2008 22:09:11 -0400

You are right; the relay agent never adds an option to the
client's message. What we mean is that relay agent might add an
interface ID option to the relay message, this interface ID option will
be behind the relay message option which encapsulates the relayed
message. Such a sample relay message will look like: relay message (MSG
type, hop count, link-address, peer-address)  + relay message option
(containing relayed message) + interface ID option + CGA signature
option

The CGA signature option would have been added by a client before
sending the "containing relayed message" and hence that part of the
message, which is the message that the server processes (and then relays
back via the relay by building relay-forws from the relay-replys). Thus,
there is no need for "last" option.

- Bernie

From: Sean Shuo Shen [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 9:54 PM
To: Bernie Volz (volz); 'Sheng Jiang'; [email-masked]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi, Bernie,

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

 

You are right; the relay agent never adds an option to the client's
message. What we mean is that relay agent might add an interface ID
option to the relay message, this interface ID option will be behind the
relay message option which encapsulates the relayed message. Such a
sample relay message will look like:

 

Thank you!

Sheng&Sean

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2008 23:02:31 -0400

That's fine but neither need to be last at all.
 
- Bernie

Sent: Tuesday, July 08, 2008 10:44 PM

Hi, Bernie,

You are right; the relay agent never adds an option to the client's
message. What we mean is that relay agent might add an interface ID
option to the relay message, this interface ID option will be behind the
relay message option which encapsulates the relayed message. Such a
sample relay message will look like: relay message (MSG type, hop count,
link-address, peer-address)  + relay message option (containing relayed
message) + interface ID option + CGA signature option

In the reply message example, there are actually two signature options.
The encapsulated client message has a signature signed by the client,
this signature proved who send the original message. It is the last
option of original, client message. The second signature option is
produced by the relay agent, this signature proved who relayed the
original message. It is the last option of new, reply message. Thus both
the client and relay agent are authenticated. We say "last" to mean that
client put his own signature option on the back of his message and relay
agent put his own signature option on the back of his relay message.

Thank you!

Sheng&Sean

Hi, Bernie,

 

 

 

Thank you!

Sheng&Sean

---

From: Sean Shuo Shen <[email-masked]>
Date: Wed, 09 Jul 2008 10:44:08 +0800

Hi, Bernie,

You are right; the relay agent never adds an option to the client's message.
What we mean is that relay agent might add an interface ID option to the
relay message, this interface ID option will be behind the relay message
option which encapsulates the relayed message. Such a sample relay message
will look like: relay message (MSG type, hop count, link-address,
peer-address)  + relay message option (containing relayed message) +
interface ID option + CGA signature option

The CGA signature option would have been added by a client before sending
the "containing relayed message" and hence that part of the message, which
is the message that the server processes (and then relays back via the relay
by building relay-forws from the relay-replys). Thus, there is no need for
"last" option.

In the reply message example, there are actually two signature options. The
encapsulated client message has a signature signed by the client, this
signature proved who send the original message. It is the last option of
original, client message. The second signature option is produced by the
relay agent, this signature proved who relayed the original message. It is
the last option of new, reply message. Thus both the client and relay agent
are authenticated. We say "last" to mean that client put his own signature
option on the back of his message and relay agent put his own signature
option on the back of his relay message.

Thank you!

Sheng&Sean

  _____  

Hi, Bernie,

 

 

 

Thank you!

Sheng&Sean