Subject: [dhcwg] “Secure DHCPv6 Using CGAs” draft-jiang-dhc-secure-dhcpv6-01

From: JiangSheng 66104 <[email-masked]>
Date: Wed, 14 Jan 2009 05:42:42 +0800

The below “Secure DHCPv6 Using CGAs” has been updated, according to comments that have been discussed in dhc maillist and IETF meeting. Since early collaboration is requested for this CGA and DHCP interaction work, this update message is sent to both CSI WG and DHC WG.

Best regards,

Sheng

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. 

        Title : Secure DHCPv6 Using CGAs 
        Author(s) : S. Jiang, S. Shen 
        Filename : draft-jiang-dhc-secure-dhcpv6-01.txt 
        Pages : 14 
        Date : 2009-1-8 
        
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. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-jiang-dhc-secure-dhcpv6-01.txt

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Jan 2009 23:03:08 -0500

I'm (still) a bit concerned about:

5.2. Signature Option 

   The Signature option allows public key-based signatures to be 
   attached to a DHCPv6 message. The Signature option COULD be any place

   within the DHCPv6 message. It protects all the DHCPv6 header and 
   options before it. Any options after the Signature option can be 
   processed, but it should be noticed that they are not protected by 
   this Signature option. The format of the Signature option is 
   described as follows: 

Why is this protection positional? Can you explain why you think this is
useful? Why not secure the entire message with this? 

The only interesting issue is if a client's message includes both a
SIGNATURE and AUTH (RFC 3315) option -- since in this case, two
different hashes over the entire message would need to be run and that
doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH
option. (The AUTH option would include the SIGNATURE option as RFC 3315
already requires that it cover the entire client message.)

I wonder whether this positional text is a hold over from DHCPv4 to
handle the Relay Agent Option (82) - which is added at the end? Relaying
in DHCPv6 is done far differently.

If there's a reason why the SIGNATURE needs to be positional, we still
have the AUTH option conflict that would need to be discussed (if the
AUTH option isn't excluded from coverage regardless of where it appeared
in the message, it would require the AUTH to follow the SIGNATURE).

---

The draft allows a node to be a DHCPv6 relay agent. I think more text is
required to detail this. Suppose you have:
	Client --> Relay 1 --> Relay 2 --> Server

If Relay 1 includes a SIGNATURE option, and relay 2 does not support
this, what should the server do? How does the server know whether relay
2 validated the SIGNATURE of Relay 1 or not (is there a requirement for
the relay to validate -- it is after all a "node")? Should the server
validate all SIGNATURE options (as in this case, there could be 3 - one
in the Client message, one in the Relay 1 message (which encapsulates
the client's message), and one in the Relay 2 message (which
encapsulates Relay 1's message (which encapsulates the client's
message))?

Perhaps the ability for a relay to be a node should be removed? It keeps
it simpler.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of JiangSheng 66104
Sent: Tuesday, January 13, 2009 4:43 PM
To: [email-masked]; [email-masked]
Subject: [dhcwg] "Secure DHCPv6 Using CGAs"
draft-jiang-dhc-secure-dhcpv6-01

The below "Secure DHCPv6 Using CGAs" has been updated, according to
comments that have been discussed in dhc maillist and IETF meeting.
Since early collaboration is requested for this CGA and DHCP interaction
work, this update message is sent to both CSI WG and DHC WG.

Best regards,

Sheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 18 Jan 2009 12:21:46 -0500

I noticed that the draft is actually self conflicting in terms of the
Signature option:

5.2. Signature Option 

   ... The Signature option COULD be any place 
   within the DHCPv6 message. It protects all the DHCPv6 header and 
   options before it. Any options after the Signature option can be 
   processed, but it should be noticed that they are not protected by 
   this Signature option. ...

6.1. Processing Rules of Sender 

   ... The Signature option MUST be constructed as explained in 
   Section 5.2 and be the last DHCPv6 option. 

Again, per my earlier comments I think its position should not matter.

---

In 6.2. Processing Rules of Receiver:

   The receiving node MUST verify the Signature option as follows: the 
   receiver MUST ignore any options that come after the Signature
option. 

What about the contents of the Signature option itself? The document
needs to indicate which, if any, portion of the Signature option is
included in the signature hashing. (The SEND RFC (3791) excludes the
signature option.)

Note that earlier in section 5.2. Signature Option is written:

                       6. The content between the option-len field and 
                       the signature field in this Signature option, in 
                       the format described above.

Might be best to just refer to section 5.2 instead of duplicating the
information (less chance for it to conflict)?

---

This probably exposes my ignorance of CGAs, but is the intent in this
draft that the CGA source address used by the client remains the (CGA)
link-local address?

If this is the case (client uses CGA link-local as IPv6 source address),
all is well.

If the CGA address is not the link-local, then there is a conflict with
RFC 3315:

16. Client Source Address and Interface Selection

   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
   through the interface for which configuration information is being
   requested.  However, the client MAY send the message through another
   interface attached to the same link, if and only if the client is
-> certain the two interfaces are attached to the same link.  The client
-> MUST use a link-local address assigned to the interface for which it
-> is requesting configuration information as the source address in the
-> header of the IP datagram.

   When a client sends a DHCP message directly to a server using unicast
   (after receiving the Server Unicast option from that server), the
   source address in the header of the IP datagram MUST be an address
   assigned to the interface for which the client is interested in
   obtaining configuration and which is suitable for use by the server
   in responding to the client.

A non-link-local address is only allowed if the server previously
provided the client with the Server Unicast option.

---

The following text is rather odd:

   If a node has been configured to use Secure DHCPv6, the node MUST 
   send a message using a CGA, which be constructed as specified in 
   Section 4 of [RFC3972], as the source address unless they are sent 
-> with the unspecified source address. In the message, both the CGA 
   option and the Signature option MUST be present in all DHCPv6 
   messages. The CGA Parameter field in the CGA option is filled 
   according to the rules presented above and in [RFC3972]. The public 
   key in the field is taken from the configuration used to generate the

   CGA, typically from a data structure associated with the source 
   address. The Signature option MUST be constructed as explained in 
   Section 5.2 and be the last DHCPv6 option. 

DHCPv6 never uses an unspecified source address.

Also be good to use "CGA Parameter option" instead of "CGA option", as
that is what the option is called. This is an issue throughout the
document.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Saturday, January 17, 2009 11:03 PM
To: JiangSheng 66104; [email-masked]; [email-masked]
Subject: Re: [dhcwg] "Secure DHCPv6 Using
CGAs"draft-jiang-dhc-secure-dhcpv6-01

5.2. Signature Option 

---

- Bernie 

-----Original Message-----

Best regards,

Sheng

---

From: JiangSheng 66104 <[email-masked]>
Date: Tue, 20 Jan 2009 06:07:19 +0800

Bernie,

Thanks so much for your comments. This really helps our work become better. Our design/solution is still remaining open for better. So do comment/discuss further. Please see my reply in lines.

Best regards,

Sheng

> useful? Why not secure the entire message with this?

We are thinking how the receiver side is able to decide the protected part of a DHCP message in order to get the right input for verification computing. There are three possible solutions in our minds: 1, the signature option is the last-generated option, it protects all options, including itself; 2, the signature option has a set of sub-options to clear indicate which options are protected; 3, the position of the signature indicates its protected range.

The first design is the best solution except for two scenarios: a, there are some options, such as the AUTH option you mentioned, request to be last generated too; b, some options may added at the end of a DHCP message after signature options has been generated. We don't have a clear example for this. But we cannot rule out the possibility. The second design is too complicated giving the fact we cannot limit the number of options. Then, the third design becomes the most reasonable one for us.

> already requires that it cover the entire client message.)

En... This is interesting. The AUTH option has already taken the last-generated position. And I assume by the time of design this, the designers already rule out the possibility that some option may request to be generated/added after AUTH option. Now, we have one, at least, it is equally to be last generated comparing the AUTH option.

> in the message, it would require the AUTH to follow the SIGNATURE).

En... this could be a possible answer, I guess. Both AUTH and SIGNATURE are only protects what in front of them. So, there would have no fixed order for both their positions and generation order. AUTH can be behind SIGNATURE, vice verse. This may also release the restriction "Any DHCP message MUST NOT include more than one Authentication option." [21.2, RFC 3315]

> Perhaps the ability for a relay to be a node should be removed? It keeps

I agree that we should put more text to explain the process for relaying if we get sure relaying need to be protected. In the above scenario, I don't think reply agent needs to validate the SIGNATURE option unless it uses some information from its received DHCP message. The server, in this case, needs to validate all 3 SIGNATURE options. However, if relay agent does not add its only options, the signature option from it may not be very useful and the SIGNATURE options from relay agent are optional.

Best regards,

Sheng

---

From: JiangSheng 66104 <[email-masked]>
Date: Tue, 20 Jan 2009 06:07:43 +0800

HI, Bernie,

Thanks again. Please see my reply in lines.

Best regards,

Sheng

> Again, per my earlier comments I think its position should not matter.

This text in 6.1 is a careless mistake. It remains unchanged from 00 version. It will be fixed in the future version.

> included in the signature hashing. (The SEND RFC (3791) excludes the

Yes, this Signature option protects its own header. We describe this in the signature field of Signature option, section 5.2

> information (less chance for it to conflict)?

Ok, we will add quotation there to make it clearer.

> provided the client with the Server Unicast option.

I believe we are talking about link-local CGAs here. However, "link-local (CGA) addresses are vulnerable because the same prefix is used by all IPv6 node", [section 7.2, rfc 3972]. Fortunately, the same section provides a hash extension mechanism to protect link-local address.

> DHCPv6 never uses an unspecified source address.

This came from the similar claim in SEND. Ok, "unless they are sent
> -> with the unspecified source address" will be revomed.

> that is what the option is called. This is an issue throughout the

Will change it. "CGA Parameter option" is the name to be.

My thanks, again. Best regards,

Sheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 Jan 2009 17:32:29 -0500

Note that while the AUTH option needs to be generated last (since it
covers the entire message), it does not have to be the LAST option in
the message.

In DHCPv6, no entity (relay agent or server) adds options to the
messages while it is 'in-flight' as is done for the DHCPv4 relay agent
option. Once the message is formed, a relay may encapsulate it in a
Relay Message option in its own message, but that does NOT alter the
original message.

I think:
- CGA Signature can be anywhere in the message.
- CGA Signature covers the ENTIRE message EXCEPT for some of its own
fields and the AUTH option.
- The AUTH option covers the ENTIRE message, including the CGA Signature
option.

This way, the AUTH gives complete protection of the entire message as it
was intended to.

I'm not sure if it will be common for the SIGNATURE and AUTH to be used
together, as it seems to me that using the AUTH message gives the better
protection to begin with. But, if they are used together, it works.

I'd also highly recommend the CGA stuff be limited to clients and
servers (a client can add/server validate). Note that a server can NOT
use this for to provide proof of a CGA (the server's source address)
because this ONLY works when the client and server are on the same link.
If a relay agent is involved, the source address of the packet sent to
the client is a relay agent address and thus the Signature would never
validate.

This I think makes this much simpler (though perhaps it defeats some of
the purpose).

---

I also haven't yet figured out (again, perhaps due to my lack of fully
understanding all of this CGA stuff) what the benefit of this is. It
seems to me that if a client needs a public and private key, and the
server needs the public key, that using the AUTH option could be
possible and would be far better? Perhaps all you need here is a
mechanism for the key to be communicated -- which might mean new values
of the AUTH Option protocol and algorithm fields and a definition for
what is in the "authentication information". Also, this might then allow
client-to-server and server-to-client authentication since the "CGA" is
itself not involved.

And, perhaps this works better to match the SEND model which is (if I
recall correctly) where the router is using a CGA and wants to prove
that it is a valid router to the client -- so, you ideally want the
DHCPv6 server to prove that is a valid DHCPv6 server to the client (and
the client only needs the public key -- not a private key). Thus, the
server-to-client authentication is really of the most interest? And,
this would now work (whereas it does not using the original design).

- Bernie

-----Original Message-----
From: JiangSheng 66104 [mailto:[email-masked]] 
Sent: Monday, January 19, 2009 5:07 PM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RE: [dhcwg] "Secure DHCPv6 Using CGAs"

Bernie,

Thanks so much for your comments. This really helps our work become
better. Our design/solution is still remaining open for better. So do
comment/discuss further. Please see my reply in lines.

Best regards,

Sheng

> useful? Why not secure the entire message with this?

We are thinking how the receiver side is able to decide the protected
part of a DHCP message in order to get the right input for verification
computing. There are three possible solutions in our minds: 1, the
signature option is the last-generated option, it protects all options,
including itself; 2, the signature option has a set of sub-options to
clear indicate which options are protected; 3, the position of the
signature indicates its protected range.

The first design is the best solution except for two scenarios: a, there
are some options, such as the AUTH option you mentioned, request to be
last generated too; b, some options may added at the end of a DHCP
message after signature options has been generated. We don't have a
clear example for this. But we cannot rule out the possibility. The
second design is too complicated giving the fact we cannot limit the
number of options. Then, the third design becomes the most reasonable
one for us.

> already requires that it cover the entire client message.)

En... This is interesting. The AUTH option has already taken the
last-generated position. And I assume by the time of design this, the
designers already rule out the possibility that some option may request
to be generated/added after AUTH option. Now, we have one, at least, it
is equally to be last generated comparing the AUTH option.

> in the message, it would require the AUTH to follow the SIGNATURE).

En... this could be a possible answer, I guess. Both AUTH and SIGNATURE
are only protects what in front of them. So, there would have no fixed
order for both their positions and generation order. AUTH can be behind
SIGNATURE, vice verse. This may also release the restriction "Any DHCP
message MUST NOT include more than one Authentication option." [21.2,
RFC 3315]

> Perhaps the ability for a relay to be a node should be removed? It
keeps

I agree that we should put more text to explain the process for relaying
if we get sure relaying need to be protected. In the above scenario, I
don't think reply agent needs to validate the SIGNATURE option unless it
uses some information from its received DHCP message. The server, in
this case, needs to validate all 3 SIGNATURE options. However, if relay
agent does not add its only options, the signature option from it may
not be very useful and the SIGNATURE options from relay agent are
optional.

Best regards,

Sheng

---

From: JiangSheng 66104 <[email-masked]>
Date: Tue, 20 Jan 2009 18:40:06 +0800

See my reply in lines. Cheers,

Sheng

> covers the entire message), it does not have to be the LAST option in

I understand this. Now, the problem is, for the same reason – to protect all DHCP message, including AUTH option, the Signature option wants to be generated after AUTH option.

> Relay Message option in its own message, but that does NOT alter the

This is fine. I knew it. Again, the point is two options both want to be generated after another one.

> This way, the AUTH gives complete protection of the entire message as it

Yes, this can work. But one assumption you take here is AUTH provide more protection. I am not convinced yet. For me, AUTH and Signature have different purposes and it is not suitable to say one is safer than another one. They should be equal. Only one reason I can think out: AUTH has been clearly defined to be last-generated and we don’t want change the existing. If so, I am fine with above design.

> the client is a relay agent address and thus the Signature would never

Are you suggestion to disable signature option to be used in relay message? This is fine, if the relay agent does not add its own options. However, if the relay agent does add some options, these options need to be protected too. In this case, the client has two signature options to be validated: first one from the relay agent, the second one is from the server within the encapsulated server message. However, I noticed that even the first one failed, the second one might success. This is something I am not very sure yet. For me, it seems mean options from relay agent are unsecure, but the options from server are secure.

> client-to-server and server-to-client authentication since the "CGA" is

This is not about public key provision or distribution. It is after key has been configured. Servers and clients can validate the identity of message sender and the integrity of the message.

> this would now work (whereas it does not using the original design).

Yes, this is one of the major scenarios. Also the client-to-server authentication is also important, to verify the client has the right to access and receive the service from the network/DHCP server.

Regards, Sheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 20 Jan 2009 14:37:10 -0500

- Bernie

-----Original Message-----
From: JiangSheng 66104 [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2009 5:40 AM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RE: RE: [dhcwg] "Secure DHCPv6 Using CGAs"

Sheng

> covers the entire message), it does not have to be the LAST option in

I understand this. Now, the problem is, for the same reason - to protect
all DHCP message, including AUTH option, the Signature option wants to
be generated after AUTH option.

BV> One of the has to go last. I think the AUTH should - period.

> Relay Message option in its own message, but that does NOT alter the

This is fine. I knew it. Again, the point is two options both want to be
generated after another one.

> This way, the AUTH gives complete protection of the entire message as
it

Yes, this can work. But one assumption you take here is AUTH provide
more protection. I am not convinced yet. For me, AUTH and Signature have
different purposes and it is not suitable to say one is safer than
another one. They should be equal. Only one reason I can think out: AUTH
has been clearly defined to be last-generated and we don't want change
the existing. If so, I am fine with above design.

> the client is a relay agent address and thus the Signature would never

Are you suggestion to disable signature option to be used in relay
message? This is fine, if the relay agent does not add its own options.
However, if the relay agent does add some options, these options need to
be protected too. In this case, the client has two signature options to
be validated: first one from the relay agent, the second one is from the
server within the encapsulated server message. However, I noticed that
even the first one failed, the second one might success. This is
something I am not very sure yet. For me, it seems mean options from
relay agent are unsecure, but the options from server are secure.

BV> No, I am not suggesting double signature. I'm suggesting that CGA
from *SERVER* to *CLIENT* will not work if a relay agent is involved as
you have defined the Signature to include:

                       2. The 128-bit Source Address field from the IP 
                       header. 

BV> And, while the server can generate the signature using its source
address, the client will NOT receive the server's source address (if
relayed) and hence can never validate the signature option. So, this is
seriously flawed.

BV> Review the DHCPv6 protocol document (RFC 3315), especially section
20. Relay Agent Behavior. Even if this were DHCPv4, this would not work
when relay agents are involved.

> client-to-server and server-to-client authentication since the "CGA"
is

This is not about public key provision or distribution. It is after key
has been configured. Servers and clients can validate the identity of
message sender and the integrity of the message.

BV> Exactly ... The problem with the RFC 3315 AUTH Option is the key
distribution problem. With CGA, you assume that they keys are already
distributed. So, bingo -- use these keys with the AUTH option (forget
about validating the CGA -- validate the client/server interaction,
either in one direction or both). If keys are already available to do
CGA, let's use them for DHCPv6 AUTH and we avoid yet another key
distribution requirement and can bootstrap DHCPv6 AUTH to get it more
widely deployed. This also matches one of the key requirements in
networks where clients need correct ROUTING and ADDRESSING information.
SEND can distribute routing information and then DHCPv6 (with the keys
used for CGA used by the server/client) to validate DHCPv6 messages
(from server to client or client to server or both).

> this would now work (whereas it does not using the original design).

Yes, this is one of the major scenarios. Also the client-to-server
authentication is also important, to verify the client has the right to
access and receive the service from the network/DHCP server.

Regards, Sheng

> > Why is this protection positional? Can you explain why you think
this
> is
> > The draft allows a node to be a DHCPv6 relay agent. I think more
text
> is

---

From: Sean Shen <[email-masked]>
Date: Wed, 21 Jan 2009 17:52:13 +0800

Thank you for the detailed review. I was not able to access email regularly
recently and the situation will remain for another week or 10 days, but I
will try to reply as fast as I can. Please see comments in lines:  

>Note that while the AUTH option needs to be generated last 
>(since it covers the entire message), it does not have to be 
>the LAST option in the message.
>
>In DHCPv6, no entity (relay agent or server) adds options to 
>the messages while it is 'in-flight' as is done for the DHCPv4 
>relay agent option. Once the message is formed, a relay may 
>encapsulate it in a Relay Message option in its own message, 
>but that does NOT alter the original message.
>
>I think:
>- CGA Signature covers the ENTIRE message EXCEPT for some of 
>its own fields and the AUTH option.
>- The AUTH option covers the ENTIRE message, including the CGA 
>Signature option.
>
>This way, the AUTH gives complete protection of the entire 
>message as it was intended to.
It works. 

>I'm not sure if it will be common for the SIGNATURE and AUTH 
>to be used together, as it seems to me that using the AUTH 
>message gives the better protection to begin with. But, if 
>they are used together, it works.
Sure they can be used together. The good part of SIGNATURE is that it can be
used in relay senarios, thus we don't need to rely on IPSEC for protection.
(for the issue you found in relay scenario, please see the following
comments)

>I'd also highly recommend the CGA stuff be limited to clients 
>and servers (a client can add/server validate). Note that a 
>server can NOT use this for to provide proof of a CGA (the 
>server's source address) because this ONLY works when the 
>client and server are on the same link.
>If a relay agent is involved, the source address of the packet 
>sent to the client is a relay agent address and thus the 
>Signature would never validate.
Thanks for the issue you found, it's very important. 
The souce address lost problem happened only for SERVER-->Relay-->Client.
For Client-->Relay-->Server, the souce address is kept in "link-address"
field of relay messages. Comparing AUTH and SIGNATURE, we have the
situation:

			No Relay		C-->R-->S	S-->R-->C

AUTH			yes			no		no

SIGNATURE		yes			yes 		yes with
proper solution*

Possbile solutions*: 
Server's DHCP message (in relay senario) carry source address of server. For
example, this can be done by defining new option to carry server's source
address; or simply use the Server Identifier Option, define a new "link
address plus time" type for DUID content. 
SIGNATURE is good for Relay scenarios where AUTH does not work. Entities
along the route can sign messages as long as have the ability and are
configured to do so. Receiver's can tell which signature belongs to whom.
There are no pair-wise configurations of symmetric keys.
For the questions whether all relay nodes should sign the message or whether
the server/client should verify all the signatures, personally I think we
can leave the decision for implementations or policys. Of course it's worth
discussion whether we should enforce it in protocol.     

BW,

Sean

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 21 Jan 2009 08:22:50 -0500

to server communication, we could always just allow use of the AUTH
option. There's little need for CGA.

However, I don't believe there's a need to find an alternative to IPSec.

I think you need to step back and figure out exactly what problem you're
trying to solve by adding this capability. Just beause we could do
something, doesn't mean we should.

Personally, I still find that using the keys used by SEND (CGA) with the
AUTH option to authentication servers (and possibly clients to servers)
is the most interesting beause if you've already distributed those keys,
it avoids having to distribute yet another set of keys. And, the folks
that manage the routers often manage the DHCPv6 servers as well.

- Bernie 

-----Original Message-----
From: Sean Shen [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2009 4:52 AM
To: Bernie Volz (volz); 'JiangSheng 66104'
Cc: [email-masked]; [email-masked]
Subject: RE: [CGA-EXT] [dhcwg] "Secure DHCPv6 Using

Hi, Bernie,
Thank you for the detailed review. I was not able to access email
regularly
recently and the situation will remain for another week or 10 days, but
I

It works. 

>they are used together, it works.
Sure they can be used together. The good part of SIGNATURE is that it
can be
used in relay senarios, thus we don't need to rely on IPSEC for
protection.
(for the issue you found in relay scenario, please see the following
comments)

Thanks for the issue you found, it's very important. 
The souce address lost problem happened only for
SERVER-->Relay-->Client.
For Client-->Relay-->Server, the souce address is kept in "link-address"
field of relay messages. Comparing AUTH and SIGNATURE, we have the
situation:

			No Relay		C-->R-->S
S-->R-->C

AUTH			yes			no		no

Possbile solutions*: 
Server's DHCP message (in relay senario) carry source address of server.
For
example, this can be done by defining new option to carry server's
source
address; or simply use the Server Identifier Option, define a new "link
address plus time" type for DUID content. 
SIGNATURE is good for Relay scenarios where AUTH does not work. Entities
along the route can sign messages as long as have the ability and are
configured to do so. Receiver's can tell which signature belongs to
whom.
There are no pair-wise configurations of symmetric keys.
For the questions whether all relay nodes should sign the message or
whether
the server/client should verify all the signatures, personally I think
we
can leave the decision for implementations or policys. Of course it's
worth
discussion whether we should enforce it in protocol.     

BW,

Sean

---

From: Sean Shen <[email-masked]>
Date: Thu, 22 Jan 2009 10:04:04 +0800

Please see in lines.  

>If we want to replace IPSec with something else for relay to 
>relay/relay to server communication, we could always just 
>allow use of the AUTH option. There's little need for CGA.
It can be a try if you want to use AUTH for relay-->relay/relay-->server,
but I doubt it can fit the scenario well. AUTH is basicly symmetric crypto,
good for two parties. It's rare to use it for 3 or more parties because you
don't want to manage keys for each pair of parties. Also if you want your
AUTH be checked by all the nodes on the route, you have to calculate and
carry multiple AUTHs for all of them, while RFC3315 clearly defined that
only one AUTH can be used, not mentioing that a client may not even know
which router will check the AUTH (hence don't know which key to use). 
Since I am not an author of RFC3315, I don' t know other reasons (besides
what I just said above) that AUTH is not simply used in relay scenarios. If
you think it's doable, more discussion of its feasibility will be
interesting.   

>However, I don't believe there's a need to find an alternative 
The reason is simple: NOT all routers can and like to use IPsec.

>I think you need to step back and figure out exactly what 
>problem you're trying to solve by adding this capability. Just 
>beause we could do something, doesn't mean we should.
The motivation and benefit (including advantages in relay scenarios and IP
binding) is described in section 3 of the draft. 

>Personally, I still find that using the keys used by SEND 
>(CGA) with the AUTH option to authentication servers (and 
>possibly clients to servers) is the most interesting beause if 
>you've already distributed those keys, it avoids having to 
>distribute yet another set of keys. And, the folks that manage 
>the routers often manage the DHCPv6 servers as well.
Generally using same key for multiple purposes should be avoided in crypto
(unless good hash processing involved), just like you don't want to use a
same key for both encryption and authentication. Again we said before, the
reason is not only about key management.

Best,

Sean

---

From: Damien Neil <[email-masked]>
Date: Thu, 22 Jan 2009 00:26:35 -0800

> binding) is described in section 3 of the draft.

It's possible that this is just my lack of experience with CGAs  
speaking, but section 3 hasn't enlightened me on the benefit of this  
proposal.

My understanding is that CGA authentication will permit a client to  
verify that a DHCP message received from a server with a given address  
was, in fact, sent by the server with that address.  Is there a  
mechanism, however, which permits the client to verify that this  
server is authorized to act as a DHCP server?  If not, what security  
is added by signing the message?

What prevents a malicious DHCP server from generating a new CGA, using  
it to sign its messages, and serving addresses to clients?

It might help me understand the benefits of this proposal if you could  
describe a specific attack which it can defend against.

                - Damien