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

[Robert Elz <kre at munnari.OZ.AU>]

    Date:        Mon, 14 Jul 2008 09:41:45 -0400
    From:        "Bernie Volz (volz)" <volz at cisco.com>
    Message-ID:  <8E296595B6471A4689555D5D725EBB21080C9FAD at xmb-rtp-20a.amer.cisco.com>

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


volz at cisco.com said
   in <8E296595B6471A4689555D5D725EBB21080C9FB2 at xmb-rtp-20a.amer.cisco.com>:
  | 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

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg