Subject: Re: [Ipsec] FW: I-D ACTION:draft-friedman-ike-short-term-certs-00.txt

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Dec 2006 11:52:23 +0200

Hi David.

Other documents dealing with certificates (such as RFC 3280) do not  
mention attacks against computer clocks, and I don't see why that  
should be introduced here.

Perhaps it's better to move that paragraph out of the Security  
Considerations section and into a (new) Operational Considerations  
section and rephrased as follows:

Operational Considerations
    Because of the granularity of Short Term Certificates expiration
    time, clocks of mutually trusting security gateways SHOULD be
    synchronized.  The synchronization mechanism is out of scope
    for this document, but may be based on [RFC1305] or [RFC2030].

On Nov 30, 2006, at 11:47 PM, [email-masked] wrote:

> Arik,
>
> The Security Considerations section notes the dependence
> of the "short term" property on security gateway clocks,
> but doesn't seem to cover all the cases needed to prevent
> problems here - all it says is that:
> 	1) If there are multiple security gateways
> 	2) Then their clocks SHOULD be synchronized
> I think there is room for improvement in both aspects.
>
> 1) Gateway clocks have to be protected even if there's
> only a single gateway.  If an attacker can roll a security
> gateway's clock back, the attacker has extended the
> validity of short term certificates, even if there's only
> one gateway.  I suggest that all gateway clocks MUST be
> protected against rollback, and in addition, the time
> span of certificate validity (notBefore to notAfter) in
> short term certificates SHOULD be limited (limit TBD) to
> cap the benefit from a single clock rollback event.
>
> 2) The general "SHOULD" is a bit weak.  As a strawman I'd
> suggest that if the STC_LIFETIME attribute is used
> (indicating a concern about problems caused by lack of
> clock synchronization with the client), then the security
> gateway clocks MUST be synchronized in some fashion -
> the current text that provides examples but does not
> require a specific method to be used is fine.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>> -----Original Message-----
>> From: Arik Friedman [mailto:[email-masked]]
>> Sent: Wednesday, November 29, 2006 12:16 PM
>> To: [email-masked]
>> Subject: [Ipsec] FW: I-D
>> ACTION:draft-friedman-ike-short-term-certs-00.txt
>>
>> Hello,
>>
>> We would appreciate any comments you may have regarding this
>> draft, either
>> privately or to the IPSec mailing list.
>>
>> Thanks,
>> 	Arik Friedman.
>
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Sun, 3 Dec 2006 21:34:01 -0500

Yoav,

> should be introduced here.

I believe typical certificate validity periods are long enough that
there's not much point to attacking a computer clock.  This draft
envisions validity periods short enough that it already has text
addressing clock skew and clock synchronization issues.  IMHO,
protection against clock rollback is also needed to complete the
discussion of what is different when the certificate validity
period is deliberately short.

Thanks,
--David 

> From: Yoav Nir [mailto:[email-masked]] 
> Sent: Sunday, December 03, 2006 4:52 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ipsec] FW: I-D