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

From: Sheng Jiang <[email-masked]>
Date: Fri, 04 Jul 2008 16:58:33 +0800

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2008 09:36:04 -0400

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.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 7 Jul 2008 23:06:11 +0200

Sheng Jiang,

> Filename:    draft-jiang-dhc-secure-dhcpv6

I haven't done a detailed review, but I think this is an interesting  
idea worthy of being pursued.

But maybe in the draft you can explain a bit more about the specific  
attacks this is designed to prevent?

As I understand it, this technique will prevent an attacker:

- from sending an invalid binding in a Request

- from Declining a message on behalf of a client

- from Releasing a lease of a client (or renewing, but I don't see  
that as a major problem)

- from causing a client to Reconfigure

It will not prevent an attacker from sending an Advertise and acting  
as a DHCPv6 server. (Maybe something like the RA spoofing prevention  
draft could be used for this, but that is probably the subject of a  
separate draft.)

--
Shane

---

From: Mark Stapp <[email-masked]>
Date: Wed, 09 Jul 2008 09:43:11 -0400

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

---

From: Sean Shuo Shen <[email-masked]>
Date: Thu, 10 Jul 2008 18:19:05 +0800

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

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

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

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

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

>the meaning of a specific passage, but I don't think that's what's 

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.

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

>address configuration, or prefix delegation?

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

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

>authorize relays and servers via certs? or validate clients' keys with 

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

> Filename:    draft-jiang-dhc-secure-dhcpv6
http://www3.ietf.org/proceedings/staging/draft-jiang-dhc-secure-dhcpv6-00.tx
t

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 13 Jul 2008 10:08:09 -0400

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

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Sean Shuo Shen
Sent: Thursday, July 10, 2008 6:19 AM
To: Mark Stapp (mjs); 'Sheng Jiang'
Cc: [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi Mark,

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

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

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

>Bernie's point that there's no need to require special ordering.

The order design is to simplify the verification processing at the
receiver

>the meaning of a specific passage, but I don't think that's what's 

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.

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

>authorize relays and servers via certs? or validate clients' keys with 

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

0.tx
t

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 10:27:33 +0700

Date:        Sun, 13 Jul 2008 10:08:09 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

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

Well, not quite, as the signature is part of the message, but since it
doesn't exist yet when it is being calculated, cannot be part of itself.
Nor does it need to be of course.

And you're quite right that there's no technical reason for requiring the
signature to be last, everything can be made to work without that
requirement.

However, there is a good practical reason.   That is, we know how this
will be implemented, the signature can't be added until all the other
options for the message are in place (at least, known), and the natural
way to do things is to put each option into the packet as it is needed.
That is, when generating the packet the last option added is always going
to be the signature, and it is hard to imagine an implementation where
that won't mean the signature will be the last option in the packet
(and yes, I mean the original packet, ignoring anything that later 
encapsulates it.)

That's all fine, and of itself doesn't require any rule as to placement
of the sig option, it can be permitted anywhere, and just only ever
happen to appear last.

But consider the receiver (the client).   It has to be able to deal with
any legal packet.   That's fine, it is possible to write code that will
allow the signature to be in the middle somewhere (or at the beginning),
but when will that code ever get tested?   It is natural to optimise for
the common case - that will be where the sig option is last, and there's
a single contig sequence of bytes to feed to the hash function.   The other
case, where two separate blocks need to be included (or less likely,
the packet order needs to be shuffled) will need to be written, but in
practice never be executed.   That's a bug trap, just sitting waiting
(even if tested when originally coded, which I assume it would be, that's
the kind of thing that bit rots over time as other modifications are made
to the rest of the code.)

The end result of this kind of thing is a "well known implementors rule"
that the sig option must be last, or various clients fail in obscure ways,
without that rule being ever written anywhere, leaving it as a surprise for
new implementors.   In situations like this, it is often wiser to simply
accept that life is is as it is, and make "last" be mandatory, so clients
can simply discard any packet where the sig isn't last as being malformed,
and there's no code to deal with this to rot.

The only real argument I can see against this (aside from the general
esthetic of not wanting to make a rule that isn't really needed) is if
it was wanted to allow multiple auth type options simultaneously.   Obviously
they could not all be required to be last.   I have no idea if that's
something that is relevant here, nor how it would be specified if it
were.   In particular, normally an auth option authenticates everything
but itself (well, it self authenticates itself too) - but that could not
happen here, as it is impossible for all the auth options to each include
all of the others.  There are two ways out of this - either you have auth
options cover everything in the packet earlier than them, and then you've
lost your packet order freedom again, or you have auth options cover
everything in the packet except auth options (assuming each of them can
look after itself, and is strong enough that only one of them really need
be verified.)   In the latter case, option order freedom still exists,
but for the same reasons as above, it would make sense to require all
auth options after all other options, as that's what's going to happen anyway.

Also note, sig (auth) options are not (and never can be) treated like any
general option, they always need to be treated specially, the way they're
implemented is just different than general options - they always need to be
calculated last at the sender, and should generally be checked first (after
only basic packet format) at the receiver to avoid processing options from a
forged packet.   That is, there's no need to worry about needing special
case code in servers/clients for this, because of the order requirement, as
special case code for auth options is going to be needed anyway.  Lastly,
a client that treats the auth option as just another unknown option, and
ignores it, doesn't care if that option is first, last, or anywhere, it
won't object to packets with the auth option in the middle, but that's OK,
it has no integrity protection anyway.   A server that doesn't understand
the auth option can never generate one (this isn't an option that can be
added by specifying "add this byte sequence" as a general fallback method
in some config file) so there is no way an unknowing server can start
accidentally generating (sane) auth options without understanding the rules.
What's more, if someone (administrator/hacker) were to use a fallback
method to add bogus auth options, leading an unknowing server to add
the option somewhere in the middle of the packet, it doesn't really matter
if the client rejects the packet because the option isn't last, where it
should be, or because of a sig mismatch (if anything, you'd prefer the
former, it is a much cheaper test.)

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 13 Jul 2008 23:37:13 -0400

The current AUTH option does not have to be last and the message can be
constructed (and validated) just fine - yes, the hashed data is added
into at the end of message construction but that is not an issue as the
hash is always a fixed size.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 13, 2008 11:28 PM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

    Date:        Sun, 13 Jul 2008 10:08:09 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:
<[email-masked]>

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

And you're quite right that there's no technical reason for requiring
the
signature to be last, everything can be made to work without that
requirement.

That is, when generating the packet the last option added is always
going

But consider the receiver (the client).   It has to be able to deal with
any legal packet.   That's fine, it is possible to write code that will
allow the signature to be in the middle somewhere (or at the beginning),
but when will that code ever get tested?   It is natural to optimise for
the common case - that will be where the sig option is last, and there's
a single contig sequence of bytes to feed to the hash function.   The
other
case, where two separate blocks need to be included (or less likely,
the packet order needs to be shuffled) will need to be written, but in
practice never be executed.   That's a bug trap, just sitting waiting
(even if tested when originally coded, which I assume it would be,
that's
the kind of thing that bit rots over time as other modifications are
made
to the rest of the code.)

The end result of this kind of thing is a "well known implementors rule"
that the sig option must be last, or various clients fail in obscure
ways,
without that rule being ever written anywhere, leaving it as a surprise
for
new implementors.   In situations like this, it is often wiser to simply
accept that life is is as it is, and make "last" be mandatory, so
clients
can simply discard any packet where the sig isn't last as being
malformed,
and there's no code to deal with this to rot.

The only real argument I can see against this (aside from the general
esthetic of not wanting to make a rule that isn't really needed) is if
it was wanted to allow multiple auth type options simultaneously.
Obviously
they could not all be required to be last.   I have no idea if that's
something that is relevant here, nor how it would be specified if it
were.   In particular, normally an auth option authenticates everything
but itself (well, it self authenticates itself too) - but that could not
happen here, as it is impossible for all the auth options to each
include
all of the others.  There are two ways out of this - either you have
auth
options cover everything in the packet earlier than them, and then
you've
lost your packet order freedom again, or you have auth options cover
everything in the packet except auth options (assuming each of them can
look after itself, and is strong enough that only one of them really
need
be verified.)   In the latter case, option order freedom still exists,
but for the same reasons as above, it would make sense to require all
auth options after all other options, as that's what's going to happen
anyway.

Also note, sig (auth) options are not (and never can be) treated like
any
general option, they always need to be treated specially, the way
they're
implemented is just different than general options - they always need to
be
calculated last at the sender, and should generally be checked first
(after
only basic packet format) at the receiver to avoid processing options
from a
forged packet.   That is, there's no need to worry about needing special
case code in servers/clients for this, because of the order requirement,
as
special case code for auth options is going to be needed anyway.
Lastly,
a client that treats the auth option as just another unknown option, and
ignores it, doesn't care if that option is first, last, or anywhere, it
won't object to packets with the auth option in the middle, but that's
OK,
it has no integrity protection anyway.   A server that doesn't
understand
the auth option can never generate one (this isn't an option that can be
added by specifying "add this byte sequence" as a general fallback
method
in some config file) so there is no way an unknowing server can start
accidentally generating (sane) auth options without understanding the
rules.
What's more, if someone (administrator/hacker) were to use a fallback
method to add bogus auth options, leading an unknowing server to add
the option somewhere in the middle of the packet, it doesn't really
matter
if the client rejects the packet because the option isn't last, where it
should be, or because of a sig mismatch (if anything, you'd prefer the
former, it is a much cheaper test.)

kre

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Jul 2008 00:09:45 -0700

> (and yes, I mean the original packet, ignoring anything that later

This simply isn't true.   The way I have always envisioned writing this code (which, I admit, I have never written) is to represent the option internally as zeroes, and then call the routine that constructs the packet.   Then compute the actual checksum.   Then stuff it in where the option was stored in the packet, wherever that was.   So for me, requiring the option to be at the end would require additional code.

> the common case

Actually, it wouldn't be natural to optimize this case, because there's no way to optimize it.   You can't traverse the options backwards.   So it's no easier to find the option at the end of the packet than in the middle.   The obvious optimization for both the server and client is to put the option at the beginning.

> and there's no code to deal with this to rot.

This is exactly backwards.   We want broken clients to fail early and often.   Otherwise they never get fixed.   The best place for the server to put the option is in the middle of the packet, where neither the assumption that it's at the beginning, nor the assumption that it's at the end, will work.

> special case code for auth options is going to be needed anyway.

This is also untrue.   You want to use the regular packet construction code to place the option in the packet; otherwise you are putting in a special code path that will never get tested, because nobody actually uses DHCP authentication.   So you want as little of the DHCP authentication code as possible to be special-cased.   In every DHCP project I've ever worked on, there are primitives for "get option X" and "add this option to the list of options to put in the packet."   There are no primitives for "get the last option" or "put this at the end."

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 17:24:36 +0700

Date:        Mon, 14 Jul 2008 00:09:45 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | This simply isn't true.   The way I have always envisioned writing
  | this code (which, I admit, I have never written) is to represent the
  | option internally as zeroes, and then call the routine that constructs
  | the packet.   Then compute the actual checksum.

That might be possible for the existing AUTH option, it is not for the
CGA signature (that is, that isn't how public key signatures are constructed).

But in any case, since you need special case code for the option, why
would you be just shoving it at any random place, rather than last
which is when the calculations are needed anyway.

  | Actually, it wouldn't be natural to optimize this case, because there's
  | no way to optimize it.   You can't traverse the options backwards.

That's not the kind of optimisation I was thinking of.  for a signature
for a CGA, all of the other data in the packet needs to be fed into the
hash function.   The API for the hash function is generally
	hash_init()
	bufp = packet;
	while (not end) {
		if (seg_wanted)
			hash_include_data(bufp, seg_len);
		bufp += seg_len;
	}
	hash_result()

The optimisation is

	hash_init()
	hash_include_data(packet, packet_len-sig_len)
	hash_result()

that is, there is only one call to the "calculate the hash of the
data" function, and it hashes everything from the start of the packet
to the beginning of the sig option.   Doing it this way makes the code
easier to write, and more likely to be correct.

  | The obvious optimization for both the server and client is to put
  | the option at the beginning.

Since there's a fixed header on the packet that you can't put the
option before (I believe), that still means having split data.

I have no idea why this would be an optimisation for the server, anywhere
but last (assuming your method worked) would mean two operations, first
allocating and clearing the option space, and second calculating and
filling in the hash result (or signature in the CGA case).   Adding
it last means all this gets done together.

For the client, sure, having the auth data first means it could be
verified before looking at the rest of the packet, but I think that's
the kind of optimisation that looks good at first glance, but turns out
to be a poor choice.   Before doing the (even hash function not all
that expensive) calculations, the client should at least ensure the
packet looks to be correctly formatted - that is, the options and their
lengths nicely take the parser to the end of the packet, nothing required
is missing, no other base rules violated, ... all those are cheap checks,
even cheaper than a hash calculation, and definitely cheaper than a
public key validation.

  | This is exactly backwards.   We want broken clients to fail early
  | and often.   Otherwise they never get fixed.

Yes, that's what I'd want too.   My point is that I don't really see the
auth option occurring anywhere but last, and certainly not a CGA
signature, regardless of where it is permitted to be.   What's more,
I think if you did actyally write the code, and weren't deliberately
concentrating on this little discussion, you'd put it at the end too.
It is just easier that way (I have written code like this).

  | The best place for the server to put the option is in the middle
  | of the packet, where neither the assumption that it's at the beginning,
  | nor the assumption that it's at the end, will work.

Sure, if the point of the server is to stress clients (and the rules allow
that).   Somehow, I doubt most server authors really write their code so
as to cause problems for clients.   We all know (in all areas, not just DHCP)
that the average user's opinion is that "it works with that server, it
doesn't work with your server, your server must be broken", and no matter
how much you point out that your server is just implementing things
differently, unless you can show that the other server is broken (and it
isn't here), you can't win that argument.

This is even more true with things like dhcp clients, of which organisations
have orders of magnitude greater numbers than dhcp servers, and for which
changing the client is often essentially impossible, but changing the
server is just a few hours work.

  | This is also untrue.   You want to use the regular packet construction
  | code to place the option in the packet;

Of course, the question is not the code that adds the option, but the
order in which it is added.   It has to be done in some order or other.
Last is just easier.

  |  There are no primitives for "get the last option" or "put this at the end."

You don't need the former, and the latter is the same as "add this option",
that is, they're all "added at the end", it is just that after adding each,
the end moves.   The only thing in question is the sequence of option
adding.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 17:32:50 +0700

Date:        Sun, 13 Jul 2008 23:37:13 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The current AUTH option does not have to be last

Yes, I understand that.   Can you however point at existing implementations
where it is not added last?   If not (unless there simply no implementations
at all) that kind of proves my point.   If there are some, I'd really like 
their authors to explain why they implemented it that way.

  | and the message can be constructed (and validated) just fine

Yes, absolutely - as I said, there's no technical reason at all for
requiring the option to be last.   Just pragmatics.

  | - yes, the hashed data is added
  | into at the end of message construction but that is not an issue as the
  | hash is always a fixed size.

That's not true for a public key signature, or not in the way I think
you mean anyway.   The size of the signature depends upon the key used,
and not at all upon the data being signed (ie: you generate a 128 bit
hash of the message, the signature is still 1024 bits, plus overheads,
for a 1024 bit RSA key - at least for RSA public keys, I'm less sure
about the other algorithms, but I suspect similar there, and in any case,
for CGA's, which were under discussion here, RSA is the only option right
now).

That is, it may be true that the signer can work out how big the signature
will be, in advance of calculating it, but it's sure easier to just generate
it, and then see how big it is.   There's certainly no constant size that you
can assume the signature will be before you look at the particular key pair.

kre

---

From: Sean Shuo Shen <[email-masked]>
Date: Mon, 14 Jul 2008 18:49:02 +0800

Hi, Bernie

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Sunday, July 13, 2008 10:08 PM
> To: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang
> Cc: [email-masked]
> Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted.
> Comments are welcome!
I think your question is: can the CGA signature be put into the current
DHCPv6 auth framwork as the 3rd auth protocol besides the current two.  
This is a good question and actually we tried to fit the signature option
into current AUTH framework at the beginning. The AUTH framework is open for
more auth protocols and is a good place to carry more auth mechanisms. But
there is a issues should be noticed:  DHCPv6 AUTH only allow one auth
option, thus only client and server can authenticate each other via auth
option. The relay agents have to be authenticated via IPSEC.  Our proposal
trys to avoid this IPSEC requirement and makes sure that all the relay
agents in the middle can be authenticated and be trusted by the receiver.
> particular level is immaterial and should NEVER need to be in any
We have been clarified before that once a message A with signature was sent
by the client, no more options is added to this message A. The relay agents
will generate relay message B which encapsulate A in B's relay message
option, more options MAY add other options after the relay message option
and these more options are option of B (not of A).  It is comply and
consistent with RFC3315. See RFC3315, Section 7 :
      options        MUST include a "Relay Message option" (see
                     section 22.10); MAY include other options added by
                     the relay agent.
Regard,
Sean

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 08:52:44 -0400

>Can you however point at existing implementations
>where it is not added last? 

Yes, the Cisco Network Registrar DHCPv6 server does not necessarily add
the AUTH option last -- it will add the AUTH option and then any options
requested by the client. The server adds the option and then, just
before sending the packet, does a callback to a function that is
responsible for calculating the hash and storing it into the buffer to
be transmitted.

>requiring the option to be last.   Just pragmatics.

OK, great. I have no issues if an implementation actually adds it last,
but I do have an issue with a I-D/RFC that would require it to be last.

>you mean anyway.   The size of the signature depends upon the key used,

Sure, you have to know the key to figure out the signature size.

Again, an implementation should be free to implement this any way it
wants. If the implementation wants to add the option last, that is its
choice. But not something that should be required.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 6:33 AM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

    Date:        Sun, 13 Jul 2008 23:37:13 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:
<[email-masked]>

Yes, I understand that.   Can you however point at existing
implementations
where it is not added last?   If not (unless there simply no
implementations
at all) that kind of proves my point.   If there are some, I'd really
like 
their authors to explain why they implemented it that way.

  | - yes, the hashed data is added
  | into at the end of message construction but that is not an issue as
the
  | hash is always a fixed size.

That's not true for a public key signature, or not in the way I think
you mean anyway.   The size of the signature depends upon the key used,
and not at all upon the data being signed (ie: you generate a 128 bit
hash of the message, the signature is still 1024 bits, plus overheads,
for a 1024 bit RSA key - at least for RSA public keys, I'm less sure
about the other algorithms, but I suspect similar there, and in any
case,
for CGA's, which were under discussion here, RSA is the only option
right
now).

That is, it may be true that the signer can work out how big the
signature
will be, in advance of calculating it, but it's sure easier to just
generate
it, and then see how big it is.   There's certainly no constant size
that you
can assume the signature will be before you look at the particular key
pair.

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 08:56:09 -0400

And, what if there is another option that states it needs to be last?

If there is no technical reason, then drop the requirement. If it makes
it easier to implement, that is up to the implementation to decide to
do; not up to the standard to mandate it.

- Bernie 

-----Original Message-----
From: Sean Shuo Shen [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 8:51 AM
To: [email-masked]; Bernie Volz (volz)
Cc: Mark Stapp (mjs); 'Sheng Jiang'; [email-masked]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

About the "last option" argument, as Kre said, there is no technical
reason
that such a requirement absolutely has to be satisfied, but such a
requirement can make implementations uniformly easier. 

Regard,

Sean

> Sent: Monday, July 14, 2008 6:33 PM
> To: Bernie Volz (volz)
submitted.
implementations
implementations
like
the
case,
right
signature
generate
> it, and then see how big it is.   There's certainly no constant size
that
you
pair.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 09:10:15 -0400

If you want to extend the AUTH option to handle relay-agent to
relay-agent or relay-agent-to-server authentication, I don't think that
means you'd have to use a new option.

---

>                     section 22.10); MAY include other options added by

You'll note that this text in RFC 3315 states nothing about ordering.

- Bernie

-----Original Message-----
From: Sean Shuo Shen [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 6:49 AM
To: Bernie Volz (volz); Mark Stapp (mjs); 'Sheng Jiang'
Cc: [email-masked]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

Hi, Bernie

submitted.
I think your question is: can the CGA signature be put into the current
DHCPv6 auth framwork as the 3rd auth protocol besides the current two.  
This is a good question and actually we tried to fit the signature
option
into current AUTH framework at the beginning. The AUTH framework is open
for
more auth protocols and is a good place to carry more auth mechanisms.
But
there is a issues should be noticed:  DHCPv6 AUTH only allow one auth
option, thus only client and server can authenticate each other via auth
option. The relay agents have to be authenticated via IPSEC.  Our
proposal
trys to avoid this IPSEC requirement and makes sure that all the relay
agents in the middle can be authenticated and be trusted by the
receiver.
> particular level is immaterial and should NEVER need to be in any
We have been clarified before that once a message A with signature was
sent
by the client, no more options is added to this message A. The relay
agents
will generate relay message B which encapsulate A in B's relay message
option, more options MAY add other options after the relay message
option
and these more options are option of B (not of A).  It is comply and
consistent with RFC3315. See RFC3315, Section 7 :
      options        MUST include a "Relay Message option" (see
                     section 22.10); MAY include other options added by
                     the relay agent.
Regard,
Sean

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 20:29:03 +0700

Date:        Mon, 14 Jul 2008 08:56:09 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | And, what if there is another option that states it needs to be last?

Yes, that's a problem, there can be only one (non-exclusive0 option with
that requirement.   But "last" tends to only make sense for auth type
options, options whose value depends upon all the other data in the packet.

That's why my earlier message mentioned the possibility of multiple auth
options (which to me probably makes no sense, but ...)

  | If there is no technical reason, then drop the requirement. If it makes
  | it easier to implement, that is up to the implementation to decide to
  | do; not up to the standard to mandate it.

Again, I think it is to allow clients to simplify their code, which I
suspect many will do anyway, and that it can be done without any real
impact upon the server.

Also note I'm talking about the proposed CGA signature option, not the
existing AUTH option.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 20:38:40 +0700

Date:        Mon, 14 Jul 2008 08:52:44 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | it will add the AUTH option and then any options
  | requested by the client. The server adds the option and then, just
  | before sending the packet, does a callback to a function that is
  | responsible for calculating the hash and storing it into the buffer to
  | be transmitted.

[...]

  | Sure, you have to know the key to figure out the signature size.

So you're saying that this implementation, if it was to add support
for CGA authentication (assuming that's decided to be worthwhile)
then it would get the key, figure out the length of the signature,
allocate space, then go do other stuff, then come back later, get the
key again, calculate the signature, and store it.

Why?

That's nothing like the way I'd write it.

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 09:41:45 -0400

>suspect many will do anyway, and that it can be done without any real

How does this simplify the client implementation?

The steps are the same:
- Determine the key being used for the transaction.
- Locate the AUTH or CGA option.
- Generate the hash over the message (perhaps setting the fields in the
AUTH/CGA option to some other value before generating the hash; storing
the overwritten bytes elsewhere) and concatentating anything needed for
generating the hash to the message (if appropriate).
- Validate the hash.

So, what's the benefit of putting the AUTH or CGA or whatever option
last? (Even if the option was last, the steps to locate it are still the
same.)

--

I think at this point we've (I've) wasted enough bandwidth on this
issue.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 9:29 AM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

    Date:        Mon, 14 Jul 2008 08:56:09 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:
<[email-masked]>

  | And, what if there is another option that states it needs to be
last?

Yes, that's a problem, there can be only one (non-exclusive0 option with
that requirement.   But "last" tends to only make sense for auth type
options, options whose value depends upon all the other data in the
packet.

  | If there is no technical reason, then drop the requirement. If it
makes
  | it easier to implement, that is up to the implementation to decide
to
  | do; not up to the standard to mandate it.

kre

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jul 2008 09:45:59 -0400

At least as compelling a justification for a different option being  
last is that relay-agent information options, added after the client  
has sent the datagram.

John

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 09:46:31 -0400

>That's nothing like the way I'd write it. 

Because of features in the Cisco Network Registrar server that let
customers do things to packets. We have to form the "almost" complete
packet and only at the very last step (just before transmitting the
packet) fill in the actual hash in the AUTH option to it is valid. This
same processing would apply to the CGA (whether it has its own option or
uses the AUTH option).

Sure, if you're writing a simple server you might not need to do it this
way. And, that's my point - if YOUR implementation wants to add it last,
you are free to do that. If another implementation wants to add it
first, or in the middle, that's fine too.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 9:39 AM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

    Date:        Mon, 14 Jul 2008 08:52:44 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:
<[email-masked]>

  | it will add the AUTH option and then any options
  | requested by the client. The server adds the option and then, just
  | before sending the packet, does a callback to a function that is
  | responsible for calculating the hash and storing it into the buffer
to
  | be transmitted.

[...]

Why?

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 21:10:16 +0700

Date:        Mon, 14 Jul 2008 09:45:59 -0400
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | At least as compelling a justification for a different option being  
  | last is that relay-agent information options, added after the client  
  | has sent the datagram.

But I thought we'd just been through that, as I understand it, they are
not "added" to the packet, rather the existing packet is placed into a
new packet, along with the relay options.   Is that not correct?

If it isn't, then that would be a justification for a slightly different
definition of "last" where the sig option needs to be added "last" and
specifically covers data from packet beginning to just before itself,
and nothing after that - otherwise options added latter would automatically
invalidate the packet.   But I don't think this is how it is done (in v6).

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 10:16:19 -0400

If you reworked section 5.2 of the draft as follows you'd solve the
option ordering issue:

       Signature       A variable-length field containing a digital 
                       signature. The signature value is computed with 
                       the hash algorithm and the signature algorithm, 
                       as described in HA-id and SA-id. The signature 
                       constructed by using the sender's private key 
                       over the following sequence of octets: 
                        
                       1. The 128-bit CGA Message Type tag value for 
                       Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 
                       0665 d2e0 02c2. (The tag value has been 
                       generated randomly by the editor of this 
                       specification.)
                        
                       2. The 128-bit Source Address field from the IP 
                       header. 
                        
                       3. The 128-bit Destination Address field from 
                       the IP header. 
                        
                       4. The entire DHCPv6 message with the Signature
                       field of this option set to all zero's.

If may even be better to have it read:
                        
                       1. The entire DHCPv6 message with the Signature
                       field of this option set to all zero's.

                       2. The 128-bit CGA Message Type tag value for 
                       Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 
                       0665 d2e0 02c2. (The tag value has been 
                       generated randomly by the editor of this 
                       specification.)
                        
                       3. The 128-bit Source Address field from the IP 
                       header. 
                        
                       4. The 128-bit Destination Address field from 
                       the IP header. 

The reason is that it is often easier to (temporarily) add data at the
end of the message than to have allocated sufficient space BEFORE it
(and at least KRE wants to avoid having to use multiple buffer fragments
to hash over).

Also, I'm not sure what benefit the "reserved" field in the option has
(other than making the diagram easier to draw) and I'd suggest removing
it unless you have a good argument for keeping it. I think it is there
in RFC 3971 for the simple reason that there is attempt to align IPv6
header fields so that routers and the like have quicker access to them.
As the DHCPv6 message has no such alignment requirements and the start
of an option can be on any byte boundry, there is no benefit to having
this field to "align" the buffer.

- Bernie

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jul 2008 21:36:28 +0700

Date:        Mon, 14 Jul 2008 09:41:45 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The steps are the same:

Ah, I think I see what people are assuming ...

  | - Generate the hash over the message (perhaps setting the fields in the
  | AUTH/CGA option to some other value before generating the hash;

No, with public key signatures, at least how they're used everywhere else,
that's not how it is done.   The hash is generated over all the data in
the packet as it existed without the sig in it at all - not with "known value"
(dummy) sig option in place.

Remember, that unlike hash output (16 - 20 bytes typically) a signature can be
hundreds of bytes, going around shoving zeroes in all of that space is just
a waste of time,

It is in hash calculations too, including a dummy hash option itself adds
nothing useful, but there it is very often done that way because of historical
inertia.   That is, the hash (or checksum) field was often a fixed field in
the packet header, that could not be omitted.   So, specifying that the
hash/checksum be calculated with the field in place, but set to 0 (or any
other well known value) allowed things to be computed reasonably.

People have tended to copy that definition, even when there's no good reason
at all for it to be that way (which I doubt there is for the DHCP AUTH option)
but the field is generally small and including it makes no huge difference.

None of this has ever been true of public key signatures, they never go
in a fixed field (since they're variable length, they cannot), and they're
not small.

This is true in other uses of CGAs (SEND, MipV6) and other uses of signatures
(SMIME, secure HTTP, ...)

The algorithm for validating a signature is generally

- Determine the key being used for the transaction.
	(with CGA that's found in the CGA parameters that's in another option)
- Locate the AUTH or CGA option.
	(that is, for CGA the signature option, CGAs need, usually, 2 options)
- Remove the SIG option from the packet
	.. If the sig option is last, that means adjusting the packet length
	   field (if the packet has one).
	.. If the sig option isn't last, it means moving the sig option
	   value somewhere else, then moving down all the remaining data
	   the packet to cover it (and adjusting the length if it exist)
	   Or, more commonly, adjusting the way data is fed to the hash func
	   to make it appear that had all been done.
- Generate the hash over the message
	with the sig option missing
- Validate the hash
	ie: decrypt the sig with the public key and compare.

Generating the sig is analogous - first build the packet containing
everything except the sig, calculate the hash over the packet, sign it
with the private key, add the sig option to the end (usually).

I suppose it would be possible to do things the other way and include the
sig field, filled with 0's (or whatever) in the hash calculation, but that
just means more work for everyone, so generally, no-one does that.

  | So, what's the benefit of putting the AUTH or CGA or whatever option
  | last?

Is it clear now?

Generation is also easier, as there's no need to access the key until
it is being used to sign the message, whereas to leave the empty space
we need it first there, and later for the sig calculation.

  | (Even if the option was last, the steps to locate it are still the
  | same.)

Sure, as in my reply to Ted, it isn't locating the thing that is the
issue, it is performing the hash calculation.

  | I think at this point we've (I've) wasted enough bandwidth on this
  | issue.

yes...

To avoid another message, I'll reply to your other (slightly later) one
here as well...

[email-masked] said
   in <[email-masked]>:
  | Because of features in the Cisco Network Registrar server that let customers
  | do things to packets. We have to form the "almost" complete packet and only
  | at the very last step (just before transmitting the packet) fill in the
  | actual hash in the AUTH option to it is valid. This same processing would
  | apply to the CGA (whether it has its own option or uses the AUTH option).

Oh, I see, you want the user to be able to see there's an auth option
there, and perhaps add different options because of that.   Interesting.
And yes, that does make sense, but I'd still be adding it last.

That is, it would be last of the original options, and then whenever
the user added a new option, I'd push it in between the auth option
and whatever preceded it.

For AUTH as it exists now, that might not make much difference, but for
a CGA SIG option, it really makes things much much easier - then the
dummy option could be just an option code and no data (or opt space) - just
enough that it is possible to see that it exists.  Then the real sig
could simply replace it when everything else is known to calculate it.

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 10:59:39 -0400

Yes, I am beginning to see this, though I still don't fully understand
it.

For example, in RFC 3971, section 5.2:

5.2.  RSA Signature Option

...

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Key Hash                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Digital Signature                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                           Padding                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

      This field starts after the Key Hash field.  The length of the
      Digital Signature field is determined by the length of the RSA
      Signature option minus the length of the other fields (including
      the variable length Pad field).

   Padding

      This variable-length field contains padding, as many bytes long as
      remain after the end of the signature. 

This seems like a catch-22. How can someone determine the length of the
Digital Signature field as there's no indication of how long the pad
field is.

Therefore, the Digital Signature field's length MUST be known based on
other information (key, etc).

So, sure, putting 0's in the 100s of bytes and, likely more
significantly, having to calculate the signature over those additional
bytes is a cost.

If we feel that is a burden, using multiple fragments is the way to go.
Based on the original write-up in the draft, this is required anyway so
there's really no savings.

                        

                       4. The entire DHCPv6 message EXCEPT for the
                       option-code, option-len and Signature fields of
                       this option.

It does require one more fragment than the original specification (the
data beyond the end of the option). For the nodes that always add the
option as the last option (based on their choice to do so), they can
avoid this last fragment. But, of course they can't assume this when
receiving a message.

- Bernie

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Jul 2008 00:48:24 +0700

Date:        Mon, 14 Jul 2008 10:59:39 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | This seems like a catch-22. How can someone determine the length of the
  | Digital Signature field as there's no indication of how long the pad
  | field is.

The signature isn't just bits, it is an encoded field, its length is
determined by the first few bytes.   No-one bothers specifying this
because its all defined by the common (non IETF) standard that sets
how these things are represented.

  | Therefore, the Digital Signature field's length MUST be known based on
  | other information (key, etc).

I think it is possible to work out how long it will be (so for eaample,
space can be allocated to store the result of the calculation), but the
key is certainly required to do that.   Since ideally you want the private
key accessible for as little time as possible (so it doesn't end up in crash
dump images, etc) you re

  | So, sure, putting 0's in the 100s of bytes and, likely more
  | significantly, having to calculate the signature over those additional
  | bytes is a cost.

It's just the hash function, which isn't that expensive, what's more
annoying is having to actually do this, especially for validation.
(as it means saving the old value elsewhere before inserting the 0's).

The truly computationally expensive part of all of this is the RSA
encryption, but that's of the result of the hash, which is a short(ish)
fixed length bit string, and none of this is making any difference at
all to that.

  | If we feel that is a burden, using multiple fragments is the way to go.
  | Based on the original write-up in the draft, this is required anyway so
  | there's really no savings.

In your previous message you said (I am interposing this here as it
is relevant to this point ...)

  | The reason is that it is often easier to (temporarily) add data at the end of
  | the message than to have allocated sufficient space BEFORE it (and at least
  | KRE wants to avoid having to use multiple buffer fragments to hash over). 

which isn't it exactly, though it may have seemed like that from
what I said before.   It isn't calling the hash func multiple times
that causes problems - for the usage here, the calls are all fixed
length known position buffers (addresses, and that tag, whose purpose
someone who knows hash function theory much better than I is going to
need to explain to me one day...) so they're easy.   The part that causes
problems (or easily can) is the bit that deals with finding where the
bits of the packet are that need to be included, and making sure the
right bits are there - especially if it turns out that everyone actually
puts the sig last in practice, so the code for dealing with the part of
the packet that comes after the sig is never exercised.

Of course, if everyone copies your method, and sticks the sig in the middle
(or Ted's plan) then this won't be a real issue - I just couldn't imagine
anyone actually writing this code that way.

Back to the main message to which this is a reply for this next quote...

  | It does require one more fragment than the original specification (the
  | data beyond the end of the option). For the nodes that always add the
  | option as the last option (based on their choice to do so), they can
  | avoid this last fragment. But, of course they can't assume this when
  | receiving a message.

The server has no problem, it just always puts the option last (if it
wants, or is required to by the spec) and everything is easy.   But as
you say, the client has to deal with all legitimate possibilities.   That
means (unless the spec prohibits it) that extra fragment at some place in
the packet that must be correctly calculated (start & length) plus dealing
with the possibility that they may rarely, if ever, actually get to exercise
the code that handles this, if, as I believe likely, servers all just put
the option at the end.

To end my participation in this issue - this really all boils down to a
judgement call, is the demand for "option purity" worth requiring code
this much more complex?

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 14:04:58 -0400

>you say, the client has to deal with all legitimate possibilities.
That 

Actually, I suspect that both client and server have to deal with it as
this is bi-directional "security", isn't it? At least from a validation
perspective (when the packet is generated, the client, relay, or server
can add it at the end - at least for now - but it can't expect it to be
at the end when received).

>judgement call, is the demand for "option purity" worth requiring code

Yes, IMHO, it is worth the added complexity (in my opinion, I don't
really think there's that much complexity here).

For a received packet, the node would already have had to find the
location of the option containing this data and it also has the length
(of the option as well as the packet). So, to skip to the end of the
option isn't exactly rocket science (start of option + sizeof(unsigned
short) + sizeof(unsigned short) + length of option data).

When sending a packet, putting the packet together is a bit more complex
if the option isn't at the end, especially if the size of the field
isn't known. But again, that is an implementation issue and left to the
implementer - it can always be added "last" or dealt with by moving the
parts of the data around.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 1:48 PM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

    Date:        Mon, 14 Jul 2008 10:59:39 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:
<[email-masked]>

  | This seems like a catch-22. How can someone determine the length of
the
  | Digital Signature field as there's no indication of how long the pad
  | field is.

  | Therefore, the Digital Signature field's length MUST be known based
on
  | other information (key, etc).

I think it is possible to work out how long it will be (so for eaample,
space can be allocated to store the result of the calculation), but the
key is certainly required to do that.   Since ideally you want the
private
key accessible for as little time as possible (so it doesn't end up in
crash
dump images, etc) you re

  | So, sure, putting 0's in the 100s of bytes and, likely more
  | significantly, having to calculate the signature over those
additional
  | bytes is a cost.

  | If we feel that is a burden, using multiple fragments is the way to
go.
  | Based on the original write-up in the draft, this is required anyway
so
  | there's really no savings.

  | The reason is that it is often easier to (temporarily) add data at
the end of
  | the message than to have allocated sufficient space BEFORE it (and
at least
  | KRE wants to avoid having to use multiple buffer fragments to hash
over). 

need to explain to me one day...) so they're easy.   The part that
causes

Of course, if everyone copies your method, and sticks the sig in the
middle
(or Ted's plan) then this won't be a real issue - I just couldn't
imagine
anyone actually writing this code that way.

  | It does require one more fragment than the original specification
(the
  | data beyond the end of the option). For the nodes that always add
the
  | option as the last option (based on their choice to do so), they can
  | avoid this last fragment. But, of course they can't assume this when
  | receiving a message.

The server has no problem, it just always puts the option last (if it
wants, or is required to by the spec) and everything is easy.   But as
you say, the client has to deal with all legitimate possibilities.
That
means (unless the spec prohibits it) that extra fragment at some place
in
the packet that must be correctly calculated (start & length) plus
dealing
with the possibility that they may rarely, if ever, actually get to
exercise
the code that handles this, if, as I believe likely, servers all just
put
the option at the end.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Jul 2008 01:21:39 +0700

Actually one more message, as I just remembered one more point I forgot ...

In practice, no-one cares.   The sender knows how big the sig is, that's
part of the result of the encryption.   It then adds as many padding bytes
as it wants for whatever purpose it needs them - which as an earlier message
from you pointed out, for DHCP, would be none at all, they're not needed.

The receiver (the protocol code that is verifying the signature) just treats
the sig and padding as a single field, and hands it all to the validator.
The validator understands the internal encoding of the sig field, and knows
how to find the length from there, and simply ignores the padding that
follows (I'm not even sure the caller bothers telling the validator the
length it believes the sig+padding occupies, more likely just ptr to sig).

So, in practice, the actual sig length is known where it is needed to be
known, and isn't needed anywhere else.   That is, none of us actually
needs to understand the internal sig encoding, to be able to figure out the
length - we simply don't care (which is one reason that authors of specs
never bother to mention that it exists - if they even realise it).

One thing I would point out from the spec sample you included (packet format).
If the length is 1 byte, and it is counting bytes in the option (I know the
one you quoted is not), then the option won't be able to handle entirely
plausible signatures.   Bigger than 255 bytes happens for keys < 2048 bits...
(not a lot less, but less).

SEND doesn't have that issue, as its length field is counting multiples of 8.
The MIPv6 ERO spec has a bug because of this.   It is something to be aware of.

kre

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2008 14:35:35 -0400

That spec detail I included was from SEND RFC and the length field there
is counting multiples of 8.

DHCPv6 option length fields are 16-bits, so not to worry. (If this was
for DHCPv4, more of a concern, but then there's Ted's RFC that can allow
multiple instances of the option to be concatenated. But v4 is not on
the table at present.)

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 14, 2008 2:22 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is

Actually one more message, as I just remembered one more point I forgot
...

In practice, no-one cares.   The sender knows how big the sig is, that's
part of the result of the encryption.   It then adds as many padding
bytes
as it wants for whatever purpose it needs them - which as an earlier
message
from you pointed out, for DHCP, would be none at all, they're not
needed.

The receiver (the protocol code that is verifying the signature) just
treats
the sig and padding as a single field, and hands it all to the
validator.
The validator understands the internal encoding of the sig field, and
knows
how to find the length from there, and simply ignores the padding that
follows (I'm not even sure the caller bothers telling the validator the
length it believes the sig+padding occupies, more likely just ptr to
sig).

needs to understand the internal sig encoding, to be able to figure out

One thing I would point out from the spec sample you included (packet
format).
If the length is 1 byte, and it is counting bytes in the option (I know
the
one you quoted is not), then the option won't be able to handle entirely
plausible signatures.   Bigger than 255 bytes happens for keys < 2048
bits...
(not a lot less, but less).

SEND doesn't have that issue, as its length field is counting multiples
of 8.
The MIPv6 ERO spec has a bug because of this.   It is something to be
aware of.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Jul 2008 01:36:47 +0700

Date:        Mon, 14 Jul 2008 14:04:58 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Actually, I suspect that both client and server have to deal with it as

I knew that using "client" was touchy - I mean the receiver of the option,
whatever role they play in the DHCP exchange. "client" was just easier
to type.   Apologies...

  | For a received packet, the node would already have had to find the
  | location of the option containing this data and it also has the length
  | (of the option as well as the packet). So, to skip to the end of the
  | option isn't exactly rocket science (start of option + sizeof(unsigned
  | short) + sizeof(unsigned short) + length of option data).

No, it's not, but do you want to imagine the number of off by one type
errors code like that has experienced over history - like does the code
remember the length field does, or does not, include the size of the
length field itself, ...  (as you write it above, clearly it doesn't,
but in other usages, it does, and implementors get confused...)  And
if in practice there's never anything there, the bug lies dormant.
That's what I was most worried about.

  | When sending a packet, putting the packet together is a bit more complex
  | if the option isn't at the end, especially if the size of the field
  | isn't known. But again, that is an implementation issue and left to the
  | implementer - it can always be added "last" or dealt with by moving the
  | parts of the data around.

Yes, I am not so much worried about the sender, which can do things as it
desires - though as I started to say in the paragraph I didn't finish typing
I now realise, ideally you don't want the private key to be in use more than
it needs to be, so requiring it to be accessed twice, once for a length
calc, and once for the sig calc, seems like just bad design.

But this is the kind of thing that someone who really understands the security
issues should be examining, and that is certainly not me.

kre

ps: really for the last time, unless of course I get a question I must
answer...

---

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

Hi, Bernie,

As we have said several times, it is certainly doable if the signature
option is somewhere in the middle and still protect message contents after
itself. It is only design choice, actually, either last or in the middle is
acceptable for us. We can change it if there is no other people insist last
should be mandated.

Many thanks for your valuable comments! Best regards,

Sean & Sheng

> Sent: Monday, July 14, 2008 10:16 PM
> To: Sean Shuo Shen; [email-masked]
> Cc: Mark Stapp (mjs); Sheng Jiang; [email-masked]
submitted.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Jul 2008 15:24:45 +0300

> (and yes, I mean the original packet, ignoring anything that later 
That is one way of implementing options that depend on other options 
(hashes and signatures etc).

But not the only one. Another common technique is zeroing out the 
authentication value before the actual calculation, on both receipt and 
send. The only problem with that is if the size of the authentication 
field is not known in advance. Is this the case here? A third approach 
is giving the hash/signature function two blocks of data.

And of course, as you mention, if there are multiple auth options then 
the placement as last is also going to be problematic. My initial 
thinking is that there is no reason to prevent RFC 3118 and CGAs to be 
used at the same time. E.g., RFC 3118 ensures we use a real DHCP server 
and CGA ensures clients do not hijack each others leases.

Jari