Subject: Re: [ntpwg] WG: I-D Action: draft-ietf-ntp-network-time-security-03.txt

From: Kurt Roeckx <[email-masked]>
Date: Mon, 9 Jun 2014 21:21:26 +0200

On Wed, Mar 19, 2014 at 12:00:40PM +0100, [email-masked] wrote:
> 
> Hi all,
> 
> today we submitted an update of the NTS draft. Basically, we only changed
> the error in the formula of the cookie calculation which we introduced in
> the 02 version of the draft. The other suggestions of Steven Bellovin and
> other comments are currently still under consideration.

So I was wondering about the status of this, and would love to
hear an update.

I've been reading the draft again, and I have some comments.

It's my understanding that the reason for the whole cookie thing
is that we want to avoid the number of RSA signatures.  That makes
me wonder the following things:
- Do we have any idea how many clients are real ntp clients and
  not sntp clients?  
- I assume we want sntp clients to use this too.  Is there any
  idea at which point this solution actually reduces the load on
  the server and doesn't increase it?  I'm expecting sntp clients
  not to keep state, but I might be wrong here.
- Have you considered keys other than RSA like EC?  Maybe if we
  strongly suggest not to use RSA but something faster like EC
  and sign the reply we we can make things both simpler and reduce
  load on the server.

I've also been thinking wether we should send stapled OCSP responses
together with the server certificate.  And if we do, do we want
to enforce this stapled response or is this a best effort thing?

I'm also still wondering about how to bootstrap a system that
doesn't know what the current time is, and so doesn't know wether
the certificate is still valid or not.  Some of the idea's I had:
- Require an OCSP response with nonce.  But most CAs do not offer
  this.
- Require multiple servers where the issuer of the certificate
  is from a different root CA.

I would like to point out that we only need to do that in case we
have no idea what the time is.  I think it should be fine once we
know within 24 hours what the time is.

Kurt

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 10 Jun 2014 18:36:09 +0200

On Tue, Jun 10, 2014 at 01:11:17PM +0200, Röttger Stephen wrote:
> Hi Kurt,
> 
> Thanks a lot for your comments. Answers are inline.
> 
> The major points that we're working on right now are:
> - Kristof Teichel found a serious authentication bypass vulnerability in the
> protocol. The secret cookie is signed and then encrypted, making it possible
> for a mitm to reencrypt it and forward it to a different client.

If it's encrypted (with the client's key), a MITM shouldn't be
able to decrypt it, and this reencrypted?  Or did I misunderstand
something?

> I think we don't specify which algorithms should be used for the signatures
> and encryption. We only say that the server uses X.509 certificates to prove
> his identity, so any protocol supported by X.509 should be possible for us.

Which makes me wonder if the client should send which types of
key's it's willing to support, and if that's already planned or
not.

The server might for instance want to use ECDSA.  But that's a
sign only key that doesn't support encryption.  Would this work
on the server side?  On the client side?  Would it require to
also do ECDHE in that case?

> As per suggestion of Steve Bellovin, we are currently thinking about
> replacing the public key sent by the client with a X.509 certificate as
> well, which would allow the client to choose the encryption method through
> the certificate.

We only use assymetric cryptography like RSA?  There is no transtion
to something like AES?

> I tried to find out before how OCSP servers handle revoked but expired
> certificates. I couldn't find any specifics about this but I assume that
> they can purge their database and remove expired certificates from them and
> then reply with 'certificate not revoked'.
> Does anyone know more about this?

I think the best information for this is the CA/Browser forum
baseline requirements.  It has those section in it which I think
are relevant:
| 13.2.4 Deletion of Entries
| Revocation entries on a CRL or OCSP Response MUST NOT be removed
| until after the Expiry Date of the revoked Certificate.
[...]
| 13.2.6 Response for non-issued certificates
| If the OCSP responder receives a request for status of a
| certificate that has not been issued, then the responder SHOULD
| NOT respond with a "good" status. The CA SHOULD monitor the
| responder for such requests as part of its security response
| procedures.

I assume that 13.2.6 applies to expired certificates too.

> Your're right, this is a difficult problem and I think we will have to put more work into it. My thoughts so far:
> 
> If we don't know the current time, we can't tell if a certificate is already
> expired and thus I would argue that it's more likely that the private key
> has been compromised. The private key for an expired certificate might not
> be as well protected anymore since the certificate is expired anyway.
> A compromised server certificate won't be that big of a problem because we
> usually use multiple servers for time synchronization anyway.
> Leaving us with the scenario of a compromised CA certificate. I'm not that
> familiar with OCSP, but I assume in this case the attacker could also fake
> the OCSP replies.

OCSP is signed by the CA.  But you need to do OCSP for each
certificate in the chain.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 10 Jun 2014 23:33:04 +0200

> able to decrypt it, and this reencrypted?  Or did I misunderstand

The MITM could of course have used his own key, so could decrypt
it.

Kurt