> On Jan 26, 2015, at 5:24 PM, Tero Kivinen <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
