home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-doc-roadmap-00.txt < prev    next >
Text File  |  1997-07-02  |  20KB  |  558 lines
  1.  
  2.  
  3. Network  Working Group                                        R. Thayer
  4. Internet Draft                                             N. Doraswamy
  5. Category: Informational                                        R. Glenn
  6. Expire in six months                                          July 1997
  7.  
  8.  
  9.                               IP Security
  10.                             Document Roadmap
  11.                  <draft-ietf-ipsec-doc-roadmap-00.txt>
  12.  
  13.  
  14.  
  15.  
  16. Status of This Memo
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34.    This memo provides information for the Internet community.  This memo
  35.    does not specify an Internet standard.  Distribution of this memo is
  36.    unlimited.
  37.  
  38. Abstract
  39.  
  40.    The IPsec protocol suite is used to provide privacy and
  41.    authentication services at the IP layer.  Several documents are used
  42.    to describe this protocol suite.  The interrelationship and
  43.    organization of the various documents covering the IPsec protocol are
  44.    discussed here.  An explanation of what to find in which document,
  45.    and what to include in new Cipher and Authenticator documents are
  46.    described.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60. Thayer, Doraswamy, Glenn                                        [Page 1]
  61.  
  62. INTERNET DRAFT                  July 1997           Expires January 1998
  63.  
  64.  
  65. Contents
  66.  
  67.    Status of This Memo .................................................1
  68.  
  69.    Abstract ............................................................1
  70.  
  71.    Contents ............................................................2
  72.  
  73.    1. Introduction .....................................................3
  74.  
  75.    2. Interrelationship of IPsec Documents .............................3
  76.  
  77.    3. Keying Material ..................................................5
  78.  
  79.    4. Recommended Content of Cipher and Authenticator Documents ........5
  80.  
  81.    4.1 Cipher and Authenticator ........................................5
  82.    4.2 Cipher ..........................................................6
  83.    4.3 Authenticator ...................................................7
  84.  
  85.    5. Security Considerations ..........................................8
  86.  
  87.    6. Acknowledgments ..................................................8
  88.  
  89.    7. References .......................................................9
  90.  
  91.    8. Author's Addresses ...............................................9
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Thayer, Doraswamy, Glenn                                        [Page 2]
  123.  
  124. INTERNET DRAFT                  July 1997           Expires January 1998
  125.  
  126.  
  127. 1. Introduction
  128.  
  129.    This document is intended to provide guidelines for the development
  130.    of collateral specifications describing the use of new Cipher and
  131.    Authenticator algorithms with the ESP protocol, described in [ESP]
  132.    and new Authenticator algorithms used with the AH protocol, described
  133.    in [AH].  ESP and AH are part of the IP Security architecture
  134.    described in [Arch].  There is a requirement for a well-known
  135.    procedure that can be used to add new cipher algorithms or
  136.    authenticator algorithms to ESP and AH, not only while the initial
  137.    document set is undergoing development but after the base documents
  138.    have achieved RFC status.  Following the guidelines discussed below
  139.    simplifies adding new algorithms and reduces that amount of redundant
  140.    documentation.
  141.  
  142.    The goal in writing a new ESP or AH algorithm document is to
  143.    concentrate on the application of the specific algorithm.  General
  144.    ESP and AH concepts, definitions, and issues are covered in the ESP
  145.    and AH documents. The algorithms themselves are not described in
  146.    these documents.  This gives us the capability to add new algorithms
  147.    and also specify how any given algorithm might interact with other
  148.    algorithms. The intent is to achieve the goal of avoiding duplication
  149.    of information and excessive numbers of documents, the so-called
  150.    "draft explosion" effect.
  151.  
  152. 2. Interrelationship of IPsec Documents
  153.  
  154.    The documents describing the set of IPsec protocols are divided into
  155.    seven groups.  This is illustrated in Figure 1.  There is a main
  156.    Architecture document which broadly covers the general concepts,
  157.    security requirements, definitions, and mechanisms defining IPsec
  158.    technology.
  159.  
  160.    There is an ESP Protocol document and an AH Protocol document which
  161.    covers the packet format and general issues regarding the respective
  162.    protocols.  These protocol documents also contain default values if
  163.    appropriate, such as the default padding contents, and mandatory to
  164.    implement algorithms.  These documents dictate some of the values in
  165.    the Domain Of Interpretation document [DOI].  Note the DOI document
  166.    is itself part of the IANA Assigned Numbers mechanism and so the
  167.    values described in the DOI are well-known.  See [DOI] for more
  168.    information on the mechanism.
  169.  
  170.    The "Cipher" document set, shown on the left, is the set of documents
  171.    describing how various ciphers are used for ESP.  These documents are
  172.    intended to fit in this roadmap, and should avoid overlap with the
  173.    ESP protocol document and with the Authenticator documents.  Examples
  174.    of this document are the [DES-1829], [DES-Detroit], [3DES], or [CAST]
  175.    documents.  When these or other Ciphers are used for ESP, the DOI
  176.    document has to indicate certain values, such as Cipher type, so
  177.    these documents provide input to the DOI.
  178.  
  179.    The "Authenticator" document set, shown on the right, is the set of
  180.    documents describing how various authenticator algorithms are used
  181.  
  182.  
  183.  
  184. Thayer, Doraswamy, Glenn                                        [Page 3]
  185.  
  186. INTERNET DRAFT                  July 1997           Expires January 1998
  187.  
  188.  
  189.    for both ESP and AH.  These documents are intended to fit in this
  190.    roadmap, and should avoid overlap with the AH protocol document and
  191.    with the Cipher documents.  Examples of this document are the [HMAC-
  192.    MD5], and [HMAC-SHA-1] documents.  When these or other algorithms are
  193.    used for either ESP or AH, the DOI document has to indicate certain
  194.    values, such as algorithm type, so these documents provide input to
  195.    the DOI.
  196.  
  197.    The "Key Management Documents", shown at the bottom, are the
  198.    documents describing the IETF standards-track key management schemes.
  199.    These documents provide certain values for the DOI also.  Note that
  200.    issues of key management should be indicated here and not in, for
  201.    example, the ESP and AH protocol documents.  Currently this box
  202.    represents [ISAKMP], [Oakley], and [Resolution].
  203.  
  204.    The DOI document, shown in the middle, contains values needed for the
  205.    other documents to relate to each other.  This includes for example
  206.    Cipher algorithms, Authenticator algorithms, and operational
  207.    parameters such as key lifetimes.
  208.  
  209.  
  210.                       +--------------+
  211.                       | Architecture |
  212.                       +--------------+
  213.                         v          v
  214.                +<-<-<-<-+          +->->->->+
  215.                v                            v
  216.       +----------+                       +----------+
  217.       |   ESP    |                       |    AH    |
  218.       | PROTOCOL |                       | PROTOCOL |
  219.       +----------+                       +----------+
  220.         v      v                           v       v
  221.         v      +->->->->->->->->+          v       v
  222.         v      v                v          v       v
  223.         v      v                v          v       v
  224.         v  +--------+       +---------------+      v
  225.         v  | +--------+     | +---------------+    v
  226.         v  | |        |     | |               |    v
  227.         v  +-| Cipher |     +-| Authenticator |    v
  228.         v    +--------+       +---------------+    v
  229.         v        v                       v         v
  230.         v        v        +-----+        v         v
  231.         +>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+
  232.                           +-----+
  233.                              ^
  234.                              ^
  235.                        +------------+
  236.                        |    KEY     |
  237.                        | MANAGEMENT |
  238.                        +------------+
  239.  
  240.  
  241.               Figure 1. IPsec Document Roadmap.
  242.  
  243.  
  244.  
  245.  
  246. Thayer, Doraswamy, Glenn                                        [Page 4]
  247.  
  248. INTERNET DRAFT                  July 1997           Expires January 1998
  249.  
  250.  
  251. 3. Keying Material
  252.  
  253.    Describing the cipher and authenticator algorithms in different docu-
  254.    ments raises the issue of how the key management protocols knows the
  255.    required keying material length for the desired algorithms when used
  256.    together with ESP.  It also raises the issue of how to divide the
  257.    keying material.  This is known as the "slicing and dicing" informa-
  258.    tion.
  259.  
  260.    Each cipher and authenticator document should specify their respec-
  261.    tive key lengths. The key management protocols should use the length
  262.    of the keys specified in the cipher and authenticator documents to
  263.    generate the keying material of required length.
  264.  
  265.    The ESP protocol document is responsible for specifying how the keys
  266.    are extracted from the keying material (sliced and diced).  For exam-
  267.    ple, it should specify if the cipher or the authenticator algorithm
  268.    uses the first n-bits in the provided keying material.  The AH proto-
  269.    col document has no such requirement.  [Editor's Note: This paragraph
  270.    is still under contention and will be modified once the location of
  271.    the key derivation mechanism is known].
  272.  
  273. 4. Recommended Content of Cipher and Authenticator Documents
  274.  
  275.    The document describing how a specific cipher or authenticator is
  276.    used should contain information appropriate to that cipher or authen-
  277.    ticator.  This section enumerates what information should be pro-
  278.    vided.  It is the intention of the document roadmap that:
  279.  
  280.    .  General protocol information goes in the respective ESP or AH protocol
  281.       documents.
  282.    .  Key management information goes in the key management documents.
  283.    .  Assigned values and constants go in the DOI document.
  284.  
  285.   Cipher and Authenticator algorithms require some set of optional
  286.   parameters or have optional modes of operation (e.g. IVs, authentica-
  287.   tor lengths, and key lengths).  To help eliminate some complexity
  288.   involved with key management having to negotiate large numbers of
  289.   algorithm-specific parameters, Cipher and Authenticator documents will
  290.   select fixed values for these parameters when it is deemed technically
  291.   reasonable and feasible.
  292.  
  293.   Note, the following information is intended as a general guideline
  294.   only.
  295.  
  296. 4.1 Cipher and Authenticator
  297.  
  298.    This section describes the information that should be included in
  299.    both Cipher and Authenticator documents.
  300.  
  301.    Keying Material
  302.    .  Size of keys, including minimum, maximum, recommended and/or
  303.       required sizes.  Note: the security considerations section should
  304.       address any weakness in specific sizes.
  305.  
  306.  
  307.  
  308. Thayer, Doraswamy, Glenn                                        [Page 5]
  309.  
  310. INTERNET DRAFT                  July 1997           Expires January 1998
  311.  
  312.  
  313.    .  Format of keying material.
  314.    .  Known weak keys or references to documentation on known weak keys.
  315.    .  Recommended or required processing of input keying material such as
  316.       parity generation or checking.
  317.    .  Requirements and/or recommendations on how often the keying
  318.       material should be refreshed.
  319.  
  320.    Performance Considerations
  321.    .  Any available estimates on performance of this algorithm.
  322.    .  Any available comparison data  (e.g., compared against DES or
  323.       MD5).
  324.    .  Input size or other considerations that could improve or degrade
  325.       performance.
  326.  
  327.    ESP Environmental Considerations
  328.    .  Any known issues regarding interactions between this algorithm and
  329.       other aspects of ESP, such as use of certain authentication
  330.       schemes.  Note:  As new authentication and cipher algorithms are
  331.       applied to ESP, the later documents will be required to address
  332.       interactions with previously specified algorithms.
  333.  
  334.    Payload Content and Format Description
  335.    .  Specification of size, placement, and content of algorithm-specific
  336.       fields not defined in the ESP or AH protocol documents (e.g., IV).
  337.  
  338.    Security Considerations
  339.    .  Discuss any known attacks.
  340.    .  Discuss any known common implementation pitfalls, such as use of
  341.       weak random number generators.
  342.    .  Discuss any relevant validation procedures, such as test vectors.
  343.  
  344. 4.2 Cipher
  345.  
  346.    This section describes the information that should be included in
  347.    Cipher documents.
  348.  
  349.    Cipher Description
  350.    .  General information how this cipher algorithm is to be used in
  351.       ESP.
  352.    .  Description of background material and formal algorithm
  353.       description.
  354.    .  Features of this cipher to be used by ESP, including encryption
  355.       and/or authentication.
  356.    .  Mention of any availability issues such as Intellectual Property
  357.       considerations.
  358.    .  References, in IETF style, to background material such as FIPS
  359.       documents.
  360.  
  361.    Algorithm Modes of Operation
  362.    .  Description of how the algorithm is operated, whether it is block
  363.       mode or streaming mode or other.
  364.    .  Requirements for input or output block format.
  365.    .  Padding requirements of this algorithm.  Note: there is a default
  366.       for padding, specified in the base ESP document, so this is only
  367.  
  368.  
  369.  
  370. Thayer, Doraswamy, Glenn                                        [Page 6]
  371.  
  372. INTERNET DRAFT                  July 1997           Expires January 1998
  373.  
  374.  
  375.       needed if the default cannot be used.
  376.    .  Any algorithm-specific operating parameters, such as number of
  377.       rounds.
  378.    .  Identify optional parameters and optional methods of operation and
  379.       pick reasonable fixed values and methods with explicit technical
  380.       explanations.
  381.    .  Identify those optional parameters in which values and methods
  382.       should remain optional with explicit technical explanations on why
  383.       fixed values and methods should not be used.
  384.    .  Defaults and mandatory ranges on algorithm-specific optional
  385.       parameters that could not be fixed.
  386.  
  387. 4.3 Authenticator
  388.  
  389.    This section describes the information that should be included in
  390.    Authenticator documents.  In most cases, an authenticator algorithm
  391.    will operate the same whether it is used for ESP or AH. This should
  392.    be represented in a single authenticator algorithm document.
  393.  
  394.    Authenticator Description
  395.    .  General information on how this authenticator algorithm is to be
  396.       used with ESP and AH.
  397.    .  Description of background material and formal algorithm
  398.       description.
  399.    .  Features of this authenticator.
  400.    .  Mention of any availability issues such as Intellectual Property
  401.       considerations.
  402.    .  References, in IETF style, to background material such as
  403.       FIPS documents and definitive descriptions of underlying
  404.       algorithms.
  405.  
  406.    Algorithm Modes of Operation
  407.    .  Description of how the algorithm is operated.
  408.    .  Algorithm-specific operating parameters, such as number of
  409.       rounds, and input or output block format.
  410.    .  Implicit and explicit padding requirements of this algorithm.  Note:
  411.       There is a default method for padding of the authenticator field
  412.       specified in the AH protocol document.  This is only needed if the
  413.       default cannot be used.
  414.    .  Identify optional parameters and optional methods of operation and
  415.       pick reasonable fixed values and methods with explicit technical
  416.       explanations.
  417.    .  Identify those optional parameters in which values and methods
  418.       should remain optional with explicit technical explanations on why
  419.       fixed values and methods should not be used.
  420.    .  Defaults and mandatory ranges on algorithm-specific optional
  421.       parameters that could not be fixed.
  422.    .  Authenticator comparison criteria for this algorithm.  Note: There
  423.       is a default method for verifying the authenticator specified
  424.       in the AH protocol document.  This is only needed if the default
  425.       cannot be used (e.g. when using a signed hash).
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432. Thayer, Doraswamy, Glenn                                        [Page 7]
  433.  
  434. INTERNET DRAFT                  July 1997           Expires January 1998
  435.  
  436.  
  437. 5. Security Considerations
  438.  
  439.    This document provides a roadmap and guidelines for writing cipher
  440.    and authenticator documents. The reader SHOULD follow all the secu-
  441.    rity procedures and guidelines described in the IPsec Architecture,
  442.    ESP, AH, cipher and authenticator documents.  Note that many cipher
  443.    algorithms are not considered secure if they are not used with some
  444.    sort of authentication mechanism.
  445.  
  446. 6. Acknowledgments
  447.  
  448.    Several Internet drafts were referenced in writing this document.
  449.    Depending on where the documents are on (or off) the IETF standards
  450.    track these may not be available through the IETF RFC repositories.
  451.    In certain cases the reader may want to know what version of these
  452.    documents were referenced. These documents are:
  453.  
  454.    .  ARCH: draft-ietf-ipsec-arch-sec-01.txt.
  455.    .  DES-Detroit: this is the ANX Workshop style of ESP, based on the
  456.       Hughes draft as modified by Cheryl Madson and published on the ANX
  457.       mailing list.
  458.    .  DES-1829: this is Bill Simpson's DES-CBC for ESP document, to be
  459.       published as draft-simpson-esp-des1-v2-01.txt.
  460.    .  3DES: this is <the Triple-DES shim document>.
  461.    .  CAST: this is draft-ietf-ipsec-esp-cast-128-cbc-00.txt, as revised
  462.       to relate to this document.
  463.    .  DOI: draft-ietf-ietf-doi-02.txt.
  464.    .  ESP: draft-ietf-ipsec-esp-04.txt, mailed to the IETF mailing list
  465.       in May/June 1997.
  466.    .  AH: draft-ietf-ipsec-auth-05.txt, mailed to the IETF mailing list
  467.       in May/June 1997.
  468.    .  HUGHES: this is draft-ietf-ipsec-esp-des-md5-03.txt
  469.    .  ISAKMP: There are three documents describing ISAKMP.  These are
  470.       draft-ietf-ipsec-isakmp-07.txt, draft-ietf-ipsec-isakmp-oakley-
  471.       03.txt, and draft-ietf-ipsec-ipsec-doi-02.txt.
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Thayer, Doraswamy, Glenn                                        [Page 8]
  495.  
  496. INTERNET DRAFT                  July 1997           Expires January 1998
  497.  
  498.  
  499. 7. References
  500.  
  501.    [3DES]        Triple-DES for ESP, RFC-xxxx.
  502.  
  503.    [ARCH]        Atkinson, R., "Security Architecture for the Internet
  504.                  Protocol", RFC-1825, Naval Research Laboratory,
  505.                  July 1995.
  506.  
  507.    [CAST]        CAST for ESP, RFC-xxxx.
  508.  
  509.    [DES-Detroit] DES for ESP, Detroit dialect, RFC-xxxx.
  510.  
  511.    [DES-1829]    DES for ESP, 1829-Compatible mode, RFC-xxxx.
  512.  
  513.    [DOI]         IP Security Domain of Interpretation, RFC-xxxx.
  514.  
  515.    [ESP]         Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
  516.                  Transform", RFC 1829, Qualcomm, Inc., Piermont,
  517.                  Daydreamer, August 1995.
  518.  
  519.    [HMAC]        Krawczyk, K., Bellare, M., and Canetti R., "HMAC:
  520.                  Keyed-Hashing for Message Authentication", RFC-2104,
  521.                  February 1997.
  522.  
  523.    [HMAC-MD5]    Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP
  524.                  and AH", draft-ietf-ipsec-ff-auth-hmac-sha-1-00.txt,
  525.                  June 1997.
  526.  
  527.    [HMAC-SHA-1]  Madson, C., Glenn, R., "The Use of HMAC-SHA-1 within
  528.                  ESP and AH", draft-ietf-ipsec-ff-auth-hmac-sha-1-00.txt,
  529.                  June 1997.
  530.  
  531. 8. Author's Addresses
  532.  
  533.    Rodney Thayer
  534.    Sable Technology Corporation
  535.    246 Walnut Street
  536.    Newton, Massachusetts  02160
  537.    <mailto:rodney@sabletech.com>
  538.  
  539.    Naganand Doraswamy
  540.    Bay Networks
  541.    e-mail: naganand@baynetworks.com
  542.  
  543.    Rob Glenn
  544.    NIST
  545.    e-mail: rob.glenn@nist.gov
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556. Thayer, Doraswamy, Glenn                                        [Page 9]
  557.  
  558.