home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2025.txt < prev    next >
Text File  |  1996-10-22  |  102KB  |  2,524 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           C. Adams
  8. Request for Comments: 2025                        Bell-Northern Research
  9. Category: Standards Track                                   October 1996
  10.  
  11.  
  12.              The Simple Public-Key GSS-API Mechanism (SPKM)
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This specification defines protocols, procedures, and conventions to
  25.    be employed by peers implementing the Generic Security Service
  26.    Application Program Interface (as specified in RFCs 1508 and 1509)
  27.    when using the Simple Public-Key Mechanism.
  28.  
  29. Background
  30.  
  31.    Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
  32.    well-established in many environments, it is important in some
  33.    applications to have a GSS-API mechanism which is based on a public-
  34.    key, rather than a symmetric-key, infrastructure.  The mechanism
  35.    described in this document has been proposed to meet this need and to
  36.    provide the following features.
  37.  
  38.      1)  The SPKM allows both unilateral and mutual authentication
  39.          to be accomplished without the use of secure timestamps.  This
  40.          enables environments which do not have access to secure time
  41.          to nevertheless have access to secure authentication.
  42.  
  43.      2)  The SPKM uses Algorithm Identifiers to specify various
  44.          algorithms to be used by the communicating peers.  This allows
  45.          maximum flexibility for a variety of environments, for future
  46.          enhancements, and for alternative algorithms.
  47.  
  48.      3)  The SPKM allows the option of a true, asymmetric algorithm-
  49.          based, digital signature in the gss_sign() and gss_seal()
  50.          operations (now called gss_getMIC() and gss_wrap() in
  51.          [GSSv2]), rather than an integrity checksum based on a MAC
  52.          computed with a symmetric algorithm (e.g., DES).  For some
  53.          environments, the availability of true digital signatures
  54.          supporting non-repudiation is a necessity.
  55.  
  56.  
  57.  
  58. Adams                       Standards Track                     [Page 1]
  59.  
  60. RFC 2025                          SPKM                      October 1996
  61.  
  62.  
  63.      4)  SPKM data formats and procedures are designed to be as similar
  64.          to those of the Kerberos mechanism as is practical.  This is
  65.          done for ease of implementation in those environments where
  66.          Kerberos has already been implemented.
  67.  
  68.    For the above reasons, it is felt that the SPKM will offer
  69.    flexibility and functionality, without undue complexity or overhead.
  70.  
  71. Key Management
  72.  
  73.    The key management employed in SPKM is intended to be as compatible
  74.    as possible with both X.509 [X.509] and PEM [RFC-1422], since these
  75.    represent large communities of interest and show relative maturity in
  76.    standards.
  77.  
  78. Acknowledgments
  79.  
  80.    Much of the material in this document is based on the Kerberos
  81.    Version 5 GSS-API mechanism [KRB5], and is intended to be as
  82.    compatible with it as possible.  This document also owes a great debt
  83.    to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
  84.    many fruitful discussions, to Kelvin Desplanque for implementation-
  85.    related clarifications, to John Linn of OpenVision Technologies for
  86.    helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.
  87.  
  88. 1. Overview
  89.  
  90.    The goal of the Generic Security Service Application Program
  91.    Interface (GSS-API) is stated in the abstract of [RFC-1508] as
  92.    follows:
  93.  
  94.      "This Generic Security Service Application Program Interface (GSS-
  95.      API) definition provides security services to callers in a generic
  96.      fashion, supportable with a range of underlying mechanisms and
  97.      technologies and hence allowing source-level portability of
  98.      applications to different environments. This specification defines
  99.      GSS-API services and primitives at a level independent of
  100.      underlying mechanism and programming language environment, and is
  101.      to be complemented by other, related specifications:
  102.  
  103.        - documents defining specific parameter bindings for particular
  104.          language environments;
  105.  
  106.        - documents defining token formats, protocols, and procedures to
  107.          be implemented in order to realize GSS-API services atop
  108.          particular security mechanisms."
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Adams                       Standards Track                     [Page 2]
  115.  
  116. RFC 2025                          SPKM                      October 1996
  117.  
  118.  
  119.    The SPKM is an instance of the latter type of document and is
  120.    therefore termed a "GSS-API Mechanism".  This mechanism provides
  121.    authentication, key establishment, data integrity, and data
  122.    confidentiality in an on-line distributed application environment
  123.    using a public-key infrastructure.  Because it conforms to the
  124.    interface defined by [RFC-1508], SPKM can be used as a drop-in
  125.    replacement by any application which makes use of security services
  126.    through GSS-API calls (for example, any application which already
  127.    uses the Kerberos GSS-API for security).  The use of a public-key
  128.    infrastructure allows digital signatures supporting non-repudiation
  129.    to be employed for message exchanges, and provides other benefits
  130.    such as scalability to large user populations.
  131.  
  132.    The tokens defined in SPKM are intended to be used by application
  133.    programs according to the GSS API "operational paradigm" (see [RFC-
  134.    1508] for further details):
  135.  
  136.      The operational paradigm in which GSS-API operates is as follows.
  137.      A typical GSS-API caller is itself a communications protocol [or is
  138.      an application program which uses a communications protocol],
  139.      calling on GSS-API in order to protect its communications with
  140.      authentication, integrity, and/or confidentiality security
  141.      services.  A GSS-API caller accepts tokens provided to it by its
  142.      local GSS-API implementation [i.e., its GSS-API mechanism] and
  143.      transfers the tokens to a peer on a remote system; that peer passes
  144.      the received tokens to its local GSS-API implementation for
  145.      processing.
  146.  
  147.      This document defines two separate GSS-API mechanisms, SPKM-1 and
  148.      SPKM-2, whose primary difference is that SPKM-2 requires the
  149.      presence of secure timestamps for the purpose of replay detection
  150.      during context establishment and SPKM-1 does not.  This allows
  151.      greater flexibility for applications since secure timestamps cannot
  152.      always be guaranteed to be available in a given environment.
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Adams                       Standards Track                     [Page 3]
  171.  
  172. RFC 2025                          SPKM                      October 1996
  173.  
  174.  
  175. 2. Algorithms
  176.  
  177.    A number of algorithm types are employed in SPKM.  Each type, along
  178.    with its purpose and a set of specific examples, is described in this
  179.    section.  In order to ensure at least a minimum level of
  180.    interoperability among various implementations of SPKM, one of the
  181.    integrity algorithms is specified as MANDATORY; all remaining
  182.    examples (and any other algorithms) may optionally be supported by a
  183.    given SPKM implementation (note that a GSS-conformant mechanism need
  184.    not support confidentiality).  Making a confidentiality algorithm
  185.    mandatory may preclude exportability of the mechanism implementation;
  186.    this document therefore specifies certain algorithms as RECOMMENDED
  187.    (that is, interoperability will be enhanced if these algorithms are
  188.    included in all SPKM implementations for which exportability is not a
  189.    concern).
  190.  
  191. 2.1 Integrity Algorithm (I-ALG):
  192.  
  193.          Purpose:
  194.  
  195.          This algorithm is used to ensure that a message has not been
  196.          altered in any way after being constructed by the legitimate
  197.          sender.  Depending on the algorithm used, the application of
  198.          this algorithm may also provide authenticity and support non-
  199.          repudiation for the message.
  200.  
  201.        Examples:
  202.  
  203.          md5WithRSAEncryption OBJECT IDENTIFIER ::= {
  204.            iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
  205.            pkcs-1(1) 4        -- imported from [PKCS1]
  206.          }
  207.  
  208.             This algorithm (MANDATORY) provides data integrity and
  209.             authenticity and supports non-repudiation by computing an
  210.             RSA signature on the MD5 hash of that data.  This is
  211.             essentially equivalent to md5WithRSA {1 3 14 3 2 3},
  212.             which is defined by OIW (the Open Systems Environment
  213.             Implementors' Workshop).
  214.  
  215.             Note that since this is the only integrity/authenticity
  216.             algorithm specified to be mandatory at this time, for
  217.             interoperability reasons it is also stipulated that
  218.             md5WithRSA be the algorithm used to sign all context
  219.             establishment tokens which are signed rather than MACed --
  220.             see Section 3.1.1 for details.  In future versions of this
  221.             document, alternate or additional algorithms may be
  222.             specified to be mandatory and so this stipulation on the
  223.  
  224.  
  225.  
  226. Adams                       Standards Track                     [Page 4]
  227.  
  228. RFC 2025                          SPKM                      October 1996
  229.  
  230.  
  231.             context establishment tokens may be removed.
  232.  
  233.          DES-MAC OBJECT IDENTIFIER ::= {
  234.             iso(1) identified-organization(3) oiw(14) secsig(3)
  235.             algorithm(2) 10  -- carries length in bits of the MAC as
  236.          }                   -- an INTEGER parameter, constrained to
  237.                              -- multiples of eight from 16 to 64
  238.  
  239.             This algorithm (RECOMMENDED) provides integrity by computing
  240.             a DES MAC (as specified by [FIPS-113]) on that data.
  241.  
  242.  
  243.          md5-DES-CBC OBJECT IDENTIFIER ::= {
  244.             iso(1) identified-organization(3) dod(6) internet(1)
  245.             security(5) integrity(3) md5-DES-CBC(1)
  246.          }
  247.  
  248.             This algorithm provides data integrity by encrypting, using
  249.             DES CBC, the "confounded" MD5 hash of that data (see Section
  250.             3.2.2.1 for the definition and purpose of confounding).
  251.             This will typically be faster in practice than computing a
  252.             DES MAC unless the input data is extremely short (e.g., a
  253.             few bytes).  Note that without the confounder the strength
  254.             of this integrity mechanism is (at most) equal to the
  255.             strength of DES under a known-plaintext attack.
  256.  
  257.  
  258.          sum64-DES-CBC OBJECT IDENTIFIER ::= {
  259.             iso(1) identified-organization(3) dod(6) internet(1)
  260.             security(5) integrity(3) sum64-DES-CBC(2)
  261.          }
  262.  
  263.             This algorithm provides data integrity by encrypting, using
  264.             DES CBC, the concatenation of the confounded data and the
  265.             sum of all the input data blocks (the sum computed using
  266.             addition modulo 2**64 - 1).  Thus, in this algorithm,
  267.             encryption is a requirement for the integrity to be secure.
  268.  
  269.             For comments regarding the security of this integrity
  270.             algorithm, see [Juen84, Davi89].
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Adams                       Standards Track                     [Page 5]
  283.  
  284. RFC 2025                          SPKM                      October 1996
  285.  
  286.  
  287. 2.2 Confidentiality Algorithm (C-ALG):
  288.  
  289.        Purpose:
  290.  
  291.          This symmetric algorithm is used to generate the encrypted
  292.          data for gss_seal() / gss_wrap().
  293.  
  294.        Example:
  295.  
  296.          DES-CBC OBJECT IDENTIFIER ::= {
  297.             iso(1) identified-organization(3) oiw(14) secsig(3)
  298.             algorithm(2) 7 -- carries IV (OCTET STRING) as a parameter;
  299.          }                 -- this (optional) parameter is unused in
  300.                            -- SPKM due to the use of confounding
  301.  
  302.             This algorithm is RECOMMENDED.
  303.  
  304. 2.3 Key Establishment Algorithm (K-ALG):
  305.  
  306.        Purpose:
  307.  
  308.          This algorithm is used to establish a symmetric key for use
  309.          by both the initiator and the target over the established
  310.          context.  The keys used for C-ALG and any keyed I-ALGs (for
  311.          example, DES-MAC) are derived from this context key.  As will
  312.          be seen in Section 3.1, key establishment is done within the
  313.          X.509 authentication exchange and so the resulting shared
  314.          symmetric key is authenticated.
  315.  
  316.        Examples:
  317.  
  318.          RSAEncryption OBJECT IDENTIFIER ::= {
  319.            iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
  320.            pkcs-1(1) 1        -- imported from [PKCS1] and [RFC-1423]
  321.          }
  322.  
  323.             In this algorithm (MANDATORY), the context key is generated
  324.             by the initiator, encrypted with the RSA public key of the
  325.             target, and sent to the target.  The target need not respond
  326.             to the initiator for the key to be established.
  327.  
  328.          id-rsa-key-transport OBJECT IDENTIFIER ::= {
  329.             iso(1) identified-organization(3) oiw(14) secsig(3)
  330.             algorithm(2) 22   -- imported from [X9.44]
  331.          }
  332.  
  333.             Similar to RSAEncryption, but source authenticating info.
  334.             is also encrypted with the target's RSA public key.
  335.  
  336.  
  337.  
  338. Adams                       Standards Track                     [Page 6]
  339.  
  340. RFC 2025                          SPKM                      October 1996
  341.  
  342.  
  343.         dhKeyAgreement OBJECT IDENTIFIER ::= {
  344.            iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
  345.            pkcs-3(3) 1
  346.         }
  347.  
  348.             In this algorithm, the context key is generated jointly by
  349.             the initiator and the target using the Diffie-Hellman key
  350.             establishment algorithm.  The target must therefore respond
  351.             to the initiator for the key to be established (so this
  352.             K-ALG cannot be used with unilateral authentication in
  353.             SPKM-2 (see Section 3.1)).
  354.  
  355. 2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:
  356.  
  357.        Purpose:
  358.  
  359.          Having established a context key using the negotiated K-ALG,
  360.          both initiator and target must be able to derive a set of
  361.          subkeys for the various C-ALGs and keyed I-ALGs supported over
  362.          the context.  Let the (ordered) list of agreed C-ALGs be
  363.          numbered consecutively, so that the first algorithm (the
  364.          "default") is numbered "0", the next is numbered "1", and so
  365.          on.  Let the numbering for the (ordered) list of agreed I-ALGs
  366.          be identical.  Finally, let the context key be a binary string
  367.          of arbitrary length "M", subject to the following constraint:
  368.          L <= M <= U  (where the lower limit "L" is the bit length of
  369.          the longest key needed by any agreed C-ALG or keyed I-ALG, and
  370.          the upper limit "U" is the largest bit size which will fit
  371.          within the K-ALG parameters).
  372.  
  373.          For example, if DES and two-key-triple-DES are the negotiated
  374.          confidentiality algorithms and DES-MAC is the negotiated keyed
  375.          integrity algorithm (note that digital signatures do not use a
  376.          context key), then the context key must be at least 112 bits
  377.          long.  If 512-bit RSAEncryption is the K-ALG in use then the
  378.          originator can randomly generate a context key of any greater
  379.          length up to 424 bits (the longest allowable RSA input
  380.          specified in [PKCS-1]) -- the target can determine the length
  381.          which was chosen by removing the padding bytes during the RSA
  382.          decryption operation.  On the other hand, if dhKeyAgreement is
  383.          the K-ALG in use then the context key is the result of the
  384.          Diffie-Hellman computation (with the exception of the high-
  385.          order byte, which is discarded for security reasons), so that
  386.          its length is that of the Diffie-Hellman modulus, p, minus 8
  387.          bits.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Adams                       Standards Track                     [Page 7]
  395.  
  396. RFC 2025                          SPKM                      October 1996
  397.  
  398.  
  399.          The derivation algorithm for a k-bit subkey is specified as
  400.          follows:
  401.  
  402.       rightmost_k_bits (OWF(context_key || x || n || s || context_key))
  403.  
  404.          where
  405.  
  406.           - "x" is the ASCII character "C" (0x43) if the subkey is
  407.             for a confidentiality algorithm or the ASCII character "I"
  408.             (0x49) if the subkey is for a keyed integrity algorithm;
  409.           - "n" is the number of the algorithm in the appropriate agreed
  410.             list for the context (the ASCII character "0" (0x30), "1"
  411.             (0x31), and so on);
  412.           - "s" is the "stage" of processing -- always the ASCII
  413.             character "0" (0x30), unless "k" is greater than the output
  414.             size of OWF, in which case the OWF is computed repeatedly
  415.             with increasing ASCII values of "stage" (each OWF output
  416.             being concatenated to the end of previous OWF outputs),
  417.             until "k" bits have been generated;
  418.           - "||" is the concatenation operation; and
  419.           - "OWF" is any appropriate One-Way Function.
  420.  
  421.        Examples:
  422.  
  423.          MD5 OBJECT IDENTIFIER ::= {
  424.            iso(1) member-body(2) US(840) rsadsi(113549)
  425.            digestAlgorithm(2) 5
  426.          }
  427.  
  428.            This algorithm is MANDATORY.
  429.  
  430.          SHA OBJECT IDENTIFIER ::= {
  431.             iso(1) identified-organization(3) oiw(14) secsig(3)
  432.             algorithm(2) 18
  433.          }
  434.  
  435.          It is recognized that existing hash functions may not satisfy
  436.          all required properties of OWFs.  This is the reason for
  437.          allowing negotiation of the O-ALG OWF during the context
  438.          establishment process (see Section 2.5), since in this way
  439.          future improvements in OWF design can easily be accommodated.
  440.          For example, in some environments a preferred OWF technique
  441.          might be an encryption algorithm which encrypts the input
  442.          specified above using the context_key as the encryption key.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Adams                       Standards Track                     [Page 8]
  451.  
  452. RFC 2025                          SPKM                      October 1996
  453.  
  454.  
  455. 2.5 Negotiation:
  456.  
  457.    During context establishment in SPKM, the initiator offers a set of
  458.    possible confidentiality algorithms and a set of possible integrity
  459.    algorithms to the target (note that the term "integrity algorithms"
  460.    includes digital signature algorithms).  The confidentiality
  461.    algorithms selected by the target become ones that may be used for
  462.    C-ALG over the established context, and the integrity algorithms
  463.    selected by the target become ones that may be used for I-ALG over
  464.    the established context (the target "selects" algorithms by
  465.    returning, in the same relative order, the subset of each offered
  466.    list that it supports).  Note that any C-ALG and I-ALG may be used
  467.    for any message over the context and that the first confidentiality
  468.    algorithm and the first integrity algorithm in the agreed sets become
  469.    the default algorithms for that context.
  470.  
  471.    The agreed confidentiality and integrity algorithms for a specific
  472.    context define the valid values of the Quality of Protection (QOP)
  473.    parameter used in the gss_getMIC() and gss_wrap() calls -- see
  474.    Section 5.2 for further details.  If no response is expected from the
  475.    target (unilateral authentication in SPKM-2) then the algorithms
  476.    offered by the initiator are the ones that may be used over the
  477.    context (if this is unacceptable to the target then a delete token
  478.    must be sent to the initiator so that the context is never
  479.    established).
  480.  
  481.    Furthermore, in the first context establishment token the initiator
  482.    offers a set of possible K-ALGs, along with the key (or key half)
  483.    corresponding to the first algorithm in the set (its preferred
  484.    algorithm).  If this K-ALG is unacceptable to the target then the
  485.    target must choose one of the other K-ALGs in the set and send this
  486.    choice along with the key (or key half) corresponding to this choice
  487.    in its response (otherwise a delete token must be sent so that the
  488.    context is never established).  If necessary (that is, if the target
  489.    chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will
  490.    send its key half in a response to the target.
  491.  
  492.    Finally, in the first context establishment token the initiator
  493.    offers a set of possible O-ALGs (only a single O-ALG if no response
  494.    is expected).  The (single) O-ALG chosen by the target becomes the
  495.    subkey derivation algorithm OWF to be used over the context.
  496.  
  497.    In future versions of SPKM, other algorithms may be specified for any
  498.    or all of I-ALG, C-ALG, K-ALG, and O-ALG.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Adams                       Standards Track                     [Page 9]
  507.  
  508. RFC 2025                          SPKM                      October 1996
  509.  
  510.  
  511. 3. Token Formats
  512.  
  513.    This section discusses protocol-visible characteristics of the SPKM;
  514.    it defines elements of protocol for interoperability and is
  515.    independent of language bindings per [RFC-1509].
  516.  
  517.    The SPKM GSS-API mechanism will be identified by an Object Identifier
  518.    representing "SPKM-1" or "SPKM-2", having the value {spkm spkm-1(1)}
  519.    or {spkm spkm-2(2)}, where spkm has the value {iso(1) identified-
  520.    organization(3) dod(6) internet(1) security(5) mechanisms(5)
  521.    spkm(1)}.  SPKM-1 uses random numbers for replay detection during
  522.    context establishment and SPKM-2 uses timestamps (note that for both
  523.    mechanisms, sequence numbers are used to provide replay and out-of-
  524.    sequence detection during the context, if this has been requested by
  525.    the application).
  526.  
  527.    Tokens transferred between GSS-API peers (for security context
  528.    management and per-message protection purposes) are defined.
  529.  
  530. 3.1. Context Establishment Tokens
  531.  
  532.    Three classes of tokens are defined in this section:  "Initiator"
  533.    tokens, emitted by calls to gss_init_sec_context() and consumed by
  534.    calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
  535.    to gss_accept_sec_context() and consumed by calls to
  536.    gss_init_sec_context(); and "Error" tokens, potentially emitted by
  537.    calls to gss_init_sec_context() or gss_accept_sec_context(), and
  538.    potentially consumed by calls to gss_init_sec_context() or
  539.    gss_accept_sec_context().
  540.  
  541.    Per RFC-1508, Appendix B, the initial context establishment token
  542.    will be enclosed within framing as follows:
  543.  
  544.    InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
  545.            thisMech           MechType,
  546.                    -- MechType is OBJECT IDENTIFIER
  547.                    -- representing "SPKM-1" or "SPKM-2"
  548.            innerContextToken  ANY DEFINED BY thisMech
  549.    }               -- contents mechanism-specific
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Adams                       Standards Track                    [Page 10]
  563.  
  564. RFC 2025                          SPKM                      October 1996
  565.  
  566.  
  567.    When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as
  568.    follows:
  569.  
  570.       SPKMInnerContextToken ::= CHOICE {
  571.          req    [0] SPKM-REQ,
  572.          rep-ti [1] SPKM-REP-TI,
  573.          rep-it [2] SPKM-REP-IT,
  574.          error  [3] SPKM-ERROR,
  575.          mic    [4] SPKM-MIC,
  576.          wrap   [5] SPKM-WRAP,
  577.          del    [6] SPKM-DEL
  578.       }
  579.  
  580.    The above GSS-API framing shall be applied to all tokens emitted by
  581.    the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from
  582.    the Target to the Initiator), SPKM-REP-IT (the response from the
  583.    Initiator to the Target), SPKM-ERROR, context-deletion, and per-
  584.    message tokens, not just to the initial token in a context
  585.    establishment exchange.  While not required by RFC-1508, this enables
  586.    implementations to perform enhanced error-checking.  The tag values
  587.    provided in SPKMInnerContextToken ("[0]" through "[6]") specify a
  588.    token-id for each token; similar information is contained in each
  589.    token's tok-id field.  While seemingly redundant, the tag value and
  590.    tok-id actually perform different tasks:  the tag ensures that
  591.    InitialContextToken can be properly decoded; tok-id ensures, among
  592.    other things, that data associated with the per-message tokens is
  593.    cryptographically linked to the intended token type.  Every
  594.    innerContextToken also includes a context-id field; see Section 6 for
  595.    a discussion of both token-id and context-id information and their
  596.    use in an SPKM support function).
  597.  
  598.    The innerContextToken field of context establishment tokens for the
  599.    SPKM GSS-API mechanism will contain one of the following messages:
  600.    SPKM-REQ; SPKM-REP-TI; SPKM-REP-IT; and SPKM-ERROR.  Furthermore, all
  601.    innerContextTokens are encoded using ASN.1 BER (constrained, in the
  602.    interests of parsing simplicity, to the DER subset defined in
  603.    [X.509], clause 8.7).
  604.  
  605.    The SPKM context establishment tokens are defined according to
  606.    [X.509] Section 10 and are compatible with [9798].  SPKM-1 (random
  607.    numbers) uses Section 10.3, "Two-way Authentication", when performing
  608.    unilateral authentication of the target to the initiator and uses
  609.    Section 10.4, "Three-way Authentication", when mutual authentication
  610.    is requested by the initiator.  SPKM-2 (timestamps) uses Section
  611.    10.2, "One-way Authentication", when performing unilateral
  612.    authentication of the initiator to the target and uses Section 10.3,
  613.    "Two-way Authentication", when mutual authentication is requested by
  614.    the initiator.
  615.  
  616.  
  617.  
  618. Adams                       Standards Track                    [Page 11]
  619.  
  620. RFC 2025                          SPKM                      October 1996
  621.  
  622.  
  623.    The implication of the previous paragraph is that for SPKM-2
  624.    unilateral authentication no negotiation of K-ALG can be done (the
  625.    target either accepts the K-ALG and context key given by the
  626.    initiator or disallows the context).  For SPKM-2 mutual or SPKM-1
  627.    unilateral authentication some negotiation is possible, but the
  628.    target can only choose among the one-pass K-ALGs offered by the
  629.    initiator (or disallow the context).  Alternatively, the initiator
  630.    can request that the target generate and transmit the context key.
  631.    For SPKM-1 mutual authentication the target can choose any one- or
  632.    two-pass K-ALG offered by the initiator and, again, can be requested
  633.    to generate and transmit the context key.
  634.  
  635.    It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
  636.    mutual authentication.  Although unilateral authentication is
  637.    available for both mechanisms, its use is not generally recommended.
  638.  
  639. 3.1.1. Context Establishment Tokens - Initiator (first token)
  640.  
  641.    In order to accomplish context establishment, it may be necessary
  642.    that both the initiator and the target have access to the other
  643.    partys public-key certificate(s).  In some environments the initiator
  644.    may choose to acquire all certificates and send the relevant ones to
  645.    the target in the first token.  In other environments the initiator
  646.    may request that the target send certificate data in its response
  647.    token, or each side may individually obtain the certificate data it
  648.    needs.  In any case, however, the SPKM implementation must have the
  649.    ability to obtain certificates which correspond to a supplied Name.
  650.    The actual mechanism to be used to achieve this is a local
  651.    implementation matter and is therefore outside the scope of this
  652.    specification.
  653.  
  654.  
  655.    Relevant SPKM-REQ syntax is as follows (note that imports from other
  656.    documents are given in Appendix A):
  657.  
  658.    SPKM-REQ ::= SEQUENCE {
  659.            requestToken      REQ-TOKEN,
  660.            certif-data [0]   CertificationData OPTIONAL,
  661.            auth-data [1]     AuthorizationData OPTIONAL
  662.               -- see [RFC-1510] for a discussion of auth-data
  663.    }
  664.  
  665.    CertificationData ::= SEQUENCE {
  666.            certificationPath [0]          CertificationPath OPTIONAL,
  667.            certificateRevocationList [1]  CertificateList OPTIONAL
  668.    }  -- at least one of the above shall be present
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Adams                       Standards Track                    [Page 12]
  675.  
  676. RFC 2025                          SPKM                      October 1996
  677.  
  678.  
  679.    CertificationPath ::= SEQUENCE {
  680.            userKeyId [0]         OCTET STRING OPTIONAL,
  681.               -- identifier for user's public key
  682.            userCertif [1]        Certificate OPTIONAL,
  683.               -- certificate containing user's public key
  684.            verifKeyId [2]        OCTET STRING OPTIONAL,
  685.               -- identifier for user's public verification key
  686.            userVerifCertif [3]   Certificate OPTIONAL,
  687.               -- certificate containing user's public verification key
  688.            theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
  689.    }          -- certification path from target to source
  690.  
  691.    Having separate verification fields allows different key pairs
  692.    (possibly corresponding to different algorithms) to be used for
  693.    encryption/decryption and signing/verification.  Presence of [0] or
  694.    [1] and absence of [2] and [3] implies that the same key pair is to
  695.    be used for enc/dec and verif/signing (note that this practice is not
  696.    typically recommended).  Presence of [2] or [3] implies that a
  697.    separate key pair is to be used for verif/signing, and so [0] or [1]
  698.    must also be present.  Presence of [4] implies that at least one of
  699.    [0], [1], [2], and [3] must also be present.
  700.  
  701.       REQ-TOKEN ::= SEQUENCE {
  702.               req-contents     Req-contents,
  703.               algId            AlgorithmIdentifier,
  704.               req-integrity    Integrity  -- "token" is Req-contents
  705.       }
  706.  
  707.       Integrity ::= BIT STRING
  708.         -- If corresponding algId specifies a signing algorithm,
  709.         -- "Integrity" holds the result of applying the signing procedure
  710.         -- specified in algId to the BER-encoded octet string which results
  711.         -- from applying the hashing procedure (also specified in algId) to
  712.         -- the DER-encoded octets of "token".
  713.         -- Alternatively, if corresponding algId specifies a MACing
  714.         -- algorithm, "Integrity" holds the result of applying the MACing
  715.         -- procedure specified in algId to the DER-encoded octets of
  716.         -- "token" (note that for MAC, algId must be one of the integrity
  717.         -- algorithms offered by the initiator with the appropriate subkey
  718.         -- derived from the context key (see Section 2.4) used as the key
  719.         -- input)
  720.  
  721.    It is envisioned that typical use of the Integrity field for each of
  722.    REQ-TOKEN, REP-TI-TOKEN, and REP-IT-TOKEN will be a true digital
  723.    signature, providing unilateral or mutual authentication along with
  724.    replay protection, as required.  However, there are situations in
  725.    which the MAC choice will be appropriate.  One example is the case in
  726.    which the initiator wishes to remain anonymous (so that the first, or
  727.  
  728.  
  729.  
  730. Adams                       Standards Track                    [Page 13]
  731.  
  732. RFC 2025                          SPKM                      October 1996
  733.  
  734.  
  735.    first and third, token(s) will be MACed and the second token will be
  736.    signed).  Another example is the case in which a previously
  737.    authenticated, established, and cached context is being re-
  738.    established at some later time (here all exchanged tokens will be
  739.    MACed).
  740.  
  741.    The primary advantage of the MAC choice is that it reduces processing
  742.    overhead for cases in which either authentication is not required
  743.    (e.g., anonymity) or authentication is established by some other
  744.    means (e.g., ability to form the correct MAC on a "fresh" token in
  745.    context re-establishment).
  746.  
  747.    Req-contents ::= SEQUENCE {
  748.            tok-id           INTEGER (256),    -- shall contain 0100(hex)
  749.            context-id       Random-Integer,   -- see Section 6.3
  750.            pvno             BIT STRING,       -- protocol version number
  751.            timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
  752.            randSrc          Random-Integer,
  753.            targ-name        Name,
  754.            src-name [0]     Name OPTIONAL,
  755.               -- must be supplied unless originator is "anonymous"
  756.            req-data         Context-Data,
  757.            validity [1]     Validity OPTIONAL,
  758.               -- validity interval for key (may be used in the
  759.               -- computation of security context lifetime)
  760.            key-estb-set     Key-Estb-Algs,
  761.               -- specifies set of key establishment algorithms
  762.            key-estb-req      BIT STRING OPTIONAL,
  763.               -- key estb. parameter corresponding to first K-ALG in set
  764.               -- (not used if initiator is unable or unwilling to
  765.               -- generate and securely transmit key material to target).
  766.               -- Established key must satisfy the key length constraints
  767.               -- specified in Section 2.4.
  768.            key-src-bind      OCTET STRING OPTIONAL
  769.               -- Used to bind the source name to the symmetric key.
  770.               -- This field must be present for the case of SPKM-2
  771.               -- unilateral authen. if the K-ALG in use does not provide
  772.               -- such a binding (but is optional for all other cases).
  773.               -- The octet string holds the result of applying the
  774.               -- mandatory hashing procedure MD5 (in MANDATORY I-ALG;
  775.               -- see Section 2.1) as follows:  MD5(src || context_key),
  776.               -- where "src" is the DER-encoded octets of src-name,
  777.               -- "context-key" is the symmetric key (i.e., the
  778.               -- unprotected version of what is transmitted in
  779.               -- key-estb-req), and "||" is the concatenation operation.
  780.            }
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Adams                       Standards Track                    [Page 14]
  787.  
  788. RFC 2025                          SPKM                      October 1996
  789.  
  790.  
  791.    -- The protocol version number (pvno) parameter is a BIT STRING which
  792.    -- uses as many bits as necessary to specify all the SPKM protocol
  793.    -- versions supported by the initiator (one bit per protocol
  794.    -- version).  The protocol specified by this document is version 0.
  795.    -- Bit 0 of pvno is therefore set if this version is supported;
  796.    -- similarly, bit 1 is set if version 1 (if defined in the future) is
  797.    -- supported, and so on.  Note that for unilateral authentication
  798.    -- using SPKM-2, no response token is expected during context
  799.    -- establishment, so no protocol negotiation can take place; in this
  800.    -- case, the initiator must set exactly one bit of pvno.  The version
  801.    -- of REQ-TOKEN must correspond to the highest bit set in pvno.
  802.    -- The "validity" parameter above is the only way within SPKM for
  803.    -- the initiator to transmit desired context lifetime to the target.
  804.    -- Since it cannot be guaranteed that the initiator and target have
  805.    -- synchronized time, the span of time specified by "validity" is to
  806.    -- be taken as definitive (rather than the actual times given in this
  807.    -- parameter).
  808.  
  809.    Random-Integer ::= BIT STRING
  810.  
  811.    -- Each SPKM implementation is responsible for generating a "fresh"
  812.    -- random number for the purpose of context establishment; that is,
  813.    -- one which (with high probability) has not been used previously.
  814.    -- There are no cryptographic requirements on this random number
  815.    -- (i.e., it need not be unpredictable, it simply needs to be fresh).
  816.  
  817.    Context-Data ::= SEQUENCE {
  818.            channelId       ChannelId OPTIONAL, -- channel bindings
  819.            seq-number      INTEGER OPTIONAL,   -- sequence number
  820.            options         Options,
  821.            conf-alg        Conf-Algs,          -- confidentiality. algs.
  822.            intg-alg        Intg-Algs,          -- integrity algorithm
  823.            owf-alg         OWF-Algs            -- for subkey derivation
  824.    }
  825.  
  826.    ChannelId ::= OCTET STRING
  827.  
  828.    Options ::= BIT STRING {
  829.            delegation-state (0),
  830.            mutual-state (1),
  831.            replay-det-state (2), -- used for replay det. during context
  832.            sequence-state (3),   -- used for sequencing during context
  833.            conf-avail (4),
  834.            integ-avail (5),
  835.            target-certif-data-required (6)
  836.                                  -- used to request targ's certif. data
  837.    }
  838.  
  839.  
  840.  
  841.  
  842. Adams                       Standards Track                    [Page 15]
  843.  
  844. RFC 2025                          SPKM                      October 1996
  845.  
  846.  
  847.    Conf-Algs ::= CHOICE {
  848.            algs [0]        SEQUENCE OF AlgorithmIdentifier,
  849.            null [1]        NULL
  850.             -- used when conf. is not available over context
  851.    } -- for C-ALG (see Section 5.2 for discussion of QOP)
  852.  
  853.    Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
  854.        -- for I-ALG (see Section 5.2 for discussion of QOP)
  855.  
  856.    OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
  857.        -- Contains exactly one algorithm in REQ-TOKEN for SPKM-2
  858.        -- unilateral, and contains at least one algorithm otherwise.
  859.        -- Always contains exactly one algorithm in REP-TOKEN.
  860.  
  861.    Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
  862.        -- to allow negotiation of K-ALG
  863.  
  864.    A context establishment sequence based on the SPKM will perform
  865.    unilateral authentication if the mutual-req bit is not set in the
  866.    application's call to gss_init_sec_context().  SPKM-2 accomplishes
  867.    this using only SPKM-REQ (thereby authenticating the initiator to the
  868.    target), while SPKM-1 accomplishes this using both SPKM-REQ and
  869.    SPKM-REP-TI (thereby authenticating the target to the initiator).
  870.  
  871.    Applications requiring authentication of both peers (initiator as
  872.    well as target) must request mutual authentication, resulting in
  873.    "mutual-state" being set within SPKM-REQ Options.  In response to
  874.    such a request, the context target will reply to the initiator with
  875.    an SPKM-REP-TI token.  If mechanism SPKM-2 has been chosen, this
  876.    completes the (timestamp-based) mutual authentication context
  877.    establishment exchange.  If mechanism SPKM-1 has been chosen and
  878.    SPKM-REP-TI is sent, the initiator will then reply to the target with
  879.    an SPKM-REP-IT token, completing the (random-number-based) mutual
  880.    authentication context establishment exchange.
  881.  
  882.    Other bits in the Options field of Context-Data are explained in
  883.    RFC-1508, with the exception of target-certif-data-required, which
  884.    the initiator sets to TRUE to request that the target return its
  885.    certification data in the SPKM-REP-TI token.  For unilateral
  886.    authentication in SPKM-2 (in which no SPKM-REP-TI token is
  887.    constructed), this option bit is ignored by both initiator and
  888.    target.
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Adams                       Standards Track                    [Page 16]
  899.  
  900. RFC 2025                          SPKM                      October 1996
  901.  
  902.  
  903. 3.1.2. Context Establishment Tokens - Target
  904.  
  905.    SPKM-REP-TI ::= SEQUENCE {
  906.            responseToken    REP-TI-TOKEN,
  907.            certif-data      CertificationData OPTIONAL
  908.              -- included if target-certif-data-required option was
  909.              -- set to TRUE in SPKM-REQ
  910.    }
  911.  
  912.  
  913.    REP-TI-TOKEN ::= SEQUENCE {
  914.            rep-ti-contents Rep-ti-contents,
  915.            algId           AlgorithmIdentifier,
  916.            rep-ti-integ    Integrity  -- "token" is Rep-ti-contents
  917.    }
  918.  
  919.    Rep-ti-contents ::= SEQUENCE {
  920.            tok-id           INTEGER (512),   -- shall contain 0200 (hex)
  921.            context-id       Random-Integer,  -- see Section 6.3
  922.            pvno [0]         BIT STRING OPTIONAL, -- prot. version number
  923.            timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
  924.            randTarg         Random-Integer,
  925.            src-name [1]     Name OPTIONAL,
  926.              -- must contain whatever value was supplied in REQ-TOKEN
  927.            targ-name        Name,
  928.            randSrc          Random-Integer,
  929.            rep-data         Context-Data,
  930.            validity [2]     Validity  OPTIONAL,
  931.              -- validity interval for key (used if the target can only
  932.              -- support a shorter context lifetime than was offered in
  933.              -- REQ-TOKEN)
  934.            key-estb-id      AlgorithmIdentifier OPTIONAL,
  935.              -- used if target is changing key estb. algorithm (must be
  936.              -- a member of initiators key-estb-set)
  937.            key-estb-str      BIT STRING OPTIONAL
  938.              -- contains (1) the response to the initiators
  939.              -- key-estb-req (if init. used a 2-pass K-ALG), or (2) the
  940.              -- key-estb-req corresponding to the K-ALG supplied in
  941.              -- above key-estb-id, or (3) the key-estb-req corresponding
  942.              -- to the first K-ALG supplied in initiator's key-estb-id,
  943.              -- if initiator's (OPTIONAL) key-estb-req was not used
  944.              -- (target's key-estb-str must be present in this case).
  945.              -- Established key must satisfy the key length constraints
  946.              -- specified in Section 2.4.
  947.            }
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Adams                       Standards Track                    [Page 17]
  955.  
  956. RFC 2025                          SPKM                      October 1996
  957.  
  958.  
  959.    The protocol version number (pvno) parameter is a BIT STRING which
  960.    uses as many bits as necessary to specify a single SPKM protocol
  961.    version offered by the initiator which is supported by the target
  962.    (one bit per protocol version); that is, the target sets exactly one
  963.    bit of pvno.  If none of the versions offered by the initiator are
  964.    supported by the target, a delete token must be returned so that the
  965.    context is never established.  If the initiator's pvno has only one
  966.    bit set and the target happens to support this protocol version, then
  967.    this version is used over the context and the pvno parameter of REP-
  968.    TOKEN can be omitted.  Finally, if the initiator and target do have
  969.    one or more versions in common but the version of the REQ-TOKEN
  970.    received is not supported by the target, a REP-TOKEN must be sent
  971.    with a desired version bit set in pvno (and dummy values used for all
  972.    subsequent token fields).  The initiator can then respond with a new
  973.    REQ-TOKEN of the proper version (essentially starting context
  974.    establishment anew).
  975.  
  976. 3.1.3. Context Establishment Tokens - Initiator (second token)
  977.  
  978.    Relevant SPKM-REP-IT syntax is as follows:
  979.  
  980.    SPKM-REP-IT ::= SEQUENCE {
  981.            responseToken    REP-IT-TOKEN,
  982.            algId            AlgorithmIdentifier,
  983.            rep-it-integ     Integrity  -- "token" is REP-IT-TOKEN
  984.    }
  985.  
  986.    REP-IT-TOKEN ::= SEQUENCE {
  987.            tok-id           INTEGER (768), -- shall contain 0300 (hex)
  988.            context-id       Random-Integer,
  989.            randSrc          Random-Integer,
  990.            randTarg         Random-Integer,
  991.            targ-name        Name,  -- the targ-name specified in REP-TI
  992.            src-name         Name OPTIONAL,
  993.              -- must contain whatever value was supplied in REQ-TOKEN
  994.            key-estb-rep     BIT STRING OPTIONAL
  995.                  -- contains the response to targets key-estb-str
  996.                  -- (if target selected a 2-pass K-ALG)
  997.            }
  998.  
  999. 3.1.4. Error Token
  1000.  
  1001.    The syntax of SPKM-ERROR is as follows:
  1002.  
  1003.    SPKM-ERROR ::= SEQUENCE {
  1004.            error-token      ERROR-TOKEN,
  1005.            algId            AlgorithmIdentifier,
  1006.            integrity        Integrity  -- "token" is ERROR-TOKEN
  1007.  
  1008.  
  1009.  
  1010. Adams                       Standards Track                    [Page 18]
  1011.  
  1012. RFC 2025                          SPKM                      October 1996
  1013.  
  1014.  
  1015.    }
  1016.  
  1017.    ERROR-TOKRN ::=   SEQUENCE {
  1018.            tok-id           INTEGER (1024), -- shall contain 0400 (hex)
  1019.            context-id       Random-Integer
  1020.            }
  1021.  
  1022.    The SPKM-ERROR token is used only during the context establishment
  1023.    process.  If an SPKM-REQ or SPKM-REP-TI token is received in error,
  1024.    the receiving function (either gss_init_sec_context() or
  1025.    gss_accept_sec_context()) will generate an SPKM-ERROR token to be
  1026.    sent to the peer (if the peer is still in the context establishment
  1027.    process) and will return GSS_S_CONTINUE_NEEDED.  If, on the other
  1028.    hand, no context establishment response is expected from the peer
  1029.    (i.e., the peer has completed context establishment), the function
  1030.    will return the appropriate major status code (e.g., GSS_S_BAD_SIG)
  1031.    along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all
  1032.    context-relevant information will be deleted.  The output token will
  1033.    not be an SPKM-ERROR token but will instead be an SPKM-DEL token
  1034.    which will be processed by the peer's gss_process_context_token().
  1035.  
  1036.    If gss_init_sec_context() receives an error token (whether valid or
  1037.    invalid), it will regenerate SPKM-REQ as its output token and return
  1038.    a major status code of GSS_S_CONTINUE_NEEDED.  (Note that if the
  1039.    peer's gss_accept_sec_context() receives SPKM-REQ token when it is
  1040.    expecting a SPKM-REP-IT token, it will ignore SPKM-REQ and return a
  1041.    zero-length output token with a major status of
  1042.    GSS_S_CONTINUE_NEEDED.)
  1043.  
  1044.    Similarly, if gss_accept_sec_context() receives an error token
  1045.    (whether valid or invalid), it will regenerate SPKM-REP-TI as its
  1046.    output token and return a major status code of GSS_S_CONTINUE_NEEDED.
  1047.  
  1048.    md5WithRsa is currently stipulated for the signing of context
  1049.    establishment tokens.  Discrepancies involving modulus bitlength can
  1050.    be resolved through judicious use of the SPKM-ERROR token.  The
  1051.    context initiator signs REQ-TOKEN using the strongest RSA it supports
  1052.    (e.g., 1024 bits).  If the target is unable to verify signatures of
  1053.    this length, it sends SPKM-ERROR signed with the strongest RSA that
  1054.    it supports (e.g. 512).
  1055.  
  1056.    At the completion of this exchange, both sides know what RSA
  1057.    bitlength the other supports, since the size of the signature is
  1058.    equal to the size of the modulus.  Further exchanges can be made
  1059.    (using successively smaller supported bitlengths) until either an
  1060.    agreement is reached or context establishment is aborted because no
  1061.    agreement is possible.
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Adams                       Standards Track                    [Page 19]
  1067.  
  1068. RFC 2025                          SPKM                      October 1996
  1069.  
  1070.  
  1071. 3.2. Per-Message and Context Deletion Tokens
  1072.  
  1073.    Three classes of tokens are defined in this section: "MIC" tokens,
  1074.    emitted by calls to gss_getMIC() and consumed by calls to
  1075.    gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and
  1076.    consumed by calls to gss_unwrap(); and context deletion tokens,
  1077.    emitted by calls to gss_init_sec_context(), gss_accept_sec_context(),
  1078.    or gss_delete_sec_context() and consumed by calls to
  1079.    gss_process_context_token().
  1080.  
  1081. 3.2.1. Per-message Tokens - Sign / MIC
  1082.  
  1083.    Use of the gss_sign() / gss_getMIC() call yields a token, separate
  1084.    from the user data being protected, which can be used to verify the
  1085.    integrity of that data as received.  The token and the data may be
  1086.    sent separately by the sending application and it is the receiving
  1087.    application's responsibility to associate the received data with the
  1088.    received token.
  1089.  
  1090.    The SPKM-MIC token has the following format:
  1091.  
  1092.    SPKM-MIC ::= SEQUENCE {
  1093.            mic-header       Mic-Header,
  1094.            int-cksum        BIT STRING
  1095.                                 -- Checksum over header and data,
  1096.                                 -- calculated according to algorithm
  1097.                                 -- specified in int-alg field.
  1098.    }
  1099.  
  1100.    Mic-Header ::= SEQUENCE {
  1101.            tok-id           INTEGER (257),
  1102.                                 -- shall contain 0101 (hex)
  1103.            context-id       Random-Integer,
  1104.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  1105.                                 -- Integrity algorithm indicator (must
  1106.                                 -- be one of the agreed integrity
  1107.                                 -- algorithms for this context).
  1108.                                 -- field not present = default id.
  1109.            snd-seq [1]      SeqNum OPTIONAL  -- sequence number field.
  1110.    }
  1111.  
  1112.    SeqNum ::= SEQUENCE {
  1113.            num      INTEGER, -- the sequence number itself
  1114.            dir-ind  BOOLEAN  -- a direction indicator
  1115.    }
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Adams                       Standards Track                    [Page 20]
  1123.  
  1124. RFC 2025                          SPKM                      October 1996
  1125.  
  1126.  
  1127. 3.2.1.1. Checksum
  1128.  
  1129.    Checksum calculation procedure (common to all algorithms -- note that
  1130.    for SPKM the term "checksum" includes digital signatures as well as
  1131.    hashes and MACs): Checksums are calculated over the data field,
  1132.    logically prepended by the bytes of the plaintext token header (mic-
  1133.    header).  The result binds the data to the entire plaintext header,
  1134.    so as to minimize the possibility of malicious splicing.
  1135.  
  1136.    For example, if the int-alg specifies the md5WithRSA algorithm, then
  1137.    the checksum is formed by computing an MD5 [RFC-1321] hash over the
  1138.    plaintext data (prepended by the header), and then computing an RSA
  1139.    signature [PKCS1] on the 16-byte MD5 result.  The signature is
  1140.    computed using the RSA private key retrieved from the credentials
  1141.    structure and the result (whose length is implied by the "modulus"
  1142.    parameter in the private key) is stored in the int-cksum field.
  1143.  
  1144.    If the int-alg specifies a keyed hashing algorithm (for example,
  1145.    DES-MAC or md5-DES-CBC), then the key to be used is the appropriate
  1146.    subkey derived from the context key (see Section 2.4).  Again, the
  1147.    result (whose length is implied by int-alg) is stored in the int-
  1148.    cksum field.
  1149.  
  1150. 3.2.1.2. Sequence Number
  1151.  
  1152.    It is assumed that the underlying transport layers (of whatever
  1153.    protocol stack is being used by the application) will provide
  1154.    adequate communications reliability (that is, non-malicious loss,
  1155.    re-ordering, etc., of data packets will be handled correctly).
  1156.    Therefore, sequence numbers are used in SPKM purely for security, as
  1157.    opposed to reliability, reasons (that is, to avoid malicious loss,
  1158.    replay, or re-ordering of SPKM tokens) -- it is therefore recommended
  1159.    that applications request sequencing and replay detection over all
  1160.    contexts.  Note that sequence numbers are used so that there is no
  1161.    requirement for secure timestamps in the message tokens.  The
  1162.    initiator's initial sequence number for the current context may be
  1163.    explicitly given in the Context-Data field of SPKM-REQ and the
  1164.    target's initial sequence number may be explicitly given in the
  1165.    Context-Data field of SPKM-REP-TI; if either of these is not given
  1166.    then the default value of 00 is to be used.
  1167.  
  1168.    Sequence number field: The sequence number field is formed from the
  1169.    sender's four-byte sequence number and a Boolean direction-indicator
  1170.    (FALSE - sender is the context initiator, TRUE - sender is the
  1171.    context acceptor).  After constructing a gss_sign/getMIC() or
  1172.    gss_seal/wrap() token, the sender's seq. number is incremented by 1.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Adams                       Standards Track                    [Page 21]
  1179.  
  1180. RFC 2025                          SPKM                      October 1996
  1181.  
  1182.  
  1183. 3.2.1.3. Sequence Number Processing
  1184.  
  1185.    The receiver of the token will verify the sequence number field by
  1186.    comparing the sequence number with the expected sequence number and
  1187.    the direction indicator with the expected direction indicator.  If
  1188.    the sequence number in the token is higher than the expected number,
  1189.    then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is
  1190.    returned.  If the token sequence number is lower than the expected
  1191.    number, then the expected sequence number is not adjusted and
  1192.    GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is
  1193.    returned, whichever is appropriate.  If the direction indicator is
  1194.    wrong, then the expected sequence number is not adjusted and
  1195.    GSS_S_UNSEQ_TOKEN is returned.
  1196.  
  1197.    Since the sequence number is used as part of the input to the
  1198.    integrity checksum, sequence numbers need not be encrypted, and
  1199.    attempts to splice a checksum and sequence number from different
  1200.    messages will be detected.  The direction indicator will detect
  1201.    tokens which have been maliciously reflected.
  1202.  
  1203. 3.2.2. Per-message Tokens - Seal / Wrap
  1204.  
  1205.    Use of the gss_seal() / gss_wrap() call yields a token which
  1206.    encapsulates the input user data (optionally encrypted) along with
  1207.    associated integrity check quantities. The token emitted by
  1208.    gss_seal() / gss_wrap() consists of an integrity header followed by a
  1209.    body portion that contains either the plaintext data (if conf-alg =
  1210.    NULL) or encrypted data (using the appropriate subkey specified in
  1211.    Section 2.4 for one of the agreed C-ALGs for this context).
  1212.  
  1213.    The SPKM-WRAP token has the following format:
  1214.  
  1215.    SPKM-WRAP ::= SEQUENCE {
  1216.            wrap-header       Wrap-Header,
  1217.            wrap-body         Wrap-Body
  1218.    }
  1219.  
  1220.    Wrap-Header ::= SEQUENCE {
  1221.            tok-id           INTEGER (513),
  1222.                                 -- shall contain 0201 (hex)
  1223.            context-id       Random-Integer,
  1224.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  1225.                                 -- Integrity algorithm indicator (must
  1226.                                 -- be one of the agreed integrity
  1227.                                 -- algorithms for this context).
  1228.                                 -- field not present = default id.
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Adams                       Standards Track                    [Page 22]
  1235.  
  1236. RFC 2025                          SPKM                      October 1996
  1237.  
  1238.  
  1239.            conf-alg [1]     Conf-Alg OPTIONAL,
  1240.                                 -- Confidentiality algorithm indicator
  1241.                                 -- (must be NULL or one of the agreed
  1242.                                 -- confidentiality algorithms for this
  1243.                                 -- context).
  1244.                                 -- field not present = default id.
  1245.                                 -- NULL = none (no conf. applied).
  1246.            snd-seq [2]      SeqNum OPTIONAL
  1247.                                 -- sequence number field.
  1248.    }
  1249.  
  1250.  
  1251.  
  1252.    Wrap-Body ::= SEQUENCE {
  1253.            int-cksum        BIT STRING,
  1254.                                 -- Checksum of header and data,
  1255.                                 -- calculated according to algorithm
  1256.                                 -- specified in int-alg field.
  1257.            data             BIT STRING
  1258.                                 -- encrypted or plaintext data.
  1259.    }
  1260.  
  1261.    Conf-Alg ::= CHOICE {
  1262.            algId [0]        AlgorithmIdentifier,
  1263.            null [1]         NULL
  1264.    }
  1265.  
  1266.  
  1267. 3.2.2.1: Confounding
  1268.  
  1269.    As in [KRB5], an 8-byte random confounder is prepended to the data to
  1270.    compensate for the fact that an IV of zero is used for encryption.
  1271.    The result is referred to as the "confounded" data field.
  1272.  
  1273. 3.2.2.2. Checksum
  1274.  
  1275.    Checksum calculation procedure (common to all algorithms): Checksums
  1276.    are calculated over the plaintext data field, logically prepended by
  1277.    the bytes of the plaintext token header (wrap-header).  As with
  1278.    gss_sign() / gss_getMIC(), the result binds the data to the entire
  1279.    plaintext header, so as to minimize the possibility of malicious
  1280.    splicing.
  1281.  
  1282.    The examples for md5WithRSA and DES-MAC are exactly as specified in
  1283.    3.2.1.1.
  1284.  
  1285.    If int-alg specifies md5-DES-CBC and conf-alg specifies anything
  1286.    other than DES-CBC, then the checksum is computed according to
  1287.  
  1288.  
  1289.  
  1290. Adams                       Standards Track                    [Page 23]
  1291.  
  1292. RFC 2025                          SPKM                      October 1996
  1293.  
  1294.  
  1295.    3.2.1.1 and the result is stored in int-cksum.  However, if conf-alg
  1296.    specifies DES-CBC then the encryption and the integrity are done as
  1297.    follows.  An MD5 [RFC-1321] hash is computed over the plaintext data
  1298.    (prepended by the header).  This 16-byte value is appended to the
  1299.    concatenation of the "confounded" data and 1-8 padding bytes (the
  1300.    padding is as specified in [KRB5] for DES-CBC).  The result is then
  1301.    CBC encrypted using the DES-CBC subkey (see Section 2.4) and placed
  1302.    in the "data" field of Wrap-Body.  The final two blocks of ciphertext
  1303.    (i.e., the encrypted MD5 hash) are also placed in the int-cksum field
  1304.    of Wrap-Body as the integrity checksum.
  1305.  
  1306.    If int-alg specifies sum64-DES-CBC then conf-alg must specify DES-CBC
  1307.    (i.e., confidentiality must be requested by the calling application
  1308.    or SPKM will return an error).  Encryption and integrity are done in
  1309.    a single pass using the DES-CBC subkey as follows.  The sum (modulo
  1310.    2**64 - 1) of all plaintext data blocks (prepended by the header) is
  1311.    computed.  This 8-byte value is appended to the concatenation of the
  1312.    "confounded" data and 1-8 padding bytes (the padding is as specified
  1313.    in [KRB5] for DES-CBC).  As above, the result is then CBC encrypted
  1314.    and placed in the "data" field of Wrap-Body. The final block of
  1315.    ciphertext (i.e., the encrypted sum) is also placed in the int-cksum
  1316.    field of Wrap-Body as the integrity checksum.
  1317.  
  1318. 3.2.2.3 Sequence Number
  1319.  
  1320.    Sequence numbers are computed and processed for gss_wrap() exactly as
  1321.    specified in 3.2.1.2 and 3.2.1.3.
  1322.  
  1323. 3.2.2.4: Data Encryption
  1324.  
  1325.    The following procedure is followed unless (a) conf-alg is NULL (no
  1326.    encryption), or (b) conf-alg is DES-CBC and int-alg is md5-DES-CBC
  1327.    (encryption as specified in 3.2.2.2), or (c) int-alg is sum64-DES-CBC
  1328.    (encryption as specified in 3.2.2.2):
  1329.  
  1330.    The "confounded" data is padded and encrypted according to the
  1331.    algorithm specified in the conf-alg field.  The data is encrypted
  1332.    using CBC with an IV of zero.  The key used is the appropriate subkey
  1333.    derived from the established context key using the subkey derivation
  1334.    algorithm described in Section 2.4 (this ensures that the subkey used
  1335.    for encryption and the subkey used for a separate, keyed integrity
  1336.    algorithm -- for example DES-MAC, but not sum64-DES-CBC -- are
  1337.    different).
  1338.  
  1339. 3.2.3. Context deletion token
  1340.  
  1341.    The token emitted by gss_delete_sec_context() is based on the format
  1342.    for tokens emitted by gss_sign() / gss_getMIC().
  1343.  
  1344.  
  1345.  
  1346. Adams                       Standards Track                    [Page 24]
  1347.  
  1348. RFC 2025                          SPKM                      October 1996
  1349.  
  1350.  
  1351.    The SPKM-DEL token has the following format:
  1352.  
  1353.    SPKM-DEL ::= SEQUENCE {
  1354.            del-header       Del-Header,
  1355.            int-cksum        BIT STRING
  1356.                                 -- Checksum of header, calculated
  1357.                                 -- according to algorithm specified
  1358.                                 -- in int-alg field.
  1359.    }
  1360.  
  1361.    Del-Header ::= SEQUENCE {
  1362.            tok-id           INTEGER (769),
  1363.                                 -- shall contain 0301 (hex)
  1364.            context-id       Random-Integer,
  1365.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  1366.                                 -- Integrity algorithm indicator (must
  1367.                                 -- be one of the agreed integrity
  1368.                                 -- algorithms for this context).
  1369.                                 -- field not present = default id.
  1370.            snd-seq [1]      SeqNum OPTIONAL
  1371.                                 -- sequence number field.
  1372.    }
  1373.  
  1374.    The field snd-seq will be calculated as for tokens emitted by
  1375.    gss_sign() / gss_getMIC().  The field int-cksum will be calculated as
  1376.    for tokens emitted by gss_sign() / gss_getMIC(), except that the
  1377.    user-data component of the checksum data will be a zero-length
  1378.    string.
  1379.  
  1380.    If a valid delete token is received, then the SPKM implementation
  1381.    will delete the context and gss_process_context_token() will return a
  1382.    major status of GSS_S_COMPLETE and a minor status of
  1383.    GSS_SPKM_S_SG_CONTEXT_DELETED.  If, on the other hand, the delete
  1384.    token is invalid, the context will not be deleted and
  1385.    gss_process_context_token() will return the appropriate major status
  1386.    (GSS_S_BAD_SIG, for example) and a minor status of
  1387.    GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD.  The application may wish to
  1388.    take some action at this point to check the context status (such as
  1389.    sending a sealed/wrapped test message to its peer and waiting for a
  1390.    sealed/wrapped response).
  1391.  
  1392. 4. Name Types and Object Identifiers
  1393.  
  1394.    No mandatory name forms have yet been defined for SPKM.  This section
  1395.    is for further study.
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Adams                       Standards Track                    [Page 25]
  1403.  
  1404. RFC 2025                          SPKM                      October 1996
  1405.  
  1406.  
  1407. 4.1. Optional Name Forms
  1408.  
  1409.    This section discusses name forms which may optionally be supported
  1410.    by implementations of the SPKM GSS-API mechanism.  It is recognized
  1411.    that OS-specific functions outside GSS-API are likely to exist in
  1412.    order to perform translations among these forms, and that GSS-API
  1413.    implementations supporting these forms may themselves be layered atop
  1414.    such OS-specific functions.  Inclusion of this support within GSS-API
  1415.    implementations is intended as a convenience to applications.
  1416.  
  1417. 4.1.1. User Name Form
  1418.  
  1419.    This name form shall be represented by the Object Identifier {iso(1)
  1420.    member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
  1421.    generic(1) user_name(1)}.  The recommended symbolic name for this
  1422.    type is "GSS_SPKM_NT_USER_NAME".
  1423.  
  1424.    This name type is used to indicate a named user on a local system.
  1425.    Its interpretation is OS-specific.  This name form is constructed as:
  1426.  
  1427.       username
  1428.  
  1429. 4.1.2. Machine UID Form
  1430.  
  1431.    This name form shall be represented by the Object Identifier {iso(1)
  1432.    member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
  1433.    generic(1) machine_uid_name(2)}.  The recommended symbolic name for
  1434.    this type is "GSS_SPKM_NT_MACHINE_UID_NAME".
  1435.  
  1436.    This name type is used to indicate a numeric user identifier
  1437.    corresponding to a user on a local system.  Its interpretation is
  1438.    OS-specific.  The gss_buffer_desc representing a name of this type
  1439.    should contain a locally-significant uid_t, represented in host byte
  1440.    order.  The gss_import_name() operation resolves this uid into a
  1441.    username, which is then treated as the User Name Form.
  1442.  
  1443. 4.1.3. String UID Form
  1444.  
  1445.    This name form shall be represented by the Object Identifier {iso(1)
  1446.    member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
  1447.    generic(1) string_uid_name(3)}.  The recommended symbolic name for
  1448.    this type is "GSS_SPKM_NT_STRING_UID_NAME".
  1449.  
  1450.    This name type is used to indicate a string of digits representing
  1451.    the numeric user identifier of a user on a local system.  Its
  1452.    interpretation is OS-specific. This name type is similar to the
  1453.    Machine UID Form, except that the buffer contains a string
  1454.    representing the uid_t.
  1455.  
  1456.  
  1457.  
  1458. Adams                       Standards Track                    [Page 26]
  1459.  
  1460. RFC 2025                          SPKM                      October 1996
  1461.  
  1462.  
  1463. 5. Parameter Definitions
  1464.  
  1465.    This section defines parameter values used by the SPKM GSS-API
  1466.    mechanism.  It defines interface elements in support of portability.
  1467.  
  1468. 5.1. Minor Status Codes
  1469.  
  1470.    This section recommends common symbolic names for minor_status values
  1471.    to be returned by the SPKM GSS-API mechanism.  Use of these
  1472.    definitions will enable independent implementors to enhance
  1473.    application portability across different implementations of the
  1474.    mechanism defined in this specification.  (In all cases,
  1475.    implementations of gss_display_status() will enable callers to
  1476.    convert minor_status indicators to text representations.) Each
  1477.    implementation must make available, through include files or other
  1478.    means, a facility to translate these symbolic names into the concrete
  1479.    values which a particular GSS-API implementation uses to represent
  1480.    the minor_status values specified in this section.  It is recognized
  1481.    that this list may grow over time, and that the need for additional
  1482.    minor_status codes specific to particular implementations may arise.
  1483.  
  1484. 5.1.1. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET)
  1485.  
  1486. 5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET)
  1487.  
  1488.    GSS_S_G_VALIDATE_FAILED
  1489.        /* "Validation error" */
  1490.    GSS_S_G_BUFFER_ALLOC
  1491.        /* "Couldn't allocate gss_buffer_t data" */
  1492.    GSS_S_G_BAD_MSG_CTX
  1493.        /* "Message context invalid" */
  1494.    GSS_S_G_WRONG_SIZE
  1495.        /* "Buffer is the wrong size" */
  1496.    GSS_S_G_BAD_USAGE
  1497.        /* "Credential usage type is unknown" */
  1498.    GSS_S_G_UNAVAIL_QOP
  1499.        /* "Unavailable quality of protection specified" */
  1500.  
  1501. 5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF)
  1502.  
  1503.    GSS_S_G_MEMORY_ALLOC
  1504.        /* "Couldn't perform requested memory allocation" */
  1505.  
  1506. 5.1.2. SPKM-specific-codes (Minor Status Code MSB, bit 31, OFF)
  1507.  
  1508.    GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
  1509.        /* "Context is already fully established" */
  1510.    GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
  1511.  
  1512.  
  1513.  
  1514. Adams                       Standards Track                    [Page 27]
  1515.  
  1516. RFC 2025                          SPKM                      October 1996
  1517.  
  1518.  
  1519.        /* "Unknown integrity algorithm type in token" */
  1520.    GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE
  1521.        /* "Unknown confidentiality algorithm type in token" */
  1522.    GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
  1523.        /* "Unknown key establishment algorithm type in token" */
  1524.    GSS_SPKM_S_SG_CTX_INCOMPLETE
  1525.        /* "Attempt to use incomplete security context" */
  1526.    GSS_SPKM_S_SG_BAD_INT_ALG_SET
  1527.        /* "No integrity algorithm in common from offered set" */
  1528.    GSS_SPKM_S_SG_BAD_CONF_ALG_SET
  1529.        /* "No confidentiality algorithm in common from offered set" */
  1530.    GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET
  1531.        /* "No key establishment algorithm in common from offered set" */
  1532.    GSS_SPKM_S_SG_NO_PVNO_IN_COMMON
  1533.        /* "No protocol version number in common from offered set" */
  1534.    GSS_SPKM_S_SG_INVALID_TOKEN_DATA
  1535.        /* "Data is improperly formatted:  cannot encode into token" */
  1536.    GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT
  1537.        /* "Received token is improperly formatted:  cannot decode" */
  1538.    GSS_SPKM_S_SG_CONTEXT_DELETED
  1539.        /* "Context deleted at peer's request" */
  1540.    GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD
  1541.        /* "Invalid delete token received -- context not deleted" */
  1542.    GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT
  1543.       /* "Unrecoverable context establishment error. Context deleted" */
  1544.  
  1545. 5.2. Quality of Protection Values
  1546.  
  1547.    The Quality of Protection (QOP) parameter is used in the SPKM GSS-API
  1548.    mechanism as input to gss_sign() and gss_seal() (gss_getMIC() and
  1549.    gss_wrap()) to select among alternate confidentiality and integrity-
  1550.    checking algorithms.  Once these sets of algorithms have been agreed
  1551.    upon by the context initiator and target, the QOP parameter simply
  1552.    selects from these ordered sets.
  1553.  
  1554.    More specifically, the SPKM-REQ token sends an ordered sequence of
  1555.    Alg. IDs specifying integrity-checking algorithms supported by the
  1556.    initiator and an ordered sequence of Alg. IDs specifying
  1557.    confidentiality algorithms supported by the initiator.  The target
  1558.    returns the subset of the offered integrity-checking Alg. IDs which
  1559.    it supports and the subset of the offered confidentiality Alg. IDs
  1560.    which it supports in the SPKM-REP-TI token (in the same relative
  1561.    orders as those given by the initiator).  Thus, the initiator and
  1562.    target each know the algorithms which they themselves support and the
  1563.    algorithms which both sides support (the latter are defined to be
  1564.    those supported over the established context).  The QOP parameter has
  1565.    meaning and validity with reference to this knowledge.  For example,
  1566.    an application may request integrity algorithm number 3 as defined by
  1567.  
  1568.  
  1569.  
  1570. Adams                       Standards Track                    [Page 28]
  1571.  
  1572. RFC 2025                          SPKM                      October 1996
  1573.  
  1574.  
  1575.    the mechanism specification.  If this algorithm is supported over
  1576.    this context then it is used; otherwise, GSS_S_FAILURE and an
  1577.    appropriate minor status code are returned.
  1578.  
  1579.    If the SPKM-REP-TI token is not used (unilateral authentication using
  1580.    SPKM-2), then the "agreed" sets of Alg. IDs are simply taken to be
  1581.    the initiator's sets (if this is unacceptable to the target then it
  1582.    must return an error token so that the context is never established).
  1583.    Note that, in the interest of interoperability, the initiator is not
  1584.    required to offer every algorithm it supports; rather, it may offer
  1585.    only the mandated/recommended SPKM algorithms since these are likely
  1586.    to be supported by the target.
  1587.  
  1588.    The QOP parameter for SPKM is defined to be a 32-bit unsigned integer
  1589.    (an OM_uint32) with the following bit-field assignments:
  1590.  
  1591.  Confidentiality                     Integrity
  1592.  31 (MSB)                         16 15                         (LSB) 0
  1593. ------------------------------------|-----------------------------------
  1594. |  TS (5)  | U(3) | IA (4) | MA (4) |  TS (5)  | U(3) | IA (4) | MA(4) |
  1595. ------------------------------------|-----------------------------------
  1596.  
  1597.    where
  1598.  
  1599.       TS is a 5-bit Type Specifier (a semantic qualifier whose value
  1600.       specifies the type of algorithm which may be used to protect the
  1601.       corresponding token -- see below for details);
  1602.  
  1603.       U is a 3-bit Unspecified field (available for future
  1604.       use/expansion);
  1605.  
  1606.       IA is a 4-bit field enumerating Implementation-specific
  1607.       Algorithms; and
  1608.  
  1609.       MA is a 4-bit field enumerating Mechanism-defined Algorithms.
  1610.  
  1611.    The interpretation of the QOP parameter is as follows (note that the
  1612.    same procedure is used for both the confidentiality and the integrity
  1613.    halves of the parameter).  The MA field is examined first.  If it is
  1614.    non-zero then the algorithm used to protect the token is the
  1615.    mechanism-specified algorithm corresponding to that integer value.
  1616.  
  1617.    If MA is zero then IA is examined.  If this field value is non-zero
  1618.    then the algorithm used to protect the token is the implementation-
  1619.    specified algorithm corresponding to that integer value (if this
  1620.    algorithm is available over the established context).  Note that use
  1621.    of this field may hinder portability since a particular value may
  1622.    specify one algorithm in one implementation of the mechanism and may
  1623.  
  1624.  
  1625.  
  1626. Adams                       Standards Track                    [Page 29]
  1627.  
  1628. RFC 2025                          SPKM                      October 1996
  1629.  
  1630.  
  1631.    not be supported or may specify a completely different algorithm in
  1632.    another implementation of the mechanism.
  1633.  
  1634.    Finally, if both MA and IA are zero then TS is examined.  A value of
  1635.    zero for TS specifies the default algorithm for the established
  1636.    context, which is defined to be the first algorithm on the
  1637.    initiator's list of offered algorithms (confidentiality or integrity,
  1638.    depending on which half of QOP is being examined) which is supported
  1639.    over the context.  A non-zero value for TS corresponds to a
  1640.    particular algorithm qualifier and selects the first algorithm
  1641.    supported over the context which satisfies that qualifier.
  1642.  
  1643.    The following TS values (i.e., algorithm qualifiers) are specified;
  1644.    other values may be added in the future.
  1645.  
  1646.       For the Confidentiality TS field:
  1647.  
  1648.          00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
  1649.          00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
  1650.          00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK
  1651.  
  1652.       For the Integrity TS field:
  1653.  
  1654.          00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT
  1655.          00010 (2) = SPKM_INT_ALG_REPUDIABLE
  1656.  
  1657.    Clearly, qualifiers such as strong, medium, and weak are debatable
  1658.    and likely to change with time, but for the purposes of this version
  1659.    of the specification we define these terms as follows.  A
  1660.    confidentiality algorithm is "weak" if the effective key length of
  1661.    the cipher is 40 bits or less; it is "medium-strength" if the
  1662.    effective key length is strictly between 40 and 80 bits; and it is
  1663.    "strong" if the effective key length is 80 bits or greater.  (Note
  1664.    that "effective key length" describes the computational effort
  1665.    required to break a cipher using the best-known cryptanalytic attack
  1666.    against that cipher.)
  1667.  
  1668.    A five-bit TS field allows up to 31 qualifiers for each of
  1669.    confidentiality and integrity (since "0" is reserved for "default").
  1670.    This document specifies three for confidentiality and two for
  1671.    integrity, leaving a lot of room for future specification.
  1672.    Suggestions of qualifiers such as "fast", "medium-speed", and "slow"
  1673.    have been made, but such terms are difficult to quantify (and in any
  1674.    case are platform- and processor-dependent), and so have been left
  1675.    out of this initial specification.  The intention is that the TS
  1676.    terms be quantitative, environment-independent qualifiers of
  1677.    algorithms, as much as this is possible.
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Adams                       Standards Track                    [Page 30]
  1683.  
  1684. RFC 2025                          SPKM                      October 1996
  1685.  
  1686.  
  1687.    Use of the QOP structure as defined above is ultimately meant to be
  1688.    as follows.
  1689.  
  1690.     - TS values are specified at the GSS-API level and are therefore
  1691.       portable across mechanisms.  Applications which know nothing about
  1692.       algorithms are still able to choose "quality" of protection for
  1693.       their message tokens.
  1694.  
  1695.     - MA values are specified at the mechanism level and are therefore
  1696.       portable across implementations of a mechanism.  For example, all
  1697.       implementations of the Kerberos V5 GSS mechanism must support
  1698.  
  1699.          GSS_KRB5_INTEG_C_QOP_MD5     (value: 1)
  1700.          GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
  1701.          GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
  1702.  
  1703.       (Note that these Kerberos-specified integrity QOP values do not
  1704.       conflict with the QOP structure defined above.)
  1705.  
  1706.     - IA values are specified at the implementation level (in user
  1707.       documentation, for example) and are therefore typically non-
  1708.       portable.  An application which is aware of its own mechanism
  1709.       implementation and the mechanism implementation of its peer,
  1710.       however, is free to use these values since they will be perfectly
  1711.       valid and meaningful over that context and between those peers.
  1712.  
  1713.    The receiver of a token must pass back to its calling application a
  1714.    QOP parameter with all relevant fields set.  For example, if triple-
  1715.    DES has been specified by a mechanism as algorithm 8, then a receiver
  1716.    of a triple-DES-protected token must pass to its application (QOP
  1717.    Confidentiality TS=1, IA=0, MA=8).  In this way, the application is
  1718.    free to read whatever part of the QOP it understands (TS or IA/MA).
  1719.  
  1720.    To aid in implementation and interoperability, the following
  1721.    stipulation is made.  The set of integrity Alg. IDs sent by the
  1722.    initiator must contain at least one specifying an algorithm which
  1723.    computes a digital signature supporting non-repudiation, and must
  1724.    contain at least one specifying any other (repudiable) integrity
  1725.    algorithm.  The subset of integrity Alg. IDs returned by the target
  1726.    must also contain at least one specifying an algorithm which computes
  1727.    a digital signature supporting non-repudiation, and at least one
  1728.    specifying a repudiable integrity algorithm.
  1729.  
  1730.    The reason for this stipulation is to ensure that every SPKM
  1731.    implementation will provide an integrity service which supports non-
  1732.    repudiation and one which does not support non-repudiation.  An
  1733.    application with no knowledge of underlying algorithms can choose one
  1734.    or the other by passing (QOP Integrity TS=1, IA=MA=0) or (QOP
  1735.  
  1736.  
  1737.  
  1738. Adams                       Standards Track                    [Page 31]
  1739.  
  1740. RFC 2025                          SPKM                      October 1996
  1741.  
  1742.  
  1743.    Integrity TS=2, IA=MA=0).  Although an initiator who wishes to remain
  1744.    anonymous will never actually use the non-repudiable digital
  1745.    signature, this integrity service must be available over the context
  1746.    so that the target can use it if desired.
  1747.  
  1748.    Finally, in accordance with the MANDATORY and RECOMMENDED algorithms
  1749.    given in Section 2, the following QOP values are specified for SPKM.
  1750.  
  1751.    For the Confidentiality MA field:
  1752.  
  1753.       0001 (1) = DES-CBC
  1754.  
  1755.    For the Integrity MA field:
  1756.  
  1757.       0001 (1) = md5WithRSA
  1758.       0010 (2) = DES-MAC
  1759.  
  1760. 6. Support Functions
  1761.  
  1762.    This section describes a mandatory support function for SPKM-
  1763.    conformant implementations which may, in fact, be of value in all
  1764.    GSS-API mechanisms.  It makes use of the token-id and context-id
  1765.    information which is included in SPKM context-establishment, error,
  1766.    context-deletion, and per-message tokens.  The function is defined in
  1767.    the following section.
  1768.  
  1769. 6.1. SPKM_Parse_token call
  1770.  
  1771.    Inputs:
  1772.  
  1773.    o  input_token OCTET STRING
  1774.  
  1775.    Outputs:
  1776.  
  1777.    o  major_status INTEGER,
  1778.  
  1779.    o  minor_status INTEGER,
  1780.  
  1781.    o  mech_type OBJECT IDENTIFIER,
  1782.  
  1783.    o  token_type INTEGER,
  1784.  
  1785.    o  context_handle CONTEXT HANDLE,
  1786.  
  1787.  
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Adams                       Standards Track                    [Page 32]
  1795.  
  1796. RFC 2025                          SPKM                      October 1996
  1797.  
  1798.  
  1799.    Return major_status codes:
  1800.  
  1801.    o  GSS_S_COMPLETE indicates that the input_token could be parsed for
  1802.       all relevant fields.  The resulting values are stored in
  1803.       mech_type, token_type and context_handle, respectively (with NULLs
  1804.       in any parameters which are not relevant).
  1805.  
  1806.    o  GSS_S_DEFECTIVE_TOKEN indicates that either the token-id or the
  1807.       context-id (if it was expected) information could not be parsed.
  1808.       A non-NULL return value in token_type indicates that the latter
  1809.       situation occurred.
  1810.  
  1811.    o  GSS_S_NO_TYPE indicates that the token-id information could be
  1812.       parsed, but it did not correspond to any valid token_type.
  1813.  
  1814.       (Note that this major status code has not been defined for GSS in
  1815.       RFC-1508.  Until such a definition is made (if ever), SPKM
  1816.       implementations should instead return GSS_S_DEFECTIVE_TOKEN with
  1817.       both token_type and context_handle set to NULL.  This essentially
  1818.       implies that unrecognized token-id information is considered to be
  1819.       equivalent to token-id information which could not be parsed.)
  1820.  
  1821.    o  GSS_S_NO_CONTEXT indicates that the context-id could be parsed,
  1822.       but it did not correspond to any valid context_handle.
  1823.  
  1824.    o  GSS_S_FAILURE indicates that the mechanism type could not be
  1825.       parsed (for example, the token may be corrupted).
  1826.  
  1827.    SPKM_Parse_token() is used to return to an application the mechanism
  1828.    type, token type, and context handle which correspond to a given
  1829.    input token.  Since GSS-API tokens are meant to be opaque to the
  1830.    calling application, this function allows the application to
  1831.    determine information about the token without having to violate the
  1832.    opaqueness intention of GSS.  Of primary importance is the token
  1833.    type, which the application can then use to decide which GSS function
  1834.    to call in order to have the token processed.
  1835.  
  1836.    If all tokens are framed as suggested in RFC-1508, Appendix B
  1837.    (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this
  1838.    document), then any mechanism implementation should be able to return
  1839.    at least the mech_type parameter (the other parameters being NULL)
  1840.    for any uncorrupted input token.  If the mechanism implementation
  1841.    whose SPKM_Parse_token() function is being called does recognize the
  1842.    token, it can return token_type so that the application can
  1843.    subsequently call the correct GSS function.  Finally, if the
  1844.    mechanism provides a context-id field in its tokens (as SPKM does),
  1845.    then an implementation can map the context-id to a context_handle and
  1846.    return this to the application.  This is necessary for the situation
  1847.  
  1848.  
  1849.  
  1850. Adams                       Standards Track                    [Page 33]
  1851.  
  1852. RFC 2025                          SPKM                      October 1996
  1853.  
  1854.  
  1855.    where an application has multiple contexts open simultaneously, all
  1856.    using the same mechanism.  When an incoming token arrives, the
  1857.    application can use this function to determine not only which GSS
  1858.    function to call, but also which context_handle to use for the call.
  1859.    Note that this function does no cryptographic processing to determine
  1860.    the validity of tokens; it simply attempts to parse the mech_type,
  1861.    token_type, and context-id fields of any token it is given.  Thus, it
  1862.    is conceivable, for example, that an arbitrary buffer of data might
  1863.    start with random values which look like a valid mech_type and that
  1864.    SPKM_Parse_token() would return incorrect information if given this
  1865.    buffer.  While conceivable, however, such a situation is unlikely.
  1866.  
  1867.    The SPKM_Parse_token() function is mandatory for SPKM-conformant
  1868.    implementations, but it is optional for applications.  That is, if an
  1869.    application has only one context open and can guess which GSS
  1870.    function to call (or is willing to put up with some error codes),
  1871.    then it need never call SPKM_Parse_token().  Furthermore, if this
  1872.    function ever migrates up to the GSS-API level, then
  1873.    SPKM_Parse_token() will be deprecated at that time in favour of
  1874.    GSS_Parse_token(), or whatever the new name and function
  1875.    specification might be.  Note finally that no minor status return
  1876.    codes have been defined for this function at this time.
  1877.  
  1878. 6.2. The token_type Output Parameter
  1879.  
  1880.    The following token types are defined:
  1881.  
  1882.       GSS_INIT_TOKEN   = 1
  1883.       GSS_ACCEPT_TOKEN = 2
  1884.       GSS_ERROR_TOKEN  = 3
  1885.       GSS_SIGN_TOKEN   = GSS_GETMIC_TOKEN = 4
  1886.       GSS_SEAL_TOKEN   = GSS_WRAP_TOKEN   = 5
  1887.       GSS_DELETE_TOKEN = 6
  1888.  
  1889.    All SPKM mechanisms shall be able to perform the mapping from the
  1890.    token-id information which is included in every token (through the
  1891.    tag values in SPKMInnerContextToken or through the tok-id field) to
  1892.    one of the above token types.  Applications should be able to decide,
  1893.    on the basis of token_type, which GSS function to call (for example,
  1894.    if the token is a GSS_INIT_TOKEN then the application will call
  1895.    gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then
  1896.    the application will call gss_unwrap()).
  1897.  
  1898. 6.3. The context_handle Output Parameter
  1899.  
  1900.    The SPKM mechanism implementation is responsible for maintaining a
  1901.    mapping between the context-id value which is included in every token
  1902.    and a context_handle, thus associating an individual token with its
  1903.  
  1904.  
  1905.  
  1906. Adams                       Standards Track                    [Page 34]
  1907.  
  1908. RFC 2025                          SPKM                      October 1996
  1909.  
  1910.  
  1911.    proper context.  Clearly the value of context_handle may be locally
  1912.    determined and may, in fact, be associated with memory containing
  1913.    sensitive data on the local system, and so having the context-id
  1914.    actually be set equal to a computed context_handle will not work in
  1915.    general.  Conversely, having the context_handle actually be set equal
  1916.    to a computed context-id will not work in general either, because
  1917.    context_handle must be returned to the application by the first call
  1918.    to gss_init_sec_context() or gss_accept_sec_context(), whereas
  1919.    uniqueness of the context-id (over all contexts at both ends) may
  1920.    require that both initiator and target be involved in the
  1921.    computation.  Consequently, context_handle and context-id must be
  1922.    computed separately and the mechanism implementation must be able to
  1923.    map from one to the other by the completion of context establishment
  1924.    at the latest.
  1925.  
  1926.    Computation of context-id during context establishment is
  1927.    accomplished as follows.  Each SPKM implementation is responsible for
  1928.    generating a "fresh" random number; that is, one which (with high
  1929.    probability) has not been used previously.  Note that there are no
  1930.    cryptographic requirements on this random number (i.e., it need not
  1931.    be unpredictable, it simply needs to be fresh).  The initiator passes
  1932.    its random number to the target in the context-id field of the SPKM-
  1933.    REQ token.  If no further context establishment tokens are expected
  1934.    (as for unilateral authentication in SPKM-2), then this value is
  1935.    taken to be the context-id (if this is unacceptable to the target
  1936.    then an error token must be generated).  Otherwise, the target
  1937.    generates its random number and concatenates it to the end of the
  1938.    initiator's random number.  This concatenated value is then taken to
  1939.    be the context-id and is used in SPKM-REP-TI and in all subsequent
  1940.    tokens over that context.
  1941.  
  1942.    Having both peers contribute to the context-id assures each peer of
  1943.    freshness and therefore precludes replay attacks between contexts
  1944.    (where a token from an old context between two peers is maliciously
  1945.    injected into a new context between the same or different peers).
  1946.    Such assurance is not available to the target in the case of
  1947.    unilateral authentication using SPKM-2, simply because it has not
  1948.    contributed to the freshness of the computed context-id (instead, it
  1949.    must trust the freshness of the initiator's random number, or reject
  1950.    the context).  The key-src-bind field in SPKM-REQ is required to be
  1951.    present for the case of SPKM-2 unilateral authentication precisely to
  1952.    assist the target in trusting the freshness of this token (and its
  1953.    proposed context key).
  1954.  
  1955. 7. Security Considerations
  1956.  
  1957.    Security issues are discussed throughout this memo.
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Adams                       Standards Track                    [Page 35]
  1963.  
  1964. RFC 2025                          SPKM                      October 1996
  1965.  
  1966.  
  1967. 8. References
  1968.  
  1969.    [Davi89]:    D. W. Davies and W. L. Price, "Security for Computer
  1970.    Networks", Second Edition, John Wiley and Sons, New York, 1989.
  1971.  
  1972.    [FIPS-113]:  National Bureau of Standards, Federal Information
  1973.    Processing Standard 113, "Computer Data Authentication", May 1985.
  1974.  
  1975.    [GSSv2]:     Linn, J., "Generic Security Service Application Program
  1976.    Interface Version 2", Work in Progress.
  1977.  
  1978.    [Juen84]:    R. R. Jueneman, C. H. Meyer and S. M. Matyas, Message
  1979.    Authentication with Manipulation Detection Codes, in Proceedings of
  1980.    the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
  1981.    Society Press, 1984, pp.33-54.
  1982.  
  1983.    [KRB5]:      Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
  1984.    RFC 1964, June 1996.
  1985.  
  1986.    [PKCS1]:     RSA Encryption Standard, Version 1.5, RSA Data Security,
  1987.    Inc., Nov. 1993.
  1988.  
  1989.    [PKCS3]:     Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
  1990.    Data Security, Inc., Nov. 1993.
  1991.  
  1992.    [RFC-1321]:  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321.
  1993.  
  1994.    [RFC-1422]:  Kent, S., "Privacy Enhancement for Internet Electronic
  1995.    Mail:  Part II: Certificate-Based Key Management", RFC 1422.
  1996.  
  1997.    [RFC-1423]:  Balenson, D., "Privacy Enhancement for Internet
  1998.    Elecronic Mail: Part III: Algorithms, Modes, and Identifiers",
  1999.    RFC 1423.
  2000.  
  2001.    [RFC-1508]:  Linn, J., "Generic Security Service Application Program
  2002.    Interface", RFC 1508.
  2003.  
  2004.    [RFC-1509]:  Wray, J., "Generic Security Service Application Program
  2005.    Interface: C-bindings", RFC 1509.
  2006.  
  2007.    [RFC-1510]:  Kohl J., and C. Neuman, "The Kerberos Network
  2008.    Authentication Service (V5)", RFC 1510.
  2009.  
  2010.    [9798]:      ISO/IEC 9798-3, "Information technology - Security
  2011.    Techniques - Entity authentication mechanisms - Part 3:  Entitiy
  2012.    authentication using a public key algorithm", ISO/IEC, 1993.
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Adams                       Standards Track                    [Page 36]
  2019.  
  2020. RFC 2025                          SPKM                      October 1996
  2021.  
  2022.  
  2023.    [X.501]:     ISO/IEC 9594-2, "Information Technology - Open Systems
  2024.    Interconnection - The Directory:  Models", CCITT/ITU Recommendation
  2025.    X.501, 1993.
  2026.  
  2027.    [X.509]:     ISO/IEC 9594-8, "Information Technology - Open Systems
  2028.    Interconnection - The Directory:  Authentication Framework",
  2029.    CCITT/ITU Recommendation X.509, 1993.
  2030.  
  2031.    [X9.44]:     ANSI, "Public Key Cryptography Using Reversible
  2032.     Algorithms for the Financial Services Industry:  Transport of
  2033.    Symmetric Algorithm Keys Using RSA", X9.44-1993.
  2034.  
  2035. 9. Author's Address
  2036.  
  2037.    Carlisle Adams
  2038.    Bell-Northern Research
  2039.    P.O.Box 3511, Station C
  2040.    Ottawa, Ontario, CANADA  K1Y 4H7
  2041.  
  2042.    Phone: +1 613.763.9008
  2043.    EMail: cadams@bnr.ca
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Adams                       Standards Track                    [Page 37]
  2075.  
  2076. RFC 2025                          SPKM                      October 1996
  2077.  
  2078.  
  2079. Appendix A:  ASN.1 Module Definition
  2080.  
  2081. SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
  2082.                security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}
  2083.  
  2084.  
  2085. DEFINITIONS IMPLICIT TAGS ::=
  2086. BEGIN
  2087.  
  2088.  
  2089. -- EXPORTS ALL --
  2090.  
  2091.  
  2092. IMPORTS
  2093.  
  2094.    Name
  2095.       FROM InformationFramework {joint-iso-ccitt(2) ds(5) module(1)
  2096.                                 informationFramework(1) 2}
  2097.  
  2098.    Certificate, CertificateList, CertificatePair, AlgorithmIdentifier,
  2099.    Validity
  2100.       FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1)
  2101.                                    authenticationFramework(7) 2}  ;
  2102.  
  2103.  
  2104.  
  2105. -- types --
  2106.  
  2107.    SPKM-REQ ::= SEQUENCE {
  2108.            requestToken      REQ-TOKEN,
  2109.            certif-data [0]   CertificationData OPTIONAL,
  2110.            auth-data [1]     AuthorizationData OPTIONAL
  2111.    }
  2112.  
  2113.  
  2114.    CertificationData ::= SEQUENCE {
  2115.            certificationPath [0]          CertificationPath OPTIONAL,
  2116.            certificateRevocationList [1]  CertificateList OPTIONAL
  2117.    } -- at least one of the above shall be present
  2118.  
  2119.  
  2120.    CertificationPath ::= SEQUENCE {
  2121.            userKeyId [0]         OCTET STRING OPTIONAL,
  2122.            userCertif [1]        Certificate OPTIONAL,
  2123.            verifKeyId [2]        OCTET STRING OPTIONAL,
  2124.            userVerifCertif [3]   Certificate OPTIONAL,
  2125.            theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
  2126.    } -- Presence of [2] or [3] implies that [0] or [1] must also be
  2127.  
  2128.  
  2129.  
  2130. Adams                       Standards Track                    [Page 38]
  2131.  
  2132. RFC 2025                          SPKM                      October 1996
  2133.  
  2134.  
  2135.      -- present.  Presence of [4] implies that at least one of [0], [1],
  2136.      -- [2], and [3] must also be present.
  2137.  
  2138.    REQ-TOKEN ::= SEQUENCE {
  2139.            req-contents     Req-contents,
  2140.            algId            AlgorithmIdentifier,
  2141.            req-integrity    Integrity  -- "token" is Req-contents
  2142.    }
  2143.  
  2144.   Integrity ::= BIT STRING
  2145.      -- If corresponding algId specifies a signing algorithm,
  2146.      -- "Integrity" holds the result of applying the signing procedure
  2147.      -- specified in algId to the BER-encoded octet string which results
  2148.      -- from applying the hashing procedure (also specified in algId) to
  2149.      -- the DER-encoded octets of "token".
  2150.      -- Alternatively, if corresponding algId specifies a MACing
  2151.      -- algorithm, "Integrity" holds the result of applying the MACing
  2152.      -- procedure specified in algId to the DER-encoded octets of
  2153.      -- "token"
  2154.  
  2155.    Req-contents ::= SEQUENCE {
  2156.            tok-id           INTEGER (256),  -- shall contain 0100 (hex)
  2157.            context-id       Random-Integer,
  2158.            pvno             BIT STRING,
  2159.            timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
  2160.            randSrc          Random-Integer,
  2161.            targ-name        Name,
  2162.            src-name [0]     Name OPTIONAL,
  2163.            req-data         Context-Data,
  2164.            validity [1]     Validity OPTIONAL,
  2165.            key-estb-set     Key-Estb-Algs,
  2166.            key-estb-req     BIT STRING OPTIONAL,
  2167.            key-src-bind     OCTET STRING OPTIONAL
  2168.               -- This field must be present for the case of SPKM-2
  2169.               -- unilateral authen. if the K-ALG in use does not provide
  2170.               -- such a binding (but is optional for all other cases).
  2171.               -- The octet string holds the result of applying the
  2172.               -- mandatory hashing procedure (in MANDATORY I-ALG;
  2173.               -- see Section 2.1) as follows:  MD5(src || context_key),
  2174.               -- where "src" is the DER-encoded octets of src-name,
  2175.               -- "context-key" is the symmetric key (i.e., the
  2176.               -- unprotected version of what is transmitted in
  2177.               -- key-estb-req), and "||" is the concatenation operation.
  2178.    }
  2179.  
  2180.    Random-Integer ::= BIT STRING
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Adams                       Standards Track                    [Page 39]
  2187.  
  2188. RFC 2025                          SPKM                      October 1996
  2189.  
  2190.  
  2191.    Context-Data ::= SEQUENCE {
  2192.            channelId       ChannelId OPTIONAL,
  2193.            seq-number      INTEGER OPTIONAL,
  2194.            options         Options,
  2195.            conf-alg        Conf-Algs,
  2196.            intg-alg        Intg-Algs,
  2197.            owf-alg         OWF-Algs
  2198.    }
  2199.  
  2200.    ChannelId ::= OCTET STRING
  2201.  
  2202.    Options ::= BIT STRING {
  2203.            delegation-state (0),
  2204.            mutual-state (1),
  2205.            replay-det-state (2),
  2206.            sequence-state (3),
  2207.            conf-avail (4),
  2208.            integ-avail (5),
  2209.            target-certif-data-required (6)
  2210.    }
  2211.  
  2212.    Conf-Algs ::= CHOICE {
  2213.            algs [0]         SEQUENCE OF AlgorithmIdentifier,
  2214.            null [1]         NULL
  2215.    }
  2216.  
  2217.    Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
  2218.  
  2219.    OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
  2220.  
  2221.    Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
  2222.  
  2223.  
  2224.    SPKM-REP-TI ::= SEQUENCE {
  2225.            responseToken    REP-TI-TOKEN,
  2226.            certif-data      CertificationData OPTIONAL
  2227.              -- present if target-certif-data-required option was
  2228.    }         -- set to TRUE in SPKM-REQ
  2229.  
  2230.    REP-TI-TOKEN ::= SEQUENCE {
  2231.            rep-ti-contents  Rep-ti-contents,
  2232.            algId            AlgorithmIdentifier,
  2233.            rep-ti-integ     Integrity  -- "token" is Rep-ti-contents
  2234.    }
  2235.  
  2236.    Rep-ti-contents ::= SEQUENCE {
  2237.            tok-id           INTEGER (512),   -- shall contain 0200 (hex)
  2238.            context-id       Random-Integer,
  2239.  
  2240.  
  2241.  
  2242. Adams                       Standards Track                    [Page 40]
  2243.  
  2244. RFC 2025                          SPKM                      October 1996
  2245.  
  2246.  
  2247.            pvno [0]         BIT STRING OPTIONAL,
  2248.            timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
  2249.            randTarg         Random-Integer,
  2250.            src-name [1]     Name OPTIONAL,
  2251.            targ-name        Name,
  2252.            randSrc          Random-Integer,
  2253.            rep-data         Context-Data,
  2254.            validity [2]     Validity  OPTIONAL,
  2255.            key-estb-id      AlgorithmIdentifier OPTIONAL,
  2256.            key-estb-str     BIT STRING OPTIONAL
  2257.    }
  2258.  
  2259.  
  2260.    SPKM-REP-IT ::= SEQUENCE {
  2261.            responseToken    REP-IT-TOKEN,
  2262.            algId            AlgorithmIdentifier,
  2263.            rep-it-integ     Integrity  -- "token" is REP-IT-TOKEN
  2264.    }
  2265.  
  2266.    REP-IT-TOKEN ::= SEQUENCE {
  2267.            tok-id           INTEGER (768),  -- shall contain 0300 (hex)
  2268.            context-id       Random-Integer,
  2269.            randSrc          Random-Integer,
  2270.            randTarg         Random-Integer,
  2271.            targ-name        Name,
  2272.            src-name         Name OPTIONAL,
  2273.            key-estb-rep     BIT STRING OPTIONAL
  2274.    }
  2275.  
  2276.    SPKM-ERROR ::= SEQUENCE {
  2277.            errorToken       ERROR-TOKEN,
  2278.            algId            AlgorithmIdentifier,
  2279.            integrity        Integrity  -- "token" is ERROR-TOKEN
  2280.    }
  2281.  
  2282.    ERROR-TOKEN ::=   SEQUENCE {
  2283.            tok-id           INTEGER (1024), -- shall contain 0400 (hex)
  2284.            context-id       Random-Integer
  2285.    }
  2286.  
  2287.    SPKM-MIC ::= SEQUENCE {
  2288.            mic-header       Mic-Header,
  2289.            int-cksum        BIT STRING
  2290.    }
  2291.  
  2292.    Mic-Header ::= SEQUENCE {
  2293.            tok-id           INTEGER (257), -- shall contain 0101 (hex)
  2294.            context-id       Random-Integer,
  2295.  
  2296.  
  2297.  
  2298. Adams                       Standards Track                    [Page 41]
  2299.  
  2300. RFC 2025                          SPKM                      October 1996
  2301.  
  2302.  
  2303.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  2304.            snd-seq [1]      SeqNum OPTIONAL
  2305.    }
  2306.  
  2307.    SeqNum ::= SEQUENCE {
  2308.            num              INTEGER,
  2309.            dir-ind          BOOLEAN
  2310.    }
  2311.  
  2312.    SPKM-WRAP ::= SEQUENCE {
  2313.            wrap-header       Wrap-Header,
  2314.            wrap-body         Wrap-Body
  2315.    }
  2316.  
  2317.    Wrap-Header ::= SEQUENCE {
  2318.            tok-id           INTEGER (513), -- shall contain 0201 (hex)
  2319.            context-id       Random-Integer,
  2320.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  2321.            conf-alg [1]     Conf-Alg OPTIONAL,
  2322.            snd-seq [2]      SeqNum OPTIONAL
  2323.    }
  2324.  
  2325.    Wrap-Body ::= SEQUENCE {
  2326.            int-cksum        BIT STRING,
  2327.            data             BIT STRING
  2328.    }
  2329.  
  2330.    Conf-Alg ::= CHOICE {
  2331.            algId [0]        AlgorithmIdentifier,
  2332.            null [1]         NULL
  2333.    }
  2334.  
  2335.  
  2336.    SPKM-DEL ::= SEQUENCE {
  2337.            del-header       Del-Header,
  2338.            int-cksum        BIT STRING
  2339.    }
  2340.  
  2341.    Del-Header ::= SEQUENCE {
  2342.            tok-id           INTEGER (769), -- shall contain 0301 (hex)
  2343.            context-id       Random-Integer,
  2344.            int-alg [0]      AlgorithmIdentifier OPTIONAL,
  2345.            snd-seq [1]      SeqNum OPTIONAL
  2346.    }
  2347.  
  2348.  
  2349. -- other types --
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Adams                       Standards Track                    [Page 42]
  2355.  
  2356. RFC 2025                          SPKM                      October 1996
  2357.  
  2358.  
  2359.    -- from [RFC-1508] --
  2360.  
  2361.    MechType ::= OBJECT IDENTIFIER
  2362.  
  2363.    InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
  2364.       thisMech              MechType,
  2365.       innerContextToken     SPKMInnerContextToken
  2366.    }     -- when thisMech is SPKM-1 or SPKM-2
  2367.  
  2368.    SPKMInnerContextToken ::= CHOICE {
  2369.       req    [0] SPKM-REQ,
  2370.       rep-ti [1] SPKM-REP-TI,
  2371.       rep-it [2] SPKM-REP-IT,
  2372.       error  [3] SPKM-ERROR,
  2373.       mic    [4] SPKM-MIC,
  2374.       wrap   [5] SPKM-WRAP,
  2375.       del    [6] SPKM-DEL
  2376.    }
  2377.  
  2378.  
  2379.    -- from [RFC-1510] --
  2380.  
  2381.    AuthorizationData ::= SEQUENCE OF SEQUENCE {
  2382.      ad-type  INTEGER,
  2383.      ad-data  OCTET STRING
  2384.    }
  2385.  
  2386.  
  2387. -- object identifier assignments --
  2388.  
  2389.    md5-DES-CBC OBJECT IDENTIFIER ::=
  2390.       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
  2391.        integrity(3) md5-DES-CBC(1)}
  2392.  
  2393.    sum64-DES-CBC OBJECT IDENTIFIER ::=
  2394.       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
  2395.        integrity(3) sum64-DES-CBC(2)}
  2396.  
  2397.    spkm-1 OBJECT IDENTIFIER ::=
  2398.       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
  2399.        mechanisms(5) spkm(1) spkm-1(1)}
  2400.  
  2401.    spkm-2 OBJECT IDENTIFIER ::=
  2402.       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
  2403.        mechanisms(5) spkm(1) spkm-2(2)}
  2404.  
  2405.  
  2406. END
  2407.  
  2408.  
  2409.  
  2410. Adams                       Standards Track                    [Page 43]
  2411.  
  2412. RFC 2025                          SPKM                      October 1996
  2413.  
  2414.  
  2415. Appendix B:  Imported Types
  2416.  
  2417.    This appendix contains, for completeness, the relevant ASN.1 types
  2418.    imported from InformationFramework (1993), AuthenticationFramework
  2419.    (1993), and [PKCS3].
  2420.  
  2421.    AttributeType ::= OBJECT IDENTIFIER
  2422.    AttributeValue ::= ANY
  2423.    AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
  2424.    RelativeDistinguishedName ::= SET OF AttributeValueAssertion
  2425.       -- note that the 1993 InformationFramework module uses
  2426.       -- different syntax for the above constructs
  2427.    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
  2428.    DistinguishedName ::= RDNSequence
  2429.    Name ::= CHOICE {  -- only one for now
  2430.            rdnSequence       RDNSequence
  2431.    }
  2432.  
  2433.    Certificate ::= SEQUENCE {
  2434.            certContents      CertContents,
  2435.            algID             AlgorithmIdentifier,
  2436.            sig               BIT STRING
  2437.    }  -- sig holds the result of applying the signing procedure
  2438.       -- specified in algId to the BER-encoded octet string which
  2439.       -- results from applying the hashing procedure (also specified in
  2440.       -- algId) to the DER-encoded octets of CertContents
  2441.  
  2442.    CertContents ::= SEQUENCE {
  2443.            version [0]        Version DEFAULT v1,
  2444.            serialNumber       CertificateSerialNumber,
  2445.            signature          AlgorithmIdentifier,
  2446.            issuer             Name,
  2447.            validity           Validity,
  2448.            subject            Name,
  2449.            subjectPublicKeyInfo     SubjectPublicKeyInfo,
  2450.            issuerUID [1]      IMPLICIT UID OPTIONAL,  -- used in v2 only
  2451.            subjectUID [2]     IMPLICIT UID OPTIONAL   -- used in v2 only
  2452.    }
  2453.  
  2454.    Version ::= INTEGER {v1(0), v2(1)}
  2455.    CertificateSerialNumber ::= INTEGER
  2456.    UID ::= BIT STRING
  2457.  
  2458.    Validity ::= SEQUENCE {
  2459.            notBefore         UTCTime,
  2460.            notAfter          UTCTime
  2461.    }
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Adams                       Standards Track                    [Page 44]
  2467.  
  2468. RFC 2025                          SPKM                      October 1996
  2469.  
  2470.  
  2471.    SubjectPublicKeyInfo ::= SEQUENCE {
  2472.            algorithm         AlgorithmIdentifier,
  2473.            subjectPublicKey  BIT STRING
  2474.    }
  2475.  
  2476.    CertificatePair ::= SEQUENCE {
  2477.            forward [0]      Certificate OPTIONAL,
  2478.            reverse [1]      Certificate OPTIONAL
  2479.    }         -- at least one of the pair shall be present
  2480.  
  2481.    CertificateList ::= SEQUENCE {
  2482.            certListContents        CertListContents,
  2483.            algId                   AlgorithmIdentifier,
  2484.            sig                     BIT STRING
  2485.    }  -- sig holds the result of applying the signing procedure
  2486.       -- specified in algId to the BER-encoded octet string which
  2487.       -- results from applying the hashing procedure (also specified in
  2488.       -- algId) to the DER-encoded octets of CertListContents
  2489.  
  2490.    CertListContents ::= SEQUENCE {
  2491.            signature               AlgorithmIdentifier,
  2492.            issuer                  Name,
  2493.            thisUpdate              UTCTime,
  2494.            nextUpdate              UTCTime OPTIONAL,
  2495.            revokedCertificates     SEQUENCE OF SEQUENCE {
  2496.                 userCertificate       CertificateSerialNumber,
  2497.                 revocationDate        UTCTime           } OPTIONAL
  2498.    }
  2499.  
  2500.    AlgorithmIdentifier ::= SEQUENCE {
  2501.            algorithm         OBJECT IDENTIFIER,
  2502.            parameter         ANY DEFINED BY algorithm OPTIONAL
  2503.    }  -- note that the 1993 AuthenticationFramework module uses
  2504.       -- different syntax for this construct
  2505.  
  2506.  
  2507.  
  2508.    --from [PKCS3] (the parameter to be used with dhKeyAgreement) --
  2509.  
  2510.    DHParameter ::= SEQUENCE {
  2511.      prime              INTEGER,  -- p
  2512.      base               INTEGER,  -- g
  2513.      privateValueLength INTEGER OPTIONAL
  2514.    }
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Adams                       Standards Track                    [Page 45]
  2523.  
  2524.