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

Re: simultaneous lifetime type support required?




>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
    Scott> others, it is appropriate to support it. But DOI only refers to phase 2,
    Scott> so what about phase 1? Is there language anywhere defining this?

  Frankly, I don't think that the ISAKMP SA will pass enough bytes to
ever justify expiring it by byte count. Time will always be the critical
factor for expiring keys for ISAKMP. 
  [If I'm wrong, and that the ISAKMP will pass megabytes of data in
under a hour or two, then there is probably something very wrong..]
  
    Scott> and if we want apply this same interoperability caveat to phase 1,
    Scott> shouldn't there be language to that affect in either ISAKMP or ARCH?

page 23 or arch-sec-06.txt:

         o Lifetime of this Security Association: a time interval after
           which an SA must be replaced with a new SA (and new SPI) or
           terminated, plus an indication of which of these actions should
|          occur.  This may be expressed as a time or byte count, or a
|	   combination of both, the first lifetime to expire taking
|	   precedence. A compliant implementation MUST support both
|	   types of lifetimes, and must support their combination.

	   If time
           is employed, and if IKE employs X.509 certificates for SA
           establishment, the SA lifetime must be constrained by the
           validity intervals of the certificates, and the NextIssueDate of
           the CRLs used in the IKE exchange for the SA.  Both initiator
           and responder are responsible for constraining SA lifetime in
           this fashion.
  
  (I'm almost sure that there is a better term than "combination". Something
more precise that expresses the fact that this is an inclusive or, but I 
can't think of the right word while taking a break from hex dumps)

   :!mcr!:            |  "Elegant and extremely rapid for calculation are the 
   Michael Richardson | techniques of Young tableaux. They also have the merit
                      | of being fun to play with." - p.47 Intro to Quarks&Partons
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 





Follow-Ups: References: