Network Working Group                                 R. Atkinson, Editor
Internet Draft                                              @Home Network
draft-ietf-rip-doi-00.txt                                 14 October 1997




            RIPv2 Domain Of Interpretation (DOI) for ISAKMP





STATUS OF THIS MEMO

      This document is an Internet Draft. Internet  Drafts  are  working
   documents  of  the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note  that  other  groups  may  also  distribute
   working documents as Internet Drafts.

      Internet Drafts are draft documents valid for  a  maximum  of  six
   months  and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet Drafts as  reference
   material or to cite them other than as ``work in progress.''

      To learn the current status of any Internet  Draft,  please  check
   the  ``1id-abstracts.txt''  listing  contained in the Internet Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net  (Europe),
   munnari.oz.au   (Australia),  ds.internic.net  (US  East  Coast),  or
   ftp.isi.edu (US West Coast).

      Distribution of this memo is unlimited. This draft will expire six
   months from date of issue.





   1. Abstract

      The Internet Security  Association  and  Key  Management  Protocol
   (ISAKMP)  defines a framework for security association management and
   cryptographic key establishment for  the  Internet.   This  framework
   consists  of  defined  exchanges and processing guidelines that occur
   within a given Domain of Interpretation (DOI).  This document details
   the  RIPv2  DOI,  which  is  defined  to  cover  the use of ISAKMP to
   negotiate Security Associations for the RIPv2 routing protocol.




Atkinson                  Expires in 6 months                   [Page 1]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


2. Introduction

      Within ISAKMP, a Domain of Interpretation is used to group related
   protocols  using ISAKMP to negotiate security associations.  Security
   protocols sharing a DOI choose security  protocol  and  cryptographic
   transforms  from  a  common namespace and share key exchange protocol
   identifiers.  They also share a common interpretation of DOI-specific
   payload   data   content,  including  the  Security  Association  and
   Identification payloads.

      Overall,  ISAKMP  places  the  following  requirements  on  a  DOI
   definition:

        o  define the naming scheme for DOI-specific protocol identifiers
        o  define the interpretation for the Situation field
        o  define the set of applicable security policies
        o  define the syntax for DOI-specific SA Attributes (phase II)
        o  define the syntax for DOI-specific payload contents
        o  define additional mappings or Key Exchange types, if needed

      The remainder of this document details the instantiation of  these
   requirements   for   using  the  RIPv2  cryptographic  authentication
   mechanism to provide data origin  authentication  for  RIPv2  routing
   packets sent between cooperating routers.





3. Terms and Definitions

      In  this  document,  the  words  that  are  used  to  define   the
   significance  of each particular requirement are usually capitalised.
   These words are defined in RFC-xxxx,  which  is  hereby  incorporated
   into this document by reference. [RFC-xxxx]

      Within ISAKMP, all DOI's must be registered with the IANA  in  the
   ``Assigned  Numbers''  RFC [STD-2].  The IANA Assigned Number for the
   RIPv2 DOI is <TO BE ASSIGNED BY IANA>.  Within  the  RIPv2  DOI,  all
   well-known  identifiers  MUST  be  registered with the IANA under the
   RIPv2 DOI.  Unless otherwise noted, all tables within  this  document
   refer to IANA Assigned Numbers for the RIPv2 DOI.

4. Assigned Numbers

      The following sections list the Assigned Numbers for the RIPv2 DOI
   Security  Protocol  Identifiers,  Transform Identifiers, and Security
   Association Attribute Types.  Note that all multi-octet binary values



Atkinson                  Expires in 6 months                   [Page 2]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


   are stored in network byte order.

4.1 RIPv2 Situation Definition

      Within ISAKMP, the Situation provides information that can be used
   by  the responder to make a policy determination about how to process
   the incoming Security Association request.  For the  RIPv2  DOI,  the
   Situation  field  is  a  four  (4)  octet  bitmask with the following
   values.

          Situation                   Value
          ---------                   -----
          SIT_AUTHENTICATION          0x01


      All other values are reserved to IANA.

      The  SIT_AUTHENTICATION   type   specifies   that   the   security
   association will be identified by source identity information present
   in an associated Identification Payload.  See  Section  4.6.2  for  a
   complete  description of the various Identification types.  All RIPv2
   DOI implementations MUST support SIT_AUTHENTICATION by  including  an
   Identification  Payload  in  at  least  one  of  the  phase  I Oakley
   exchanges ([IO], Section 5) and MUST abort any association setup that
   does not include an Identification Payload.

4.2 RIPv2 Security Protocol Identifiers


      The ISAKMP proposal syntax was specifically designed to allow  for
   the  simultaneous  negotiation  of  multiple security protocol suites
   within a single negotiation.  As a result,  a  Protocol  ID  must  be
   indicated.  The RIPv2 DOI only contains a single operational Protocol
   ID.  The size of this field is  one  octet.   The  values  2-255  are
   reserved to IANA.

          Protocol ID                         Value
          -----------                         -----
          RESERVED                            0
          PROTO_ISAKMP                        1
          PROTO_RIPv2                         2

4.3 PROTO_ISAKMP

      The PROTO_ISAKMP type specifies message protection required during
   Phase  I  of  the ISAKMP protocol.  The specific protection mechanism
   used for the RIPv2 DOI is described  in  [IO].   All  implementations
   within the RIPv2 DOI MUST support PROTO_ISAKMP.



Atkinson                  Expires in 6 months                   [Page 3]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


      NB: ISAKMP reserves the value one (1) across all DOI definitions.

4.3.1 PROTO_RIPv2

      The   PROTO_RIPv2   type   specifies   IP   packet   data   origin
   authentication.    The   default   transform   includes  data  origin
   authentication   and   replay   prevention.    For   export   control
   considerations,   confidentiality   MUST   NOT  be  provided  by  any
   PROTO_RIPv2_AH transform.

4.4 RIPv2 ISAKMP Transform Values

      As part of an ISAKMP Phase I negotiation, the  initiator's  choice
   of  Key  Exchange  offerings  is  made  using some host system policy
   description.  The actual selection of Key Exchange mechanism is  made
   using  the  standard  ISAKMP  Proposal  Payload.  The following table
   lists the defined  ISAKMP  Phase  I  Transform  Identifiers  for  the
   Proposal Payload for the RIPv2 DOI.

          Transform                           Value
          ---------                           -----
          RESERVED                            0
          KEY_OAKLEY                          1

      The size of this  field  is  one  octet.   The  values  4-255  are
   reserved to IANA.

      The KEY_OAKLEY type specifies  the  hybrid  ISAKMP/Oakley  Diffie-
   Hellman   key   exchange  as  defined  in  the  [IO]  document.   All
   implementations within the RIPv2 DOI MUST support KEY_OAKLEY.  It  is
   anticipated   that   in   future   values   will   be   assigned  for
   KEY_KERBEROS_V5  and  KEY_GKMP  to  handle  multicast  sessions  more
   effectively.

4.5  RIPv2 Cryptographic Authentication Transform Values

      The RIPv2 Cryptographic Authentication mechanism is designed to be
   algorithm-independent,  even  though only one algorithm transform was
   been defined as of the time this document was written.  The following
   table lists the defined RIPv2 Cryptographic Transform Identifiers for
   the ISAKMP Proposal Payload for the RIPv2 DOI.

          Transform ID                        Value
          ------------                        -----
          RESERVED                              0
          RIPv2_MD5_KPDK                        1
          RIPv2_SHA_KPDK                        2




Atkinson                  Expires in 6 months                   [Page 4]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


      The size of this  field  is  one  octet.   The  values  4-255  are
   reserved to IANA.

      The  RIPv2_MD5_KPDK  type  specifies   the   MD5-based   transform
   (Key/Pad/Data/Key)  described  in  RFC-2082.  The RIPv2_SHA_KPDK type
   specifies the SHA1-based transform described in  [Son  of  RFC-2082].
   All   implementations   of   this   specification  MUST  support  the
   RIPv2_MD5_KPDK type.  Implementations of  this  specification  SHOULD
   also support the RIPv2_SHA_KPDK type.

4.6 RIPv2 Security Association Attributes

      The following SA attribute definitions are used in phase II of  an
   ISAKMP/Oakley  negotiation.   Attribute types can be either Basic (B)
   or Variable-Length (V).  Encoding of these attributes is  defined  in
   the base ISAKMP specification.

          Attribute Classes

                class               value           type
          -------------------------------------------------
          Auth Key Life Type          1               B
          Auth Key Life Duration      2               B/V
          SA Life Type                5               B
          SA Life Duration            6               B/V
          Replay Protection           7               B
          Group Description           8               B
          CA Distinguished Name       9               B
          HMAC Algorithm              11              B

          Class Values

            Auth Key Life Type
            Auth Key Duration
              Specifies the time-to-live for the authentication key(s)
              used in the corresponding AH HMAC transform.

            SA Life Type
            SA Duration
              Specifies the time-to-live for the RIPv2 Security
              Association.  When the SA expires, a new RIPv2 SA
              must be established to replace the first SA.

              RESERVED                0
              seconds                 1
              kilobytes               2

              Values 3-61439 are reserved to IANA.  Values 61440-65535



Atkinson                  Expires in 6 months                   [Page 5]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


              are for experimental use.  For a given "Life Type," the
              value of the "Life Duration" attribute defines the actual
              length of the component lifetime -- either a number of
              seconds, or a number of Kbytes that can be protected.

              If unspecified, the default value shall be assumed to be
              28800 seconds (8 hours) for Auth, Enc, and SA lifetime.

            Replay Protection
              RESERVED                0
              required                1
              disallowed              2

              Values 3-61439 are reserved to IANA.  Values 61440-65535
              are for private use among mutually consenting parties.

              There is no default value for Replay Protection, as it
              must be specified to correctly identify the applicable
              transform.

            Group Description
              RESERVED                0
              default group           1

              Values 2-61439 are reserved to IANA.  Values 61440-65535
              are for private use among mutually consenting parties.

              If unspecified, the default value shall be assumed to be
              the default Oakley group ([IO], Section 5.5.1).

            CA Distinguished Name
              RESERVED                0
              DNS Security            1

              Values 2-61439 are reserved to IANA.  Values 61440-65535
              are for private use among mutually consenting parties.

              If unspecified, the default value shall be assumed to be
              DNS Security (Section 4.8).

            HMAC Algorithm
              RESERVED                0
              MD5                     1
              SHA-1                   2

              Values 3-61439 are reserved to IANA.  Values 61440-65535
              are for private use among mutually consenting parties.




Atkinson                  Expires in 6 months                   [Page 6]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


              There is no default value for HMAC Algorithm, as it
              must be specified to correctly identify the applicable
              transform.


4.7.1 Required Attribute Support

      To ensure basic interoperability, all implementations MUST support
   all of the following attributes:

              Auth Key Life Type
              Auth Key Duration
              SA Life Type
              SA Duration
              Replay Protection
              HMAC Algorithm (MD5 required, SHA-1 optional)

4.7.2 Attribute List Parsing Requirement

      To allow for flexible semantics, the RIPv2  DOI  requires  that  a
   conforming  ISAKMP  implementation  MUST correctly parse an attribute
   list that contains multiple instances of the same attribute class, so
   long  as  the  different  attribute  entries do not conflict with one
   another.

      If  conflicting  attributes  are  detected,   an   ATTRIBUTES-NOT-
   SUPPORTED  Notification  Payload  SHOULD be returned and the security
   association setup MUST be aborted.

4.8 RIPv2 Payload Content

      The following sections describe those ISAKMP payloads  whose  data
   representations are dependent on the applicable DOI.

4.8.1 Security Association Payload

      The following diagram illustrates  the  content  of  the  Security
   Association  Payload  for the RIPv2 DOI.  See above for a description
   of the Situation bitmap.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Payload |   RESERVED    |        Payload Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Domain of Interpretation (RIPv2)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Situation (bitmap)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Atkinson                  Expires in 6 months                   [Page 7]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


                  Figure 1: Security Association Payload Format

   The Security Association Payload is defined as follows:

        o  Next Payload (2 octets) - Identifier for the payload type of
           the next payload in the message.  If the current payload is
           the last in the message, this field will be zero (0).

        o  RESERVED (1 octet) - Unused, must be zero (0).

        o  Payload Length (2 octets) - Length, in octets, of the current
           payload, including the generic header.

        o  Domain of Interpretation (4 octets) - Specifies the RIPv2 DOI,
           which has been assigned the value <To be assigned by IANA>.

        o  Situation (4 octets) - Bitmask used to interpret the
           remainder of the Security Association Payload.  See Section
           4.2 for a complete list of values.


4.8.2 Identification Payload Content

      The Identification Payload is used to identify  the  initiator  of
   the  Security  Association.   The identity of the initiator SHOULD be
   used by the responder to determine the correct host  system  security
   policy  requirement  for  the association.  Typically, RIPv2 sessions
   use an identity that is either an IP Address  or  a  Fully  Qualified
   Domain Name (FQDN).

     The Identification Payload provides information that can be used by
   the responder to make this decision.

     The following diagram illustrates the content of the Identification
   Payload.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Payload |   ID Type     |        Payload Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     Identification Data                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: Identification Payload Format

   The Identification Payload field is defined as follows:

        o  Next Payload (2 octets) - Identifier for the payload type of



Atkinson                  Expires in 6 months                   [Page 8]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


           the next payload in the message.  If the current payload is
           the last in the message, this field will be zero (0).

        o  RESERVED (1 octet) - Unused, must be zero (0).

        o  Payload Length (2 octets) - Length, in octets, of the
           identification data, including the generic header.

        o  Identification Type (1 octet) - Value describing the
           identity information found in the Identification Data field.

        o  RESERVED (1 octet) - Unused, must be zero (0).

4.8.2.1 Identification Type Values

      The  following  table  lists   the   assigned   values   for   the
   Identification Type field found in the Identification Payload.

          ID Type                             Value
          -------                             -----
          RESERVED                            0
          ID_IPV4_ADDR                        1
          ID_IPV6_ADDR                        2
          ID_FQDN                             3
          ID_USER_FQDN                        4

   The size of this field is one octet.  The values 5-255  are  reserved
   to IANA.

   The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.

   The ID_IPV4_ADDR type specifies a  single  sixteen  (16)  octet  IPv6
   address.

   The ID_FQDN type specifies a fully-qualified domain name string.   An
   example of a ID_FQDN is, "foo.bar.com".

   The ID_USER_FQDN type specifies a fully-qualified username string, An
   example of a ID_USER_FQDN is, "john-doe@foo.bar.com".

4.9 RIPv2 Security Parameter Index (SPI) Encoding

      ISAKMP defines the SPI field as eight octets  in  length,  however
   the  RIPv2  Cryptographic  Authentication  only  uses a one octet Key
   Identifier.  All implementations MUST use the following  mapping  for
   the ISAKMP SPI field in the RIPv2 DOI.

       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



Atkinson                  Expires in 6 months                   [Page 9]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    KEY ID     |   RESERVED MUST BE ZERO                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   RESERVED MUST BE ZERO                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3: ISAKMP SPI Encoding

   The ISAKMP SPI field is defined as follows:

        o  KEY ID - Key Identifier (1 octet) - contains the
           KEY ID value which identifies the RIPv2 Authentication Key.

        o  RESERVED (7 octets) - Reserved for future use,
                                   must be sent as zero (0) and
                                   ignored upon receipt.

4.8 RIPv2 Certificate Authorities

           The ISAKMP Certificate Request Payload allows either side  of
   an  ISAKMP  negotiation  to request its peer to provide a certificate
   chain needed to authenticate itself.  The Certificate Request Payload
   includes  a  list  of  acceptable  Certificate  Types and Certificate
   Authorities.  Appropriate certificate chains are then returned  in  a
   Certificate Payload response.

           The RIPv2 DOI defines the following  Certificate  Authorities
   for  the processing of Certificate Request Payloads.  See Section 4.5
   for details on the specific data attribute type values for these CAs.

          Certificate Authority
          ---------------------
          DNS Security

4.8.1 DNS Security

      This CA type represents the combination of KEY and SIG records, as
   defined  in  [RFC-2065],  that  can  be used for authentication.  The
   particular encoding required to  formulate  the  Certificate  Payload
   (response) is TBD.

4.9 RIPv2 Key Exchange Requirements

           The RIPv2 DOI introduces no additional Key Exchange types.







Atkinson                  Expires in 6 months                  [Page 10]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


5. Security Considerations

           This entire note pertains to  a  hybrid  protocol,  combining
   Oakley  ([OAKLEY])  with  ISAKMP  ([ISAKMP]), to negotiate and derive
   keying  material  for  security  associations   in   a   secure   and
   authenticated  manner.   Specific  discussion of the various security
   protocols and transforms identified in this document can be found  in
   the associated base documents.

           This document describes the additional data needed  to  apply
   the ISAKMP protocol for use in managing RIPv2 Authentication Keys and
   related data.  Implementers should consult  the  RIPv2  specification
   for more information on RIPv2 Cryptographic Authentication.

ACKNOWLEDGEMENTS:

      This document is directly derived from the "IP  Security  DOI  for
   ISAKMP" by Derrell Piper.  That document is in turn derived, in part,
   from  previous  works  by  Douglas  Maughan,  Mark  Schertler,   Mark
   Schneider, Jeff Turner, Dan Harkins, and Dave Carrel.

REFERENCES:


   [RFC-2065] D. Eastlake 3rd & C. Kaufman, "Domain Name System Security
   Extensions (DNSSEC)", RFC-2065, January 1997.

   [RFC-2082] F. Baker & R. Atkinson, "RIPv2 MD5 Authentication",
   RFC-2082, January 1997.

   [IO] D. Carrel & D. Harkins, "The Resolution of ISAKMP with Oakley,"
   draft-ietf-ipsec-isakmp-oakley-03.txt.

   [ISAKMP] D. Maughan, M. Schertler, M. Schneider, & J. Turner,
   "Internet Security Association and Key Management Protocol (ISAKMP),"
   draft-ietf-ipsec-isakmp-07.{ps,txt}.

   [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
   draft-ietf-ipsec-oakley-01.txt.

   [PFKEY] D.L. McDonald, C.W. Metz, B.G. Phan, "PF_KEY Key Management API,
   Version 2", draft-mcdonald-pf-key-v2-01.txt, work in progress.


Editor's Address:

           Randall Atkinson        <rja@home.net>
           @Home Network



Atkinson                  Expires in 6 months                  [Page 11]


Internet Draft            RIPv2 DOI for ISAKMP           14 October 1997


           425 Broadway Street
           Redwood City, CA,
           USA 94063

           +1 (650) 569-5449














































Atkinson                  Expires in 6 months                  [Page 12]