[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Dangling phase 2 SAs (was RE: issues from the bakeoff)




> -----Original Message-----
> From: Heyman, Michael [mailto:Michael_Heyman@NAI.com]
> Sent: June 18, 1999 12:05 PM
> To: 'Tim Jenkins'; ipsec@lists.tislabs.com
> Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff) 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >[SNIP
> > > 
> > > The issue of dangling phase 2 SAs seems to have created a camp
> > > that believes that when a certificate is revoked, a compromise
> > > has occured, and therefore any phase 2 SAs created under the
> > > phase 1 SA with a now revoked certificate as the authentication 
> > > mechanism should be removed.  
> > > 
> > > Point 1: Compromise? What compromise?
> > > 
> > > There are many reasons to revoke a certificate that in no way
> > > invalidates authorizations that certificate performed prior to
> > > the revokation. For example, an employee leaves a company, the
> > > company revokes that employees certificate. Actions that employee
> > > took while still employed are still valid. 
> > 
> > I don't think system administrators would agree with you here. If
> > an employee leaves a company, he/she is supposed to leave behind 
> > all access to that company's assets. The longer SAs are left up
> > after this  point, the greater the exposure.  
> > 
> > Yes, it's a different kind of compromise that key material or
> > authentication, but it's a compromise none the less.
> > 
> Hmm, to make sure I understand, a contrived example:
> 
> . Gary the GVPN administrator has a company issued certificate
>   giving him the privilege to set up a secure link.
> 
> . He sets up a GVPN link using IPsec/IKE between his company and
>   Widget Inc. using his company issued certificate for 
>   authorization.
> 
> . Gary then leaves the company. The company issues Gary's 
>   certificate in a CRL.
> 
> . Widget Inc. is paranoid (a good thing) and assumes, upon
>   getting the new CRL, that Gary left for evil reasons and 
>   before he left, had oppertunity to get key information. 
>   What does Widget Inc. do? Dump all the SAs that were in
>   any way under Gary's control to reduce possible exposure.
> 
> This makes sense - maybe I'm changing my mind :-) . But, on the other
> hand, if Gary's certificate just expired, I think that does not
> invalidate what was authenticated with the certificate before the
> certificate expired. (A document signed before the signature key
> certificate expired still has a valid signature long after the
> signature certificate expires.)

If Gary's certificate just expired, he's not going to be able to re-key
eventually anyway unless he's issued an updated certificate. Again, the
difference is how soon he will need that updated certificate.

If dangling phase 2 SAs is allowed, then he has (up to) the sum of the phase
1 and phase 2 expirations. If dangling SAs are not allowed, he has up to the
phase 1 expiration time.

Which is more prudent? Reducing the exposure window in case of Gary leaving
the company, or opening the window in the case of Gary's certificate
expiring?

> 
> So, IMHO, dangling phase 2 SAs are ok (and may even be needed) but,
> implementers may wish to create a way to get rid of phase 2 SAs based
> upon some types of change of validity of authentication in phase 1.

This is an interesting point, since it may be *customer* requirement of
products anyway. In which case, the window size when Gary leaves the company
may be irrelevant.

However, I'm concerned about scalability issues in systems that need to
provide that mechanism. CRLs have to be issued and then pushed (or CRL
caches flushed) before the checks on local entities can even begin.

> 
> - -Michael Heyman
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.5.1b23
> 
> iQA/AwUBN2ps8bXbkJfuXzRQEQJO5gCgsvKvtQ7IlCizxZzm77AtgdFrkWUAoMIx
> dTJbDFr75Kvcn4Yo6ss27dgA
> =Q1u8
> -----END PGP SIGNATURE-----
>