home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-doi-00.txt < prev    next >
Text File  |  1997-10-17  |  23KB  |  618 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                 R. Atkinson, Editor
  6. Internet Draft                                              @Home Network
  7. draft-ietf-ospf-doi-00.txt                                15 October 1997
  8.  
  9.  
  10.  
  11.  
  12.             OSPFv2 Domain Of Interpretation (DOI) for ISAKMP
  13.  
  14.  
  15.  
  16.  
  17.  
  18. STATUS OF THIS MEMO
  19.  
  20.       This document is an Internet Draft. Internet  Drafts  are  working
  21.    documents  of  the Internet Engineering Task Force (IETF), its areas,
  22.    and working groups.  Note  that  other  groups  may  also  distribute
  23.    working documents as Internet Drafts.
  24.  
  25.       Internet Drafts are draft documents valid for  a  maximum  of  six
  26.    months  and may be updated, replaced, or obsoleted by other documents
  27.    at any time. It is inappropriate to use Internet Drafts as  reference
  28.    material or to cite them other than as ``work in progress.''
  29.  
  30.       To learn the current status of any Internet  Draft,  please  check
  31.    the  ``1id-abstracts.txt''  listing  contained in the Internet Drafts
  32.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net  (Europe),
  33.    munnari.oz.au   (Australia),  ds.internic.net  (US  East  Coast),  or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36.       Distribution of this memo is unlimited. This draft will expire six
  37.    months  from  date  of  issue.  This draft is a work item of the Open
  38.    Shortest Path First (OSPF) Routing  Protocol  Working  Group  in  the
  39.    IETF.   Comments  may  be  sent  to the editor or to the OSPF WG as a
  40.    whole at its mailing list.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.    1. Abstract
  47.  
  48.       The Internet Security  Association  and  Key  Management  Protocol
  49.    (ISAKMP)  defines a framework for security association management and
  50.    cryptographic key establishment for  the  Internet.   This  framework
  51.    consists  of  defined  exchanges and processing guidelines that occur
  52.    within a given Domain of Interpretation (DOI).  This document details
  53.  
  54.  
  55.  
  56. Atkinson                  Expires in 6 months                   [Page 1]
  57.  
  58. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  59.  
  60.  
  61.    the  OSPFv2  DOI,  which  is  defined  to  cover the use of ISAKMP to
  62.    negotiate Security Associations for the OSPFv2 routing protocol.
  63.  
  64. 2. Introduction
  65.  
  66.       Within ISAKMP, a Domain of Interpretation is used to group related
  67.    protocols  using ISAKMP to negotiate security associations.  Security
  68.    protocols sharing a DOI choose security  protocol  and  cryptographic
  69.    transforms  from  a  common namespace and share key exchange protocol
  70.    identifiers.  They also share a common interpretation of DOI-specific
  71.    payload   data   content,  including  the  Security  Association  and
  72.    Identification payloads.
  73.  
  74.       Overall,  ISAKMP  places  the  following  requirements  on  a  DOI
  75.    definition:
  76.  
  77.         o  define the naming scheme for DOI-specific protocol identifiers
  78.         o  define the interpretation for the Situation field
  79.         o  define the set of applicable security policies
  80.         o  define the syntax for DOI-specific SA Attributes (phase II)
  81.         o  define the syntax for DOI-specific payload contents
  82.         o  define additional mappings or Key Exchange types, if needed
  83.  
  84.       The remainder of this document details the instantiation of  these
  85.    requirements   for  using  the  OSPFv2  cryptographic  authentication
  86.    mechanism to provide data origin authentication  for  OSPFv2  routing
  87.    packets sent between cooperating routers.
  88.  
  89.  
  90.  
  91. 3. Terms and Definitions
  92.  
  93.       In  this  document,  the  words  that  are  used  to  define   the
  94.    significance  of each particular requirement are usually capitalised.
  95.    These words are defined in RFC-xxxx,  which  is  hereby  incorporated
  96.    into this document by reference. [RFC-xxxx]
  97.  
  98.       Within ISAKMP, all DOI's must be registered with the IANA  in  the
  99.    ``Assigned  Numbers''  RFC [STD-2].  The IANA Assigned Number for the
  100.    OSPFv2 DOI is <TO BE ASSIGNED BY IANA>.  Within the OSPFv2  DOI,  all
  101.    well-known  identifiers  MUST  be  registered with the IANA under the
  102.    OSPFv2 DOI.  Unless otherwise noted, all tables within this  document
  103.    refer to IANA Assigned Numbers for the OSPFv2 DOI.
  104.  
  105. 4.0 Assigned Numbers
  106.  
  107.       The following sections list the Assigned Numbers  for  the  OSPFv2
  108.    DOI   Security   Protocol  Identifiers,  Transform  Identifiers,  and
  109.  
  110.  
  111.  
  112. Atkinson                  Expires in 6 months                   [Page 2]
  113.  
  114. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  115.  
  116.  
  117.    Security Association Attribute  Types.   Note  that  all  multi-octet
  118.    binary values are stored in network byte order.
  119.  
  120. 4.1 OSPFv2 Situation Definition
  121.  
  122.       Within ISAKMP, the Situation provides information that can be used
  123.    by  the responder to make a policy determination about how to process
  124.    the incoming Security Association request.  For the OSPFv2  DOI,  the
  125.    Situation  field  is  a  four  (4)  octet  bitmask with the following
  126.    values.
  127.  
  128.           Situation                   Value
  129.           ---------                   -----
  130.           SIT_AUTHENTICATION          0x01
  131.  
  132.  
  133.       All other values are reserved to IANA.
  134.  
  135.       The  SIT_AUTHENTICATION   type   specifies   that   the   security
  136.    association will be identified by source identity information present
  137.    in an associated Identification Payload.  See  Section  4.8.2  for  a
  138.    complete description of the various Identification types.  All OSPFv2
  139.    DOI implementations MUST support SIT_AUTHENTICATION by  including  an
  140.    Identification  Payload  in  at  least  one  of  the  phase  I Oakley
  141.    exchanges ([IO], Section 5) and MUST abort any  security  association
  142.    setup that does not include an Identification Payload.
  143.  
  144. 4.2 OSPFv2 Security Protocol Identifiers
  145.  
  146.  
  147.       The ISAKMP proposal syntax was specifically designed to allow  for
  148.    the  simultaneous  negotiation  of  multiple security protocol suites
  149.    within a single negotiation.  As a result,  a  Protocol  ID  must  be
  150.    indicated. The size of this field is one octet.  The values 3-255 are
  151.    reserved to IANA.
  152.  
  153.           Protocol ID                         Value
  154.           -----------                         -----
  155.           RESERVED                              0
  156.           PROTO_ISAKMP                          1
  157.           PROTO_OSPFv2                          2
  158.  
  159. 4.3 PROTO_ISAKMP
  160.  
  161.       The PROTO_ISAKMP type specifies message protection required during
  162.    Phase  I  of  the ISAKMP protocol.  The specific protection mechanism
  163.    used for the OSPFv2 DOI is described in  [IO].   All  implementations
  164.    within the OSPFv2 DOI MUST support PROTO_ISAKMP.
  165.  
  166.  
  167.  
  168. Atkinson                  Expires in 6 months                   [Page 3]
  169.  
  170. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  171.  
  172.  
  173.       NB: ISAKMP reserves the value one (1) across all DOI definitions.
  174.  
  175. 4.3.1 PROTO_OSPFv2
  176.  
  177.       The  PROTO_OSPFv2   type   specifies   IP   packet   data   origin
  178.    authentication.   The  default  OSPFv2 transform includes data origin
  179.    authentication and replay prevention.
  180.  
  181. 4.4 OSPFv2 ISAKMP Transform Values
  182.  
  183.       As part of an ISAKMP Phase I negotiation, the  initiator's  choice
  184.    of  Key  Exchange  offerings  is  made  using some host system policy
  185.    description.  The actual selection of Key Exchange mechanism is  made
  186.    using  the  standard  ISAKMP  Proposal  Payload.  The following table
  187.    lists the defined  ISAKMP  Phase  I  Transform  Identifiers  for  the
  188.    Proposal Payload for the OSPFv2 DOI.
  189.  
  190.           Transform                           Value
  191.           ---------                           -----
  192.           RESERVED                            0
  193.           KEY_OAKLEY                          1
  194.  
  195.       The size of this  field  is  one  octet.   The  values  4-255  are
  196.    reserved to IANA.
  197.  
  198.       The KEY_OAKLEY type specifies  the  hybrid  ISAKMP/Oakley  Diffie-
  199.    Hellman   key   exchange  as  defined  in  the  [IO]  document.   All
  200.    implementations within the OSPFv2 DOI MUST support KEY_OAKLEY.  It is
  201.    anticipated  that  in future values will be assigned for Kerberos v5,
  202.    GKMP, and/or other protocols to handle  multicast  SA  creation  more
  203.    effectively.
  204.  
  205. 4.5  OSPFv2 Cryptographic Authentication Transform Values
  206.  
  207.       The OSPFv2 Cryptographic Authentication mechanism is  designed  to
  208.    be  algorithm-independent,  even  though only one algorithm transform
  209.    was been defined as of the  time  this  document  was  written.   The
  210.    following  table  lists  the  defined  OSPFv2 Cryptographic Transform
  211.    Identifiers for the ISAKMP Proposal Payload for the OSPFv2 DOI.
  212.  
  213.           Transform ID                        Value
  214.           ------------                        -----
  215.           RESERVED                            0
  216.           OSPFv2_MD5_KPDK                     1
  217.  
  218.       The size of this  field  is  one  octet.   The  values  4-255  are
  219.    reserved to IANA.
  220.  
  221.  
  222.  
  223.  
  224. Atkinson                  Expires in 6 months                   [Page 4]
  225.  
  226. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  227.  
  228.  
  229.       The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key)
  230.    described  in RFC-2178.  Implementations are required to support this
  231.    mode.
  232.  
  233. 4.6 OSPFv2 Security Association Attributes
  234.  
  235.       The following SA attribute definitions are used in phase II of  an
  236.    ISAKMP/Oakley  negotiation.   Attribute types can be either Basic (B)
  237.    or Variable-Length (V).  Encoding of these attributes is  defined  in
  238.    the base ISAKMP specification.
  239.  
  240.           Attribute Classes
  241.  
  242.                 class               value           type
  243.           -------------------------------------------------
  244.           Auth Key Life Type          1               B
  245.           Auth Key Life Duration      2               B/V
  246.           Enc Key Life Type           3               B
  247.           Enc Key Life Duration       4               B/V
  248.           SA Life Type                5               B
  249.           SA Life Duration            6               B/V
  250.           Replay Protection           7               B
  251.           Group Description           8               B
  252.           CA Distinguished Name       9               B
  253.           Encapsulation Mode          10              B
  254.  
  255.           Class Values
  256.  
  257.             Auth Key Life Type
  258.             Auth Key Duration
  259.               Specifies the time-to-live for the authentication key(s)
  260.               used in the corresponding AH HMAC transform.
  261.  
  262.             SA Life Type
  263.             SA Duration
  264.               Specifies the time-to-live for the overall security
  265.               association.  When the SA expires, all keys negotiated
  266.               under the association (AH or ESP) must be renegotiated
  267.               regardless of the time-to-live remaining for the keys.
  268.  
  269.               RESERVED                0
  270.               seconds                 1
  271.               kilobytes               2
  272.  
  273.               Values 3-61439 are reserved to IANA.  Values 61440-65535
  274.               are for experimental use.  For a given "Life Type," the
  275.               value of the "Life Duration" attribute defines the actual
  276.               length of the component lifetime -- either a number of
  277.  
  278.  
  279.  
  280. Atkinson                  Expires in 6 months                   [Page 5]
  281.  
  282. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  283.  
  284.  
  285.               seconds, or a number of Kbytes that can be protected.
  286.  
  287.               If unspecified, the default value shall be assumed to be
  288.               28800 seconds (8 hours) for Auth, Enc, and SA lifetime.
  289.  
  290.             Replay Protection
  291.               RESERVED                0
  292.               required                1
  293.               disallowed              2
  294.  
  295.               Values 3-61439 are reserved to IANA.  Values 61440-65535
  296.               are for private use among mutually consenting parties.
  297.  
  298.               There is no default value for Replay Protection, as it
  299.               must be specified to correctly identify the applicable
  300.               transform.
  301.  
  302.             Group Description
  303.               RESERVED                0
  304.               default group           1
  305.  
  306.               Values 2-61439 are reserved to IANA.  Values 61440-65535
  307.               are for private use among mutually consenting parties.
  308.  
  309.               If unspecified, the default value shall be assumed to be
  310.               the default Oakley group ([IO], Section 5.5.1).
  311.  
  312.             CA Distinguished Name
  313.               RESERVED                0
  314.               DNS Security            1
  315.  
  316.               Values 2-61439 are reserved to IANA.  Values 61440-65535
  317.               are for private use among mutually consenting parties.
  318.  
  319.               If unspecified, the default value shall be assumed to be
  320.               DNS Security (Section 4.8).
  321.  
  322.  
  323. 4.7.1 Required Attribute Support
  324.  
  325.       To ensure basic interoperability, all implementations MUST support
  326.    all of the following attributes:
  327.  
  328.               Auth Key Life Type
  329.               Auth Key Duration
  330.               SA Life Type
  331.               SA Duration
  332.               Replay Protection
  333.  
  334.  
  335.  
  336. Atkinson                  Expires in 6 months                   [Page 6]
  337.  
  338. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  339.  
  340.  
  341. 4.7.2 Attribute List Parsing Requirement
  342.  
  343.       To allow for flexible semantics, the OSPFv2 DOI  requires  that  a
  344.    conforming  ISAKMP  implementation  MUST correctly parse an attribute
  345.    list that contains multiple instances of the same attribute class, so
  346.    long  as  the  different  attribute  entries do not conflict with one
  347.    another.
  348.  
  349.       If  conflicting  attributes  are  detected,   an   ATTRIBUTES-NOT-
  350.    SUPPORTED  Notification  Payload  SHOULD be returned and the security
  351.    association setup MUST be aborted.
  352.  
  353. 4.8 OSPFv2 Payload Content
  354.  
  355.       The following sections describe those ISAKMP payloads  whose  data
  356.    representations are dependent on the applicable DOI.
  357.  
  358. 4.8.1 Security Association Payload
  359.  
  360.       The following diagram illustrates  the  content  of  the  Security
  361.    Association  Payload for the OSPFv2 DOI.  See above for a description
  362.    of the Situation bitmap.
  363.  
  364.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  365.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.       |  Next Payload |   RESERVED    |        Payload Length         |
  367.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.       |                Domain of Interpretation (OSPFv2)              |
  369.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  370.       |                       Situation (bitmap)                      |
  371.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  372.  
  373.                   Figure 1: Security Association Payload Format
  374.  
  375.    The Security Association Payload is defined as follows:
  376.  
  377.         o  Next Payload (2 octets) - Identifier for the payload type of
  378.            the next payload in the message.  If the current payload is
  379.            the last in the message, this field will be zero (0).
  380.  
  381.         o  RESERVED (1 octet) - Unused, must be zero (0).
  382.  
  383.         o  Payload Length (2 octets) - Length, in octets, of the current
  384.            payload, including the generic header.
  385.  
  386.         o  Domain of Interpretation (4 octets) - Specifies the OSPFv2 DOI,
  387.            which has been assigned the value <To Be Assigned by IANA>.
  388.  
  389.  
  390.  
  391.  
  392. Atkinson                  Expires in 6 months                   [Page 7]
  393.  
  394. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  395.  
  396.  
  397.         o  Situation (4 octets) - Bitmask used to interpret the
  398.            remainder of the Security Association Payload.  See Section
  399.            4.2 for a complete list of values.
  400.  
  401.  
  402. 4.8.2 Identification Payload Content
  403.  
  404.       The Identification Payload is used to identify  the  initiator  of
  405.    the  Security  Association.   The identity of the initiator SHOULD be
  406.    used by the responder to determine the correct host  system  security
  407.    policy requirement for the association.  Typically, OSPF sessions use
  408.    an identity that is either an IP Address or a Fully Qualified  Domain
  409.    Name (FQDN).
  410.  
  411.      The Identification Payload provides information that can be used by
  412.    the responder to make this decision.
  413.  
  414.      The following diagram illustrates the content of the Identification
  415.    Payload.
  416.  
  417.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  418.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.       |  Next Payload |    ID Type    |        Payload Length         |
  420.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.       ~                     Identification Data                       ~
  422.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  423.  
  424.                      Figure 2: Identification Payload Format
  425.  
  426.    The Identification Payload field is defined as follows:
  427.  
  428.         o  Next Payload (2 octets) - Identifier for the payload type of
  429.            the next payload in the message.  If the current payload is
  430.            the last in the message, this field will be zero (0).
  431.  
  432.         o  Identification Type (1 octet) - Value describing the
  433.            identity information found in the Identification Data field.
  434.  
  435.         o  Payload Length (2 octets) - Length, in octets, of the
  436.            identification data, including the generic header.
  437.  
  438. 4.8.2.1 Identification Type Values
  439.  
  440.       The  following  table  lists   the   assigned   values   for   the
  441.    Identification Type field found in the Identification Payload.
  442.  
  443.           ID Type                             Value
  444.           -------                             -----
  445.  
  446.  
  447.  
  448. Atkinson                  Expires in 6 months                   [Page 8]
  449.  
  450. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  451.  
  452.  
  453.           RESERVED                            0
  454.           ID_IPV4_ADDR                        1
  455.           ID_IPV6_ADDR                        2
  456.           ID_FQDN                             3
  457.           ID_USER_FQDN                        4
  458.  
  459.    The size of this field is one octet.  The values 5-255  are  reserved
  460.    to IANA.
  461.  
  462.    The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
  463.  
  464.    The ID_IPV4_ADDR type specifies a  single  sixteen  (16)  octet  IPv6
  465.    address.
  466.  
  467.    The ID_FQDN type specifies a fully-qualified domain name string.   An
  468.    example of a ID_FQDN is, "foo.bar.com".
  469.  
  470.    The ID_USER_FQDN type specifies a fully-qualified username string, An
  471.    example of a ID_USER_FQDN is, "john-doe@foo.bar.com".
  472.  
  473. 4.9 OSPFv2 Security Parameter Index (SPI) Encoding
  474.  
  475.       ISAKMP defines the SPI field as eight octets  in  length,  however
  476.    the  OSPFv2  Cryptographic  Authentication  only uses a one octet Key
  477.    Identifier.  All implementations MUST use the following  mapping  for
  478.    the ISAKMP SPI field in the OSPFv2 DOI.
  479.  
  480.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  481.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  482.       |    KEY ID     |   RESERVED MUST BE ZERO                       |
  483.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.       |                   RESERVED MUST BE ZERO                       |
  485.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  486.  
  487.                           Figure 3: ISAKMP SPI Encoding
  488.  
  489.    The ISAKMP SPI field is defined as follows:
  490.  
  491.         o  KEY ID - Key Identifier (1 octet) - contains the
  492.            KEY ID value which identifies the OSPFv2 Authentication Key.
  493.  
  494.         o  RESERVED (7 octets) - Reserved for future use,
  495.                                    must be sent as zero (0) and
  496.                                    ignored upon receipt.
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504. Atkinson                  Expires in 6 months                   [Page 9]
  505.  
  506. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  507.  
  508.  
  509. 4.8 OSPFv2 Certificate Authorities
  510.  
  511.            The ISAKMP Certificate Request Payload allows either side  of
  512.    an  ISAKMP  negotiation  to request its peer to provide a certificate
  513.    chain needed to authenticate itself.  The Certificate Request Payload
  514.    includes  a  list  of  acceptable  Certificate  Types and Certificate
  515.    Authorities.  Appropriate certificate chains are then returned  in  a
  516.    Certificate Payload response.
  517.  
  518.            The OSPFv2 DOI defines the following Certificate  Authorities
  519.    for  the processing of Certificate Request Payloads.  See Section 4.5
  520.    for details on the specific data attribute type values for these CAs.
  521.  
  522.           Certificate Authority
  523.           ---------------------
  524.           DNS Security
  525.  
  526. 4.8.1 DNS Security
  527.  
  528.       This CA type represents the combination of KEY and SIG records, as
  529.    defined  in  RFC-2065,  that  can  be  used  for authentication.  The
  530.    particular encoding required to  formulate  the  Certificate  Payload
  531.    (response) is TBD.
  532.  
  533. 4.9 OSPFv2 Key Exchange Requirements
  534.  
  535.            The OSPFv2 DOI introduces no additional Key Exchange types.
  536.  
  537. 5. Security Considerations
  538.  
  539.            This entire note pertains to  a  hybrid  protocol,  combining
  540.    Oakley  ([OAKLEY])  with  ISAKMP  ([ISAKMP]), to negotiate and derive
  541.    keying  material  for  security  associations   in   a   secure   and
  542.    authenticated  manner.   Specific  discussion of the various security
  543.    protocols and transforms identified in this document can be found  in
  544.    the associated base documents.
  545.  
  546.            This document describes the additional data needed  to  apply
  547.    the  ISAKMP  protocol  for use in managing OSPFv2 Authentication Keys
  548.    and  related  data.    Implementers   should   consult   the   OSPFv2
  549.    specification   for   more   information   on   OSPFv2  Cryptographic
  550.    Authentication.
  551.  
  552. ACKNOWLEDGEMENTS:
  553.  
  554.       This document is directly derived from the "IP  Security  DOI  for
  555.    ISAKMP" by Derrell Piper.  That document is in turn derived, in part,
  556.    from  previous  works  by  Douglas  Maughan,  Mark  Schertler,   Mark
  557.  
  558.  
  559.  
  560. Atkinson                  Expires in 6 months                  [Page 10]
  561.  
  562. Internet Draft            OSPF DOI for ISAKMP            15 October 1997
  563.  
  564.  
  565.    Schneider, Jeff Turner, Dan Harkins, and Dave Carrel.
  566.  
  567. REFERENCES:
  568.  
  569.  
  570.    [RFC-2065] D. Eastlake 3rd & C. Kaufman, "Domain Name System Security
  571.    Extensions (DNSSEC)", RFC-2065, January 1997.
  572.  
  573.    [RFC-2178] J. Moy, "OSPF Version 2", RFC-2178, July 1997.
  574.  
  575.    [IO] D. Carrel & D. Harkins, "The Resolution of ISAKMP with Oakley,"
  576.    draft-ietf-ipsec-isakmp-oakley-03.txt.
  577.  
  578.    [ISAKMP] D. Maughan, M. Schertler, M. Schneider, & J. Turner,
  579.    "Internet Security Association and Key Management Protocol (ISAKMP),"
  580.    draft-ietf-ipsec-isakmp-07.{ps,txt}.
  581.  
  582.    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
  583.    draft-ietf-ipsec-oakley-01.txt.
  584.  
  585.    [PFKEY] D.L. McDonald, C.W. Metz, B.G. Phan, "PF_KEY Key Management API,
  586.    Version 2", draft-mcdonald-pf-key-v2-01.txt, work in progress.
  587.  
  588.  
  589. Editor's Address:
  590.  
  591.            Randall Atkinson        <rja@home.net>
  592.            @Home Network
  593.            425 Broadway Street
  594.            Redwood City, CA,
  595.            USA 94063
  596.  
  597.            +1 (650) 569-5449
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616. Atkinson                  Expires in 6 months                  [Page 11]
  617.  
  618.