headers
Yoav Nir | 3 Dec 2006 10:52
Picon
Favicon

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

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, Black_David <at> emc.com 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Black_David | 4 Dec 2006 03:34

RE: FW: I-D ACTION:draft-friedman-ike-short-term-certs-00.txt

Yoav,

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

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 

> -----Original Message-----
> From: Yoav Nir [mailto:ynir <at> checkpoint.com] 
> Sent: Sunday, December 03, 2006 4:52 AM
> To: Black, David
> Cc: arikf <at> cs.technion.ac.il; ipsec <at> ietf.org
> Subject: Re: [Ipsec] FW: I-D 
> ACTION:draft-friedman-ike-short-term-certs-00.txt
> 
> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 4 Dec 2006 06:13
Picon

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

On Wed, Nov 29, 2006 at 07:16:29PM +0200, Arik Friedman wrote:
>    This document describes an extension to IKEv2 that allows an endpoint
>    to prove to a security gateway that it was already authenticated by
>    another trusted security gateway, thereby allowing the authentication
>    of the endpoint without user intervention.  This is accomplished
>    using a Short Term Credential that the endpoint requests from the
>    authenticating security gateway.  This credential is a certificate
>    issued by the authenticating gateway for a short period of time, and
>    it can be used to authenticate the user with IKE signature based
>    authentication.

Sounds like a ticketing system.

Sounds like Kerberos V (with PKINIT).

Sounds fairly unrelated to IKEv2 and rather specific to PKIX.

Nico
--

--
Permalink | Reply | 1 comment |
headers
Ariel Shaqed (Scolnicov | 4 Dec 2006 11:17
Picon

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

I see our introduction needs more work!

On 12/4/06, Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:
> On Wed, Nov 29, 2006 at 07:16:29PM +0200, Arik Friedman wrote:
> >    This document describes an extension to IKEv2 that allows an endpoint
> >    to prove to a security gateway that it was already authenticated by
> >    another trusted security gateway, thereby allowing the authentication
> >    of the endpoint without user intervention.  This is accomplished
> >    using a Short Term Credential that the endpoint requests from the
> >    authenticating security gateway.  This credential is a certificate
> >    issued by the authenticating gateway for a short period of time, and
> >    it can be used to authenticate the user with IKE signature based
> >    authentication.
>
> Sounds like a ticketing system.

True.

However, more VPN gateways and clients are PKI-capable than are
Kerberos-capable.  We aim to use PKI capabilities of the client,
without requiring the administrator to deploy PKI to clients.

> Sounds like Kerberos V (with PKINIT).

We are after a lighter weight solution than Kerberos.  (RFC 4556 uses
client certs to produce Kerberos authentication, we use IKE EAP
authentication to produce a client cert).

Obviously Kerberos authentication (or PKI authentication) for clients
could solve re-authentication issues.  So-called "legacy"
(Continue reading)

Permalink | Reply | 0 comments |
headers
atulsharma | 6 Dec 2006 14:57
Picon

RE: IKEv2 traffic selector negotiation


I think this is another scenario where asymmetric security could be useful. Asymmetry could be needed for
different reasons, for example in this case direction. Some time ago there was discussion on this. I do not
know what direction we chose to take.

Atul 

 -------------- Original message ----------------------
From: <Pasi.Eronen <at> nokia.com>
> Hi,
> 
> IKEv2 always creates CHILD_SAs in pairs, and RFC 4301 assumes
> that SPD-S entries with UDP port selectors are unidirectional
> (unlike RFC 2401, which had separate SPD entries for inbound
> and outbound traffic even when applying IPsec protection).
> Thus, IKEv2 does not directly support negotiating this.
> 
> However, even if you create a bidirectional SA pair (using the first
> TSi/TSr you propose), nothing in the specs prohibits host A from
> dropping all packets arriving from B (e.g. using some firewall/packet
> filter functionality not negotiated within IKE).
> 
> This is not exactly the same as the ability to negotiate
> unidirectional SAs (if there are other SAs that could carry the
> traffic from B to A), but could accomplish what you want.
> 
> Best regards,
> Pasi 
> 
> > -----Original Message-----
(Continue reading)

Permalink | Reply | 15 comments |
headers
Russ Housley | 8 Dec 2006 21:30

draft-solinas-ui-suites-00.txt

The members of this mail list will probably find this new 
Internet-Draft interesting.

http://www.ietf.org/internet-drafts/draft-solinas-ui-suites-00.txt
Permalink | Reply | 6 comments |
headers
Pasi.Eronen | 11 Dec 2006 09:59
Picon

Comments about draft-solinas-ui-suites-00

A couple of minor comments about this draft:

1) The document needs a reference to draft-kelly-ipsec-ciph-sha2,
which specifies how to use SHA-256 with IPsec.

2) Currently draft-kelly-ipsec-ciph-sha2 specifies only SHA-256 
based integrity/PRF algorithms, but not SHA-384 or SHA-512, so 
"Suite-B-GCM-256" and "Suite-B-GMAC-256" are not actually
implementable using currently existing documents.

3) Given that SHA-384 is basically SHA-512 truncated to 384 bits 
(and with different IV), do we really need e.g. a SHA-384 based 
PRF for IKEv2? Wouldn't it be simpler just to use SHA-512?
(There are applications where using SHA-384 may make sense, but 
I'm not sure IKEv2 PRF is one of them...)

Best regards,
Pasi
Permalink | Reply | 1 comment |
headers
Scott G Kelly | 11 Dec 2006 15:17

Re: Comments about draft-solinas-ui-suites-00

FYI, we're updating draft-kelly-ipsec-ciph-sha2 to include sha-{384,512} 
  per Steve Bellovin's review comments. Hopefully, that will be 
available later this week.

Pasi.Eronen <at> nokia.com wrote:
> A couple of minor comments about this draft:
> 
> 1) The document needs a reference to draft-kelly-ipsec-ciph-sha2,
> which specifies how to use SHA-256 with IPsec.
> 
> 2) Currently draft-kelly-ipsec-ciph-sha2 specifies only SHA-256 
> based integrity/PRF algorithms, but not SHA-384 or SHA-512, so 
> "Suite-B-GCM-256" and "Suite-B-GMAC-256" are not actually
> implementable using currently existing documents.
> 
> 3) Given that SHA-384 is basically SHA-512 truncated to 384 bits 
> (and with different IV), do we really need e.g. a SHA-384 based 
> PRF for IKEv2? Wouldn't it be simpler just to use SHA-512?
> (There are applications where using SHA-384 may make sense, but 
> I'm not sure IKEv2 PRF is one of them...)
> 
> Best regards,
> Pasi
> 
> _______________________________________________
> Ipsec mailing list
> Ipsec <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 11 Dec 2006 19:03
Picon
Favicon

Last Call: 'Suite B Cryptographic Suites for IPsec' to Proposed Standard (draft-solinas-ui-suites)

The IESG has received a request from an individual submitter to consider
the following document:

- 'Suite B Cryptographic Suites for IPsec '
    <draft-solinas-ui-suites-00.txt> as a Proposed Standard

This document proposes four optional cryptographic user interface
suites ("UI suites") for IPsec similar to the two suites specified in
RFC 4308.  The four new suites provide compatibility with the United
States National Security Agency's Suite B specifications.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2007-01-08.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-solinas-ui-suites-00.txt
Permalink | Reply | 0 comments |
headers
Ali Fessi | 13 Dec 2006 12:50
Picon

downgrade attacks on IKEv2

Hi all,

I have a question on the negotiation of the IKE_SA in IKEv2:

The SA proposals in the IKE_SA_INIT exchange are not integrity 
protected, nor they are involved in the generation of the AUTH payload 
in the IKE_AUTH exchange.

So how can the Responder be sure that the set of proposals that he 
received from the Initiator is correct and how can the Initiator be sure 
that he received the correct crypto suite that has been chosen by Responder?

Couldn't this be misused for a downgrade attack which allow a 
man-in-the-middle attacker to force the usage of insecure (or less 
secure) algorithms for the IKE_SA?

Regards,
  Ali
--

-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: ali.fessi <at> uni-tuebingen.de
Web: http://net.informatik.uni-tuebingen.de/~fessi/
Permalink | Reply | 4 comments |

Gmane