rfc2154.txt

RFC 的详细文档！

       areas in the AS.  (This last case results in some situations that
       require special management - section 6)

   (2) The scope of a TE key is defined to be the set of routers that are
       configured with this key.  If a system is configured properly,
       then a TE public key will be configured on all the routers that
       will receive PKLSAs certified by that TE key.  The minimum scope
       for a TE key is an area.  If one router distributes a key
       certified with a given TE key, then all the routers in the area
       must be able toverify the certificate.  A TE Key certifying an
       ASBRs key must have a scope of all non-stub areas in the AS.  If
       the TE key is not on some router that receives PKLSAs certified by
       that TE key, then those PKLSAs and all the LSAs that require them
       will be discarded. A TE key gets to all the routers in its scope
       via out-of-band configuration.

   (3) The scope of a signature algorithm is defined to be the set of
       routers that are capable of verifying the given algorithm's
       signatures.  The minimum scope for a signature algorithm is an
       area.  All routers in an area must be able to verify any signature
       algorithm used for signing by any router in the area.  The
       algorithm used to certify an ASBRs key must have a scope of all
       non-stub areas in the AS if the ASEs are to be accessible
       everywhere (see section 6).  If a signature algorithm is not
       available to verify an LSA, then the LSA must be discarded.  If a
       signature algorithm is not available to verify the certification
       in a PKLSA, then the PKLSA must be discarded.

4.4.  Router Key Replacement

   Router keys should be changed periodically, and immediately if a key
   is found to be compromised.  The regular period for changing a key is
   some locally determined function of the size of the key and the level
   of security needed.

   Each router can have ONE valid key per area at any given time.
   Restricting the number of keys at a given time to one key per router
   per area allows key replacement to also serve the purpose of key
   revocation, without having a revocation list and without routers
   having synchronized time.  Each key for the router/area revokes the
   last key, provided the "new" key has a more recent Create Time than
   the last key.  The Create Time in each certificate is used to prevent
   an old key from being reused, but this Create Time is used only for
   comparing the relative ages of certificates, and does not require the



Murphy, et. al.               Experimental                     [Page 11]

RFC 2154              OSPF with Digital Signatures             June 1997


   router to run a time synchronization protocol itself.  An ABR can use
   the same key for all it's attached areas, or it can have a unique key
   for each area.  This allows an AS to be managed by area with each
   area potentially having a different TE, signature algorithm, key
   size, and/or key.

   When a new key replaces an old key, the router must quickly replace
   LSAs signed with the old key with LSAs signed with the new key. To
   change a router key the following steps must be followed:

   (1) A valid certificate for the new key must be obtained for the
       router.

   (2) The router builds and sends a new PKLSA with the new certificate.

   (3) The router signs each self-originated LSA with the new key and
       sends them.

   When a PKLSA is received:

   (1) If the PKLSA's age = MaxAge, remove the PKLSA from the LSDB and
       age LSAs signed with this key to be MaxAge - MAX_TRANSIT_DELAY,
       if they were not already older than this.  This is a way to get
       rid of a key that should no longer be used.

   (2) If the PKLSA is a refresh LSA for an existing key, update the
       LSDB.

   (3) If the PKLSA contains a different key than the one currently
       stored for this router, compare the certificate Create Time.  If
       the PKLSA key is less recent, discard it.  If the PKLSA key is
       more recent, install it in the LSDB and remove the old key from
       the LSDB.  If an old key was deleted from the LSDB, age LSAs
       signed with this key to be MaxAge - MAX_TRANSIT_DELAY, if they
       were not already older than this.

4.5.  Trusted Entity Key Replacement

   It is necessary to change a TE public key periodically.  It is
   recommended that the TE public key be relatively large, so that it
   does not frequently require replacement.  A router may store multiple
   TE public keys.  Each key is uniquely identified by TE Id and TE Key
   Id.  TE keys are used to verify certificates received from other
   routers in their PKLSAs.  When a router sends a new certificate
   signed with a new TE Key, all the routers that receive the PKLSA
   containing the certificate must have that new TE Key in order to
   verify, store, and use that PKLSA.  Management of TE public keys is
   done outside the OSPF protocol, and a method is suggested, but not



Murphy, et. al.               Experimental                     [Page 12]

RFC 2154              OSPF with Digital Signatures             June 1997


   mandated by this design.  Initially all routers must be configured
   with the TE Keys they will need to verify the certificates they will
   receive.  To prevent use of a (possibly compromised) TE Key, that key
   must be replaced by a new (possibly null) TE Key having the same TE
   Id and signature algorithm.  A compromised or faulty router can
   continue using certificates signed with the old TE key, but none of
   the properly configured routers will be able to verify them.

   Changing a TE public key presents a design challenge.  When a TE
   Public Key is changed, all the certificates depending on that key
   must also change.  The router keys in the certificates may or may not
   be changed at the same time.  When the TE key and certificates
   change, all PKLSAs depending on these must be reissued. In order to
   verify these new certificates, all routers receiving the new PKLSAs
   must have the new TE Public Key.  So, the TE key replacement must be
   a synchronized event.  Routers are not required to have synchronized
   clocks.  The TE public key may well be distributed to the routers via
   an out-of-band mechanism (like a smart-card reader or other sneaker-
   net method).  It is not reasonable to require that all the routers
   obtain the TE public key at the same time.  There are probably
   several methods for meeting these requirements.  The method tested in
   our implementation is as follows:

   (1) Define a period of time needed to get the new TE key on all
       routers.  This could be minutes, hours, even days depending on
       how the distribution is accomplished.  This time period is a
       configuration value for each router (TE_KEY_DIST_INT) and must be
       the same for all routers sharing a TE.

   (2) Install a new TE key and associated certificates (if there are
       any) on each router.  Signal the router code when the new TE key
       is available to be accessed.

   (3) The router sets a timer for the TE_KEY_DIST_INT.  The router
       sets a flag indicating the presence of a new TE key.

   (4) For each router, if the timer goes off:

         Access the new TE key.
         If there are new certificates, build and send a new PKLSA.
         Age all PKLSAs in the LSDB certified by the old TE Key
                 to MaxAge - MAX_TRANSIT_DELAY.









Murphy, et. al.               Experimental                     [Page 13]

RFC 2154              OSPF with Digital Signatures             June 1997


   (5) For each router, if a PKLSA certified by a new TE key comes in
       before the timer goes off:

         If the new TE key cannot be accessed, discard the PKLSA and
                 log an ERROR.
         Access the new TE key.
         Process the received PKLSA.
         If there are new certificates, build and send a new PKLSA.
         Age all PKLSAs in the LSDB certified by the old TE key
                 to MaxAge - MAX_TRANSIT_DELAY.

   The effect of this method is that it takes a predetermined interval
   of time to change the TE public key.  That interval is the amount of
   time from the installation of the new TE key on the FIRST router
   installed, until the time that router reads the key in.  By the time
   the first router reads the key in, all other routers should have the
   new key.  If some router does not get the new TE key in time, it will
   be unable to verify all the new PKLSAs that are received.  It will
   log error messages and route data based on it's old database until
   those LSAs time out.  The simple way to fix a router in this error
   condition is to load the new TE key and restart the router.  If this
   error is expected to occur, and restarting the router is not
   acceptable, then some special purpose code will be needed to read in
   the TE key after it has been otherwise distributed, and do database
   synchronization to catch up with the other routers.

   The group of routers that need the new TE key are all the routers in
   the scope of that Trusted Entity.

4.6.  Flexible Cryptographic Environments

   It is likely that an AS will have one cryptographic environment in
   use throughout the AS, with one trusted entity, one signature
   algorithm in use, and one key in use per router.  To allow those
   cases where this is not true, multiple signature algorithms, multiple
   trusted entities, and multiple keys per router are allowed.

4.6.1.  Multiple Signature Algorithms

   It is possible to support multiple signature algorithms.  Each router
   and TE key has a signature algorithm associated with it.  All routers
   sending a key with a given algorithm must be capable of generating
   signatures of that kind, and all routers receiving keys with a given
   algorithm must be able to verify the signatures.  If a router
   receives an LSA signed with a signature algorithm that it does not
   support, the LSA must be discarded.  LSAs that cannot be verified by
   a router are not flooded by that router.  When using multiple
   signature algorithms, the scope of each algorithm must be determined



Murphy, et. al.               Experimental                     [Page 14]

RFC 2154              OSPF with Digital Signatures             June 1997


   (see section 4.3), and routers must be configured with support for
   these algorithms accordingly.

   If an Area supports two signature algorithms and is to have full
   connectivity, some routers may sign with algorithm A and others with
   algorithm B, but all routers in the area must be able to verify
   signatures for A and B.  In an AS that is divided into areas, it is
   possible for each area to have a different signature algorithm.  The
   ABR connecting two areas would have to support both algorithms, but
   the internal routers in a given area would only have to know one
   algorithm.

   ASBRs present a problem for this sort of division.  ASEs flood
   throughout the non-stub areas of an AS.  Any router that cannot
   verify an ASE will discard it without flooding.  So, to have access
   to an ASE, a router, and all the routers in the flooding path, must
   support the algorithm used by the ASBR.  One way around these
   difficulties is to have a lowest-common-denominator algorithm that is
   used for signing by all ASBRs and is supported for verification
   throughout the AS in addition to other algorithms used.  Another
   approach is to place ASBRs on the backbone, and configure all areas
   using a signature algorithm different from the ASBR to have a default
   route to the backbone.  A combined approach will allow an ASBR to be
   in a non-backbone area if it uses a signature algorithm supported on
   the backbone, and the areas using different signature algorithms are
   configured with a default to the backbone.  There are special
   limitations in the case of a router that is an ABR and also an ASBR:
   see section 6.

   There is currently only one signature algorithm (RSA_MD5) defined for
   use by this design.  The RSA algorithm is defined in PKCS #1 [9] and
   the signature and key formats used by this design are defined in
   RFC2065 [10].

4.6.2.  Multiple Trusted Entities

   It is possible to have multiple Trusted Entities in an AS.  Each TE
   has a unique TE identifier.  Every router receiving PKLSAs certified
   by a given TE must have that TE's public key.  If a router receives a
   PKLSA certified by a TE for which it does not have a public key, the
   PKLSA must be discarded.  When using multiple TEs, the scope of each
   TE must be determined (see section 4.3), and routers in this scope
   must be configured with the TE key.








Murphy, et. al.               Experimental                     [Page 15]

RFC 2154              OSPF with Digital Signatures             June 1997


4.6.3.  Multiple Keys for One Router

   An ABR may have one key for each attached area.  These keys may
   differ in size, algorithm and/or certifying TE.  Generally, each key
   will have a "scope" of the attached area, and there will be no
   conflict between keys.

   There are special limitations in the case of a router that is an ABR
   and also an ASBR: see section 6.