Subject: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 23 Jun 2014 16:19:20 +0200

Timestamps are not enough for the anti-replay protection and
are difficult to implement for clients without a good long term
real time clock, so I propose:
 - to introduce a nonce option which will be processed as an extension
  of the transaction ID (so there are already 3 octets)
 - to put the timestamp in its own option (so it can be omitted)
 - to document a way for an unsynchronized node to get a good time value,
  for instance sending an Information-Request or a Solicit without
  rapid-commit asking for a timestamp option in the ORO
I propose to require the timestamp option in all messages changing the
state (e.g., request, renew, etc) and everything from agents.
I don't propose to make nonces mandatory but there is no good reason
to not use them as soon as they are supported.
A still open problem is what to do with clock mismatch between agents
but this has in fact only an impact on optimization (multicast to
more than one agent) so IMHO we can live with it.

The second point is about (X.509 public key) certificates. They are useless
without the trust anchor, the whole chain, CRLs, etc. And if we want
to use self-signed certificates they bring nothing compared to raw
public keys. And I don't talk about profiles (even SeND had to be
completed by RFC 6494). So I really suggest to drop the certificate
option and to use the key option to identify the public key.

The last point is compatibility with SeND (RFC 3971). Today in red and
black (:-) environments it is possible to secure the Neighbor Discovery
but not DHCP. I propose to fix this using the secure DHCPv6 for
the protection of DHCP and the SeND section 6 Authorization Delegation
Discovery for the "certificate part".

Regards

[email-masked]

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 25 Jun 2014 08:16:37 +0000

Hi, Francis,

Please see replies in lines.

> - to put the timestamp in its own option (so it can be omitted)

We could apply this to next version.

>  rapid-commit asking for a timestamp option in the ORO

This has to be a separated document. It remains out of scope for this document. In most of cases, it is ok to assume a node have a time which has less 5-min time drift. A brand new node without any knowledge of time is an edge case.

>to not use them as soon as they are supported.

It's reasonable.

>option and to use the key option to identify the public key.

Actually, certificate would be very useful for server to authorize the client. It is much less useful on a client, who have not been allowed to connect on line. In such case, certificate can be used with LoF, which is equal usage as identify the public key.

>Discovery for the "certificate part".

Could you be more clear how this may work? I am not sure I fully understand your proposal. So far, SeDHCPv6 has no compatibility issues with SeND, because they are two solutions independent from each other. We don't want to introduce any dependency between them, which would make the deployment much more complicated.

Best regards,

Sheng

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Jun 2014 13:50:10 +0200

In your previous mail you wrote:

>  This has to be a separated document. It remains out of scope for this docume
>  nt. In most of cases, it is ok to assume a node have a time which has less 5
>  -min time drift. A brand new node without any knowledge of time is an edge c
>  ase.

=> to make timestamps more efficient for security you have to allow only
small drift, so a pre-synchronization procedure should help to solve
the unsecure/large vs secure/hard-to-implement drift. Note about the
first statement I agree it is "not normative".

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Jun 2014 14:06:01 +0200

In your previous mail you wrote:

>  Actually, certificate would be very useful for server to authorize the clien
>  t. It is much less useful on a client, who have not been allowed to connect 
>  on line. In such case, certificate can be used with LoF, which is equal usag
>  e as identify the public key.

=> for the first point something like the URI and hash from IKEv2 is
IMHO far more usable than to put the certificate inside the message.
And I disagree about the second statement: there is no reason to
give up about the server authorization. It is a hard problem but
not an untrackable one (as SeND proved). For the last a public key
option is simpler and more efficient so it is not an argument for
keeping the certificate option.

>  Could you be more clear how this may work? I am not sure I fully understand 
>  your proposal. So far, SeDHCPv6 has no compatibility issues with SeND, becau
>  se they are two solutions independent from each other. We don't want to intr
>  oduce any dependency between them, which would make the deployment much more
>  complicated.

=> I don't want to introduce dependency but to make them to be able to
work not only together but in complement, exactly as DHCPv6 and ND are
(even it took a very long time to finalize all details).
The missing part in SeDHCPv6 is the authorization, i.e., all the higher
order thing about certificates. This is already handled in SeND, perhaps
not in the best way, so the idea is to say for SeDHCPv6 + SeND we don't
need to reinvent the wheel.
This could leave two use cases for SeDHCPv6: LoF or statically
pre-configured SeDHCPv6 using raw public keys, and SeDHCPv6 + SeND
for strongly secured environments. Perhaps not the whole thing we want
but enough to "sell" a first version.

Regards

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 25 Jun 2014 14:49:58 +0200

On 25/06/14 13:50, Francis Dupont wrote:
> the unsecure/large vs secure/hard-to-implement drift. 
To me it seems that  a pre-synchronisation procedure is a great help for
intruders?

Now you can make sure the target is in time sync with the attack just by
synchronising with it first, really opens the window for attacks.

> Note about the

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 26 Jun 2014 03:49:13 +0000

>IMHO far more usable than to put the certificate inside the message.

We did discuss URI for certificate in DHC WG before. It is the WG consensus not to use URI, because it introduces additional overhead and time delay to server to download the certificate. It is also introduce some DDOS risks.

>but enough to "sell" a first version.

May we reach agreement on the below statement:

1. From the above discussion, the certificate option is already defined for client-to-server. Using the certification option on the server-to-client can archive the same function as public key, in LoF mode. So, keeping certificate as an alternative will not introduce any harm.

2. The client may get support from another mechanism to be able to validate the server certificate (transmitted by the certificate option), such as obtaining certificate chain from SEND.

Regards,

Sheng

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Jun 2014 18:11:11 +0200

>  To me it seems that a pre-synchronisation procedure is a great help for

=> I can't see why you say that or do you mean timestamps have another
role than anti-replay?

>  synchronising with it first, really opens the window for attacks.

=> which attacks? messages are signed so a synchronized attacker has
no advantages...

Regards

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 26 Jun 2014 18:47:59 +0200

> On 26 Jun 2014, at 18:11, Francis Dupont <[email-masked]> wrote:
> 
My point is that giving the attacker the means to synchronise the replay attack with the target will give replay attacks a considerable time window in which to play.

> => which attacks? messages are signed so a synchronized attacker has
If signing messages in itself protects against replays, why bother with synchronising time?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Jun 2014 18:56:01 +0200

In your previous mail you wrote:

>  We did discuss URI for certificate in DHC WG before. It is the WG consensus 
>  not to use URI, because it introduces additional overhead and time delay to 
>  server to download the certificate.

=> I don't buy this argument as the certicate alone is useless (i.e.,
you need the validation path/chain, CRLs, etc).

> It is also introduce some DDOS risks.

=> it is the use of certificates which introduces some DDoS risks...

>  1. From the above discussion, the certificate option is already defined for 
>  client-to-server.

=> but nothing more than the certificate option so IMHO this part of
the current proposal is strickly NOT applicable.

>  So, keeping certificate as an alternative will not introduce any harm.

=> it is just useless complexity so it introduces harm.

>  2. The client may get support from another mechanism to be able to validate 
>  the server certificate (transmitted by the certificate option), such as obta
>  ining certificate chain from SEND.

=> this argument is based on the wrong assumption the whole certificate
is needed to recognize it. It is fully wrong: an X.509 public key
certificate is only a signed public key with attributes.
Note you can argue you can get more than one certificate sharing the
same public (and private) key. IMHO  this is more than bad practice
so there is no need to support it (i.e., looking for the first
matching certificate is enough).

To summary the choice is between dropping the certificate stuff
or to fix it with for instance a profile, etc. It could take years
to get seDHCPv6 so please keep it simple...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Jun 2014 19:28:25 +0200

In your previous mail you wrote:

> My point is that giving the attacker the means to synchronise the
> replay attack with the target will give replay attacks a considerable
> time window in which to play.

=> synchronization allows to offer a smaller window.
I have two other arguments:
 - IMHO it is better to consider clients will be synchronize than
  to allow a large window and expect attackers to be never synchronized
 - it is clear timestamps by themselves are not enough, this is why
  I proposed to add nonces (note transaction IDs already provides
  24 bit of unpredictable data but 24 bits are not enough for high
  speed LANs)

> If signing messages in itself protects against replays, why bother

=> signing is for origin and integrity, timestamps and/or nonces
are for anti-replay. Note it seems we need more analysis about
the usefulness of the anti-replay (I thought about the obvious
RELEASE replayed after a long delay but anyway a good security
threat analysis is (*again*) hardly needed... argh!)

Regards

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 Jun 2014 10:34:09 -0700

At Thu, 26 Jun 2014 18:56:01 +0200,

> >  May we reach agreement on the below statement:
[...]
> => it is just useless complexity so it introduces harm.
[...]
> to get seDHCPv6 so please keep it simple...

I tend to agree with Francis.  I see we'll need more work to make the
use of certificates in the DHCP authentication workable.

I previously heard that this work tried to provide what people have
been requesting.  I wonder whether the request includes the ability of
using certificates as a mandatory component.  If not, it seems to make
more sense to focus on the public key usage and publish it sooner.

--
JINMEI, Tatuya

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 26 Jun 2014 20:13:35 +0200

> On 26 Jun 2014, at 19:28, Francis Dupont <[email-masked]> wrote:
> 
On the contrary. Synchronisation allows me(the attacker) to change the victim's time to suit my replay.
>  to allow a large window and expect attackers to be never synchronized
Attackers will synchronise but to their liking, in effect the attacker will always be synchronised.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Jun 2014 14:25:33 +0200

> the victim's time to suit my replay.

=> I don't follow you again. What is the victim (client or server)?
And BTW can you detail one attack example?

Regards

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 27 Jun 2014 14:55:09 +0200

> And BTW can you detail one attack example?
Ok, let me be more explicit (or try).

The way I understand this is:

- In order to make communication more secure, time settings in the two
ends need to be "close enough"
- To make sure the time settings are synchronised, you want to introduce
a synchronisation step at the beginning of the communication, then time
settings will be close enough
- Now communication can proceed using time as part of the transaction

If I want to attack the end that needs to be synced, here is my plan:
- Start the synchronisation procedure, but set time to fit the replay
attack I have in mind. This could be weeks away from today's time
(depending on the synchronising procedure)
- After this step, the remote end has a completely different time than
what it should be.
- Now I should have a much easier task making a replay attack, any
reference to the time set will be correct as I have set the clock in the
victim to match my attack.

This is not a specific attack as I don't have one at hand, what I see is
that the fact that I can set the time in my victim to be exactly what I
like it to be, must offer me a broader choice of attack options. This is
what I don't like about the proposal.

I possibly missed something here, please help me understand why it helps
communication but does not help attacks to be able to set any
"appropriate" time in the victim.

I would see this as one more tool in my hand.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Francis Dupont <[email-masked]>
Date: Sat, 28 Jun 2014 10:52:20 +0200

>  ends need to be "close enough"

=> yes

>  settings will be close enough

=> no, I only propose for nodes without a good real time clock
and which believe they could be out of synchro to recover first.

>  - Now communication can proceed using time as part of the transaction

=> it was already the case: the trade-off is between secure/small
window or reliable/large window, and I only propose a way to choose
the first (i.e., more secure) at a minimal cost with the hardware we
have today...

>  (depending on the synchronising procedure)

=> this is possible only when you have a rogue but trusted server.
In this case a replay is not the problem.

>  - After this step, the remote end has a completely different time than

=> DHCP is not peer-to-peer but client-server.

>  I possibly missed something here

=> DHCP is not a general protocol (and BTW your concern is not in fact
about synchronization but timestamps, and seDHCPv6 is based first
on signature, not on timestamps, so unsigned messages are simply
considered as unsecure and should be dropped if the policy requires
secure messages).

Regards