[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme
From:       Yoav Nir <ynir.ietf () gmail ! com>
Date:       2015-01-26 17:11:32
Message-ID: D578AFFA-43CB-4699-907D-B6D4199DDBE9 () gmail ! com
[Download RAW message or body]


> On Jan 26, 2015, at 5:24 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> Paul Wouters writes:
> > > > I think it is a server's policy issue. It can always restrict
> > > > the number of IPsec SAs from a single peer
> > > > by using NO_ADDITIONAL_SAS notification.
> > > > The document should not impose any restrictions here, IMHO.
> > > 
> > > Agree. Implementations might also have different limits depending
> > > whether the other end is authenticated or unauthenticated, i.e.
> > > unauthenticated clients might only be able to create for example 10
> > > Child SAs, and authenticated clients can create 1000 Child SAs... And
> > > btw child SAs are quite cheap, so the limit does not need to be 1 and
> > > 3... :)
> > 
> > But what's the point? Just to protect th per-port IPsec SA's with
> > more PFS in CREATE_CHILD_SA ?
> 
> For some reason people wnat to turn on PFS on TLS, so that NSA cannot
> break all the http-connections by just stealing that one key from the
> server.

This is an unfortunate naming issue. PFS in IKE vs PFS in TLS are very different \
beasts.

PFS in TLS is for protecting against a future compromise of the long-term private key \
associated with the server certificate. RSA keying protects the pre-master secret \
with the public key, requiring only the private key to decipher. So a future \
compromise of the (long-term) private key allows the attacker to decrypt your \
connection (very useful for debugging in wireshark)

PFS in IKE protects you against a future compromise of the ephemeral SK_d. Unlike the \
certificate private key, SK_d is generated during IKE, and is deleted at the \
expiration of the IKE SA. For a software-only implementation there is no reason to \
believe that the SK_d is any easier to steal than the traffic keys. Configurations \
tend to give IKE SAs a longer lifetime than the child SAs, but that is not required \
by the protocol.

PFS in TLS makes enough sense that UTA is recommending it for all TLS connections and \
the TLS working group is requiring it for the next version of TLS.  The thing that \
this group calls PFS is far less important, and doesn't always justify the cost.

Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]