[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 2025

Internet Draft                          C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-01.txt                           October 30, 1994


              The Simple Public-Key GSS-API Mechanism (SPKM)



STATUS OF THIS MEMO

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

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

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

   Comments on this document should be sent to "cat-ietf@mit.edu", the
   IETF Common Authentication Technology WG discussion list.


ABSTRACT

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using the Simple Public-Key Mechanism.


BACKGROUND

   Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
   well-established in many environments, it is important in some
   applications to have a GSS-API mechanism which is based on a public-
   key, rather than a symmetric-key, infrastructure.  One such mechanism
   was described as part of the Distributed Authentication Security
   Service (DASS) in [RFC-1507].  However, the mechanism described in
   this document has been proposed as an alternative to the DASS
   mechanism for several reasons.

      1)  The SPKM is simpler than DASS, containing no non-essential
          functionality.




Adams                Document Expiration: 30 April 1995                1

      2)  The SPKM allows both unilateral and mutual authentication
          to be accomplished without the use of secure timestamps,
          whereas DASS requires timestamps for replay detection.  This
          enables environments which do not have access to secure time
          to nevertheless have access to secure authentication.

      3)  The SPKM uses Algorithm Identifiers to specify various
          algorithms to be used by the communicating peers.  This allows
          maximum flexibility for a variety of environments, for future
          enhancements, and for alternative algorithms.

      4)  The SPKM allows the option of a true, asymmetric algorithm-
          based, digital signature in the gss_sign() and gss_seal()
          operations, whereas DASS uses an integrity checksum based on a
          MAC computed with a symmetric algorithm (DES).  For some
          environments, the availability of true, non-repudiable digital
          signatures is a necessity.

      5)  SPKM data formats and procedures are designed to be as similar
          to those for the Kerberos mechanism as is practical.  This is
          done for ease of implementation in those environments where
          Kerberos has already been implemented.

   For the above reasons, it is felt that the SPKM will offer greater
   flexibility and functionality than DASS, without undue complexity or
   overhead.


KEY MANAGEMENT

   The key management employed in SPKM is intended to be as compatible
   as possible with both X.509 [X.509] and PEM [RFC-1422], since these
   represent large communities of interest and show relative maturity in
   standards.


ACKNOWLEDGMENTS

   Much of the material in this document is based on the Kerberos
   Version 5 GSS-API mechanism [KRB5], and is intended to be as
   compatible with it as possible.  This document also owes a great debt
   to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
   many fruitful discussions, to Kelvin Desplanque of Domus Software
   for implementation-related clarifications, and to John Linn of
   OpenVision Technologies for helpful comments.











Adams                Document Expiration: 30 April 1995                2
1. OVERVIEW

   The goal of the Generic Security Service Application Program
   Interface (GSS-API) is stated in the abstract of [RFC-1508] as
   follows:

     "This Generic Security Service Application Program Interface (GSS-
      API) definition provides security services to callers in a generic
      fashion, supportable with a range of underlying mechanisms and
      technologies and hence allowing source-level portability of
      applications to different environments. This specification defines
      GSS-API services and primitives at a level independent of
      underlying mechanism and programming language environment, and is
      to be complemented by other, related specifications:

       - documents defining specific parameter bindings for particular
         language environments;

       - documents defining token formats, protocols, and procedures to
         be implemented in order to realize GSS-API services atop
         particular security mechanisms."

   The SPKM is an instance of the latter type of document and is
   therefore termed a "GSS-API Mechanism".  This mechanism provides
   authentication, key establishment, data integrity, and data
   confidentiality in an on-line distributed application environment
   using a public-key infrastructure.  Because it conforms to the
   interface defined by [RFC-1508], SPKM can be used as a drop-in
   replacement by any application which makes use of security services
   through GSS-API calls (for example, any application which already
   uses the Kerberos GSS-API for security).  The use of a public-key
   infrastructure allows non-repudiable digital signatures to be
   employed for message exchanges, and provides other benefits such as
   scalability to large user populations.

   The tokens defined in SPKM are intended to be used by application
   programs according to the GSS API "operational paradigm" (see
   [RFC-1508] for further details):

      The operational paradigm in which GSS-API operates is as follows.
      A typical GSS-API caller is itself a communications protocol [or
      is an application program which uses a communications protocol],
      calling on GSS-API in order to protect its communications with
      authentication, integrity, and/or confidentiality security
      services.  A GSS-API caller accepts tokens provided to it by its
      local GSS-API implementation [i.e., its GSS-API mechanism] and
      transfers the tokens to a peer on a remote system; that peer
      passes the received tokens to its local GSS-API implementation for
      processing.

   This document defines two separate GSS-API mechanisms, SPKM-1 and
   SPKM-2, which are identical except that SPKM-2 requires the presence
   of secure timestamps for the purpose of replay detection during
   context establishment and SPKM-1 does not.  This allows greater
   flexibility for applications since secure timestamps cannot always
   be guaranteed to be available in a given environment.

Adams                Document Expiration: 30 April 1995                3
2. ALGORITHMS

   A number of algorithm types are employed in SPKM.  Each type, along
   with its purpose and a set of specific examples, is described in this
   section.

2.1 Integrity Algorithm (I-ALG):

       Purpose:

         This algorithm is used to ensure that a message has not been
         altered in any way after being constructed by the legitimate
         sender.  Depending on the algorithm used, the application of
         this algorithm may also provide authenticity and non-
         repudiability for the message.

       Examples:

         md5WithRSA OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 3
         }

            This algorithm provides data integrity and non-repudiation
            by computing an RSA signature on the MD5 hash of that data.
            Note that this is equivalent to md5WithRSAEncryption {1 2
            840 113549 1 1 4}, which is defined in [PKCS1].



         DES-MAC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 10
         }

            This algorithm provides data integrity by computing a DES
            MAC (as specified by [FIPS-113]) on that data.



         md5-DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) xx
         }

            This algorithm provides data integrity by encrypting, using
            DES CBC, the MD5 hash of that data.  This will typically be
            faster in practice than computing a DES MAC if the input
            data is not extremely short (e.g., a few bytes).  Note that
            the strength of this integrity mechanism is (at most) equal
            to the strength of DES under a known-plaintext attack.



         sum64-DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) xx
         }

Adams                Document Expiration: 30 April 1995                4

            This algorithm provides data integrity by encrypting, using
            DES CBC, the concatenation of the data and the sum of all
            the input data blocks (the sum computed using addition
            modulo 2**64 - 1).  Thus, in this algorithm, encryption is a
            requirement for the integrity to be secure.

            For comments regarding the security of this mechanism, see
            [Juen84, Davi89].


2.2 Sequence Algorithm (S-ALG):

       Purpose:

         This symmetric algorithm is used to generate the encrypted
         sequence number for a token.  Because the input to the
         integrity checksum (computed using an I-ALG) includes the
         encrypted sequence number, an invalid message with a valid
         sequence number, and a valid message with an invalid sequence
         number will both be detected.  (Note that here an invalid
         sequence number is one which decrypts to a value that the
         receiver was not expecting and an invalid message is one
         which causes the integrity check to fail.)

       Example:

         DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 7               -- carries IV as a parameter
         }


2.3 Confidentiality Algorithm (C-ALG):

       Purpose:

         This symmetric algorithm is used to generate the encrypted
         data for gss_seal().

       Example:

         DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 7               -- carries IV as a parameter
         }











Adams                Document Expiration: 30 April 1995                5

2.4 Key Establishment Algorithm (K-ALG):

       Purpose:

         This algorithm is used to establish a symmetric key for use
         by both the initiator and the target over the established
         context.  The keys used for S-ALG, C-ALG, and any keyed
         I-ALGs (for example, DES-MAC) are derived from this context
         key.  As will be seen in Section 3.1, key establishment is
         done within the X.509 authentication exchange and so the
         resulting symmetric key is authenticated.

       Example:

         id-rsa-key-transport OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14)
            secsig(3) algorithm(2) 22        -- imported from [X9.44]
         }

            In this algorithm, the context key is generated by the
            initiator, encrypted with the RSA public key of the target,
            and sent to the target.  The target need not respond to the
            initiator for the key to be established.


        dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
        }

            In this algorithm, the context key is generated jointly by
            the initiator and the target using the Diffie-Hellman key
            establishment algorithm.  The target must therefore respond
            to the initiator for the key to be established (so this
            K-ALG cannot be used with unilateral authentication in
            SPKM-2 (see Section 3.1)).



   During context establishment in SPKM, the initiator offers a set of
   possible symmetric encryption algorithms and a set of possible
   integrity algorithms to the target.  The symmetric algorithms
   selected by the target become ones that may be used for S-ALG and
   C-ALG over the established context.  The integrity algorithms
   selected by the target become ones that may be used for I-ALG over
   the established context.  Note that the order of the selected
   integrity algorithms defines the values of the Quality of Protection
   (QOP) parameter used in the gss_sign() and gss_seal() calls -- see
   Section 5.2 for further details.  Note also that if no response is
   expected from the target (unilateral authentication in SPKM-2) then
   the algorithms offered by the initiator are the ones that may be used
   over the context (if this is unacceptable to the target then an error
   message must be sent to the initiator so that the context is never
   established).


Adams                Document Expiration: 30 April 1995                6

   Furthermore, in the first context establishment token the initiator
   offers a set of possible K-ALGs, along with the key (or key half)
   corresponding to the first algorithm in the set (its preferred
   algorithm).  If this K-ALG is unacceptable to the target it must
   choose one of the other K-ALGs in the set and send this choice along
   with the key (or key half) corresponding to this choice in its
   response (otherwise an error token must be sent so that the context
   is never established).  If necessary (that is, if the target chooses
   a 2-pass K-ALG such as dhKeyAgreement), the initiator will send its
   key half in a response to the target.

   In future versions of SPKM, other algorithms may be specified for any
   or all of I-ALG, S-ALG, C-ALG, and K-ALG.


3. TOKEN FORMATS

   This section discusses protocol-visible characteristics of the GSS-
   API mechanism to be implemented atop the SPKM; it defines elements of
   protocol for interoperability and is independent of language bindings
   per [RFC-1509].

   The SPKM GSS-API mechanism will be identified by an Object Identifier
   representing "SPKM-1" or "SPKM-2", having the value:

   {iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)}
   or
   {iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)},

   where SPKM-1 uses random numbers for replay detection during context
   establishment and SPKM-2 uses timestamps.

   Tokens transferred between GSS-API peers (for security context
   management and per-message protection purposes) are defined.


3.1. Context Establishment Tokens

   Three classes of tokens are defined in this section:  "Initiator"
   tokens, emitted by calls to gss_init_sec_context() and consumed by
   calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
   to gss_accept_sec_context() and consumed by calls to
   gss_init_sec_context(); and "Error" tokens, potentially emitted by
   calls to gss_init_sec_context(), gss_accept_sec_context(),
   gss_delete_sec_context(), gss_process_context_token(), gss_verify(),
   and gss_unseal() and consumed by calls to
   gss_process_context_token().


   Per RFC-1508, Appendix B, the initial context establishment token
   will be enclosed within framing as follows:





Adams                Document Expiration: 30 April 1995                7

   InitialContextToken ::=
   [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "SPKM-1" or "SPKM-2"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific
           }

   The innerContextToken of the initial context token will consist of an
   SPKM_REQ message containing a token-id (TOK_ID) field which shall
   contain the value 0100 (hex).


   The above GSS-API framing shall be applied to all tokens emitted by
   the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT,
   SPKM_ERROR, context-deletion, and per-message tokens, not just to
   the initial token in a context establishment sequence.  While not
   required by RFC-1508, this enables implementations to perform
   enhanced error-checking. The innerContextToken field of context
   establishment tokens for the SPKM GSS-API mechanism will consist of a
   message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing
   a TOK_ID field having the value 0100 (hex) for SPKM_REQ messages,
   0200 (hex) for SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT
   messages, and 0400 (hex) for SPKM_ERROR messages.  All
   innerContextTokens are encoded using Abstract Syntax Notation One
   Basic Encoding Rules (ASN.1 BER).

   The SPKM context establishment tokens are defined according to
   [X.509] Section 10.  SPKM-1 (random numbers) uses Section 10.3, "Two-
   way Authentication", when performing unilateral authentication of the
   target to the initiator and uses Section 10.4, "Three-way Authentica-
   tion", when mutual authentication is requested by the initiator.
   SPKM-2 (timestamps) uses Section 10.2, "One-way Authentication", when
   performing unilateral authentication of the initiator to the target
   and uses Section 10.3, "Two-way Authentication", when mutual authen-
   tication is requested by the initiator.

   The implication of the above paragraph is that for SPKM-2 unilateral
   authentication no negotiation of K-ALG can be done (the target either
   accepts the K-ALG given by the initiator or disallows the context).
   For SPKM-2 mutual or SPKM-1 unilateral authentication some negotia-
   tion is possible, but the target can only choose among the one-pass
   K-ALGs offered by the initiator (or disallow the context).  For
   SPKM-1 mutual authentication the target can choose any one- or two-
   pass K-ALG offered by the initiator.

   It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
   mutual authentication.  Although unilateral authentication is avail-
   able for both mechanisms, its use is not generally recommended.






Adams                Document Expiration: 30 April 1995                8

3.1.1. Context Establishment Tokens - Initiator (first token)

   In order to accomplish context establishment, it is necessary that
   both the initiator and the target have access to the other party?s
   encryption and verfication certificate(s).  In some environments the
   initiator may choose to acquire all certificates and send the
   relevant ones to the target in the first token.  In other environ-
   ments each side may individually obtain the certificate data it
   needs.  In either case, however, the SPKM implementation must have
   the ability to obtain certificates which correspond to a supplied
   Name.  The actual mechanism to be used to achieve this is a local
   implementation matter and is therefore outside the scope of this
   specification.



   Relevant SPKM_REQ syntax is as follows (note that imports from other
   documents are given in Appendix A):


   SPKM-REQ ::= SEQUENCE {
           requestToken [0] REQ_TOKEN
           certif_data [1]  CertificationData OPTIONAL
           auth_data [2]    AuthorizationData OPTIONAL
                         -- see [RFC-1510] for a discussion of auth-data
   }


   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath
           certificateRevocationList [1]  CertificateList OPTIONAL
           }


   CertificationPath ::= SEQUENCE {
           userEncCertif [0]     SingleCertificate
           userVerifCertif [1]   SingleCertificate OPTIONAL
                        -- may send separate verification certificate
                        -- to allow different algorithms to be used for
                        -- decryption and signing
           theCACertificates [2] SEQUENCE OF CertificatePair OPTIONAL
           }            -- certif. path from target to source


   SingleCertificate ::= CHOICE {               -- only one for now
           Certificate                          -- imported from [X.509]
           }                                    -- (1993)









Adams                Document Expiration: 30 April 1995                9

   REQ_TOKEN ::= SIGNED SEQUENCE {
           tok_id [0]       INTEGER  -- shall contain 0100 (hex)
           timestamp [1]    UTCTime  -- may be NULL for mechanism SPKM-1
           randSrc [2]      Random_Integer,
           targ_name [3]    Name,
           src_name [4]     Name,
           req_data [5]     Context_Data,
           validity [6]     Validity  OPTIONAL
              -- validity interval for key (may be used in the
              -- computation of security context lifetime)
           key_estb_set [7] Key_Estb_Alg
              -- specifies set of key establishment algorithms
           key_estb_req [8] BIT STRING
              -- key estb. request corresponding to first K-ALG in set
   }


   Random_Integer ::= BIT STRING

   Context_Data ::= SEQUENCE {
           channelId [0]   ChannelId,           -- channel bindings
           seq_number [1]  INTEGER OPTIONAL     -- sequence number
           options [2]     Options
           symm_alg [3]    Symm_Alg             -- symmetric enc. alg.
           intg_alg [4]    Intg_Alg             -- integrity algorithm
   }

   ChannelId ::= OCTET STRING

   Options ::= BIT STRING {
           delegation_state (0),
           mutual_state (1),
           replay_det_state (2),
           sequence_state (3),
           conf_avail (4),
           integ_avail (5)
   }


   Symm_Alg ::= SEQUENCE OF AlgorithmIdentifier -- for S-ALG, C-ALG
                                                -- (first id. in agreed
                                                -- set is default alg.
                                                -- for context)


   Intg_Alg ::= SEQUENCE OF AlgorithmIdentifier -- order of agreed seq.
                                                -- is constrained by
                                                -- semantics of QOP
                                                -- parameter (see 5.2)

   Key_Estb_Alg ::= SEQUENCE OF AlgorithmIdentifier
                                                -- to allow negotiation
                                                -- of K-ALG



Adams                Document Expiration: 30 April 1995               10

   A context establishment sequence based on the SPKM will perform uni-
   lateral authentication if the mutual_req bit is not set in the
   application's call to gss_init_sec_context().  SPKM-2 accomplishes
   this using only SPKM_REQ (thereby authenticating the initiator to the
   target), while SPKM-1 accomplishes this using both SPKM_REQ and
   SPKM_REP_TI (thereby authenticating the target to the initiator).

   Applications requiring authentication of both peers (initiator as
   well as target) should request mutual authentication, resulting in
   "mutual_state" being set within SPKM_REQ Options.  In response to
   such a request, the context target will reply to the initiator with a
   token containing either an SPKM_REP_TI or SPKM_ERROR.  If mechanism
   SPKM-2 has been chosen, this completes the (timestamp-based) mutual
   authentication context establishment exchange.  If mechanism SPKM-1
   has been chosen and SPKM_REP_TI is sent, the initiator will then
   reply to the target with either an SPKM_REP_IT or SPKM_ERROR,
   completing the (random-number-based) mutual authentication context
   establishment exchange.


3.1.2. Context Establishment Tokens - Target

   Relevant SPKM_REP_TI syntax is as follows:

   SPKM_REP_TI ::= SIGNED SEQUENCE {
           tok_id [0]       INTEGER          -- shall contain 0200 (hex)
           timestamp [1]    UTCTime          -- may be NULL for
                                             -- mechanism SPKM-1
           randTarg [2]     Random_Integer,
           src_name [3]     Name,
           randSrc [4]      Random_Integer,
           rep_data [5]     Context_Data,
           key_estb_id [6]  AlgorithmIdentifier OPTIONAL
                 -- used if target is changing key estb. algorithm
                 -- (must be a member of initiator?s key_estb_set)
           key_estb_str [7] BIT STRING OPTIONAL
                 -- contains either the response to initiator?s
                 -- key_estb_req (if init. used a 2-pass K-ALG) or
                 -- the key_estb_req corresponding to K-ALG supplied
                 -- in above key_estb_id
   }


3.1.3. Context Establishment Tokens - Initiator (second token)

   Relevant SPKM_REP_IT syntax is as follows:

   SPKM_REP_IT ::= SIGNED SEQUENCE {
           tok_id [0]       INTEGER  -- shall contain 0300 (hex)
           randTarg [1]     Random_Integer,
           targ_name [2]    Name,
           key_estb_rep [3] BIT STRING OPTIONAL
                 -- contains the response to target?s key_estb_str
                 -- (if target selected a 2-pass K-ALG)
   }

Adams                Document Expiration: 30 April 1995               11

3.1.4. Error Token

   The syntax of SPKM_ERROR is as follows:

   SPKM_ERROR ::=   SIGNED SEQUENCE {
           tok_id [0]       INTEGER, -- shall contain 0400 (hex)
           pvno[1]          INTEGER, -- protocol version number
           error-code[2]    INTEGER,
           guilty-seq[3]    OCTET STRING OPTIONAL,
                                     -- encrypted sequence number of the
                                     -- token which caused this error
                                     -- (empty if seq. nums not used)
           e-text[4]        PrintableString OPTIONAL,
           e-data[5]        OCTET STRING OPTIONAL
   }

   Values to be transferred in the error-code field of a SPKM_ERROR
   message are defined in Section 5 of this specification.



3.2. Per-Message and Context Deletion Tokens

   Three classes of tokens are defined in this section: "Sign" tokens,
   emitted by calls to gss_sign() and consumed by calls to gss_verify();
   "Seal" tokens, emitted by calls to gss_seal() and consumed by calls
   to gss_unseal(); and context deletion tokens, emitted by calls to
   gss_delete_sec_context() and consumed by calls to
   gss_process_context_token().


3.2.1. Per-message Tokens - Sign

   Use of the gss_sign() call yields a token, separate from the user
   data being protected, which can be used to verify the integrity of
   that data as received.  The token and the data are sent separately
   by the sending application and it is the receiving application's
   responsibility to associate the received data with the received
   token.

   The SPKM_SIGN token has the following format:


   SPKM_SIGN ::= SEQUENCE {
           sign_header [0]   Sign_Header,
           sign_body [1]     Sign_Body
   }









Adams                Document Expiration: 30 April 1995               12

   Sign_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain 0101 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of the agreed symmetric
                                -- algorithms for this context).
                                -- NULL = default id.
           snd_seq [3]      OCTET STRING,
                                -- Encrypted sequence number.
   }

   Sign_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of header and data,
                                -- calculated according to algorithm
                                -- specified in int_alg field.
   }




3.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the data field, logically prepended by the bytes
   of the plaintext token header (sign_header).  The result binds the
   data to the entire plaintext header, so as to minimize the possibil-
   ity of malicious splicing.

   For example, if the int_alg specifies the md5WithRSA algorithm, then
   the checksum is formed by computing an MD5 [RFC-1321] hash over the
   plaintext data (prepended by the header), and then computing an RSA
   signature [PKCS1] on the 16-byte MD5 result.  The signature is
   computed using the RSA private key retrieved from the credentials
   structure and the result (whose length is implied by the "modulus"
   parameter in the private key) is stored in the int_cksum field.

   If the int_alg specifies a keyed hashing algorithm (for example,
   DES-MAC or md5-DES-CBC), then the key to be used is the established
   context key.  Again, the result (whose length is implied by int_alg)
   is stored in the int_cksum field.









Adams                Document Expiration: 30 April 1995               13
3.2.1.2. Sequence Number

   It is assumed that the underlying transport layers (of whatever pro-
   tocol stack is being used by the application) will provide adequate
   communications reliability (that is, non-malicious loss, re-ordering,
   etc., of data packets will be handled correctly).  Therefore, enc-
   rypted sequence numbers are used in SPKM purely for security, as
   opposed to reliability, reasons (that is, to avoid malicious loss,
   replay, or re-ordering of SPKM tokens) -- note that sequence numbers
   are used so that there is no requirement for secure timestamps in the
   message tokens.  The initiator's initial sequence number for the
   current context may be explicitly given in the Context_Data field of
   SPKM_REQ and the target's initial sequence number may be explicitly
   given in the Context_Data field of SPKM_REP_TI; if either of these is
   not given then the default value of 00 is to be used.

   Sequence number field: The plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2
   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 00 - sender is the
   context initiator, Hex FF - sender is the context acceptor).

   The field is then CBC encrypted using the symmetric algorithm
   specified in seq_alg, IV', and the context key.  (IV' is computed as
   the ECB decryption of the IV specified in seq_alg, using the context
   key and the symmetric algorithm specified in seq_alg.  The reason for
   having seq_alg convey an encrypted IV is to avoid revealing a known
   plaintext/ciphertext pair in the token.)  The resulting encrypted
   sequence number is placed in snd_seq.  After sending a gss_sign() or
   gss_seal() token, the sender's sequence number is incremented by one.


3.2.1.3. Sequence Number Processing

   The receiver of the token will decrypt the sequence number field
   using the context key and compare it with the expected sequence
   number.  The repetition of the (effectively 1-bit) direction
   indicator within the sequence number field provides redundancy so
   that the receiver may verify that the decryption succeeded.

   Since the encrypted sequence number is used as part of the input to
   the integrity checksum, attempts to splice a checksum and sequence
   number from different messages will be detected.  The direction
   indicator will detect packets that have been maliciously reflected.


3.2.2. Per-message Tokens - Seal

   Use of the gss_seal() call yields a token which encapsulates the in-
   put user data (optionally encrypted) along with associated integrity
   check quantities. The token emitted by gss_seal() consists of an
   integrity header followed by a body portion that contains either the
   plaintext data (if conf_alg = FFFF) or encrypted data (using the key
   specified in 3.2.2.4 with one of the agreed C-ALGs for this context).

Adams                Document Expiration: 30 April 1995               14
   The SPKM_SEAL token has the following format:


   SPKM_SEAL ::= SEQUENCE {
           seal_header [0]   Seal_Header,
           seal_body [1]     Seal_Body
   }


   Seal_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain 0201 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of the agreed symmetric
                                -- algorithms for this context).
                                -- NULL = default id.
           conf_alg [3]     AlgorithmIdentifier,
                                -- Confidentiality algorithm indicator
                                -- (must be 'FFFF' or one of the agreed
                                -- symmetric algorithms for this
                                -- context).
                                -- NULL = default id , 'FFFF' = none.
           snd_seq [4]      OCTET STRING,
                                -- Encrypted sequence number.
   }

   Seal_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of header and data,
                                -- calculated according to algorithm
                                -- specified in int_alg field.
           data [1]         OCTET STRING
                                -- encrypted or plaintext data.
   }


3.2.2.1: Confounding

   As in [KRB5], an 8-byte random confounder is prepended to the data to
   compensate for the fact that an IV of zero is used for encryption.
   The result is referred to as the "confounded" data field.


3.2.2.2. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the plaintext data field, logically prepended by
   the bytes of the plaintext token header (seal_header).  As with
   gss_sign(), the result binds the data to the entire plaintext header,
   so as to minimize the possibility of malicious splicing.

Adams                Document Expiration: 30 April 1995               15
   The examples for md5WithRSA and DES-MAC are exactly as specified in
   3.2.1.1.

   If int_alg specifies md5-DES-CBC and conf_alg specifies anything
   other than DES-CBC, then the checksum is computed according to
   3.2.1.1 and the result is stored in int_alg.  However, if conf_alg
   specifies DES-CBC then the encryption and the integrity can be done
   as follows.  An MD5 [RFC-1321] hash is computed over the plaintext
   data (prepended by the header).  This 16-byte value is appended to
   the concatenation of the "confounded" data and 1-8 padding bytes (the
   padding is as specified in [KRB5] for DES-CBC).  The result is
   then CBC encrypted using the context key and placed in the "data"
   field of Seal_Body.  The final two blocks of ciphertext (i.e., the
   encrypted MD5 hash) are also placed in the int_cksum field of
   Seal_Body as the integrity checksum.

   If int_alg specifies sum64-DES-CBC then conf_alg must specify DES-CBC
   (i.e., confidentiality must be requested by the calling application
   or SPKM will return an error).  Encryption and integrity are done in
   a single pass using the context key as follows.  The sum (modulo
   2**64 - 1) of all plaintext data blocks (prepended by the header) is
   computed.  This 8-byte value is appended to the concatenation of the
   "confounded" data and 1-8 padding bytes (the padding is as specified
   in [KRB5] for DES-CBC).  As above, the result is then CBC encrypted
   and placed in the "data" field of Seal_Body.  The final block of
   ciphertext (i.e., the encrypted sum) is also placed in the int_cksum
   field of Seal_Body as the integrity checksum.


3.2.2.3 Sequence Number

   Encrypted sequence numbers are computed and processed for gss_seal()
   exactly as specified in 3.2.1.2 and 3.2.1.3.


3.2.2.4: Data Encryption

   The following procedure is followed unless (a) conf_alg is Hex FFFF,
   or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC, or (c) int_alg
   is sum64-DES-CBC:

   The "confounded" data is padded and encrypted according to the
   algorithm specified in the conf_alg field.  The data is encrypted
   using CBC with an IV of zero.  The key used is derived from the
   established context key by XOR-ing the context key with the hexadeci-
   mal constant F0F0F0...F0 (this ensures that the key used for encryp-
   tion and the key used for a separate, keyed integrity algorithm --
   for example DES-MAC, but not sum64-DES-CBC -- are different).


3.2.3. Context deletion token

   The token emitted by gss_delete_sec_context() is based on the packet
   format for tokens emitted by gss_sign().



Adams                Document Expiration: 30 April 1995               16

   The SPKM_DEL token has the following format:

   SPKM_DEL ::= SEQUENCE {
           del_header [0]   Del_Header,
           del_body [1]     Del_Body
   }

   Del_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain 0301 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of the agreed symmetric
                                -- algorithms for this context).
                                -- NULL = default id.
           snd_seq [3]      OCTET STRING,  -- Encrypted sequence number.
   }

   Del_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of header, calculated
                                -- according to algorithm specified
                                -- in int_alg field.
   }

   snd_seq will be calculated as for tokens emitted by gss_sign().  The
   int_cksum will be calculated as for tokens emitted by gss_sign(),
   except that the user-data component of the checksum data will be a
   zero-length string.



4. NAME TYPES AND OBJECT IDENTIFIERS

   No name types have yet been defined for SPKM.  This section is for
   further study.



5. PARAMETER DEFINITIONS

   This section defines parameter values used by the SPKM GSS-API
   mechanism.  It defines interface elements in support of portability.








Adams                Document Expiration: 30 April 1995               17

5.1. Minor Status Codes

   This section recommends common symbolic names for minor_status values
   to be returned by the SPKM GSS-API mechanism.  Use of these
   definitions will enable independent implementors to enhance
   application portability across different implementations of the
   mechanism defined in this specification.  (In all cases,
   implementations of gss_display_status() will enable callers to
   convert minor_status indicators to text representations.) Each
   implementation should make available, through include files or other
   means, a facility to translate these symbolic names into the concrete
   values which a particular GSS-API implementation uses to represent
   the minor_status values specified in this section.  It is recognized
   that this list may grow over time, and that the need for additional
   minor_status codes specific to particular implementations may arise.

5.1.1. Non-SPKM-specific codes

   GSS_S_G_VALIDATE_FAILED
       /* "Validation error" */
   GSS_S_G_BUFFER_ALLOC
       /* "Couldn't allocate gss_buffer_t data" */
   GSS_S_G_BAD_MSG_CTX
       /* "Message context invalid" */
   GSS_S_G_WRONG_SIZE
       /* "Buffer is the wrong size" */
   GSS_S_G_BAD_USAGE
       /* "Credential usage type is unknown" */
   GSS_S_G_UNAVAIL_QOP
       /* "Unavailable quality of protection specified" */

5.1.2. SPKM-specific-codes

   GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
       /* "Context is already fully established" */
   GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
       /* "Unknown integrity algorithm type in token" */
   GSS_SPKM_S_SG_BAD_SYMM_ALG_TYPE
       /* "Unknown symmetric algorithm type in token" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
       /* "Unknown key establishment algorithm type in token" */
   GSS_SPKM_S_SG_CTX_INCOMPLETE
       /* "Attempt to use incomplete security context" */
   GSS_SPKM_S_SG_BAD_INT_ALG_SET
       /* "No integrity algorithm in common from offered set" */
   GSS_SPKM_S_SG_BAD_SYMM_ALG_SET
       /* "No symmetric algorithm in common from offered set" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET
       /* "No key establishment algorithm in common from offered set" */
   GSS_SPKM_S_SG_INVALID_TOKEN_DATA
       /* "Data is improperly formatted:  cannot encode into token" */
   GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT
       /* "Received token is improperly formatted:  cannot decode" */



Adams                Document Expiration: 30 April 1995               18

5.2. Quality of Protection Values

   Quality of Protection (QOP) values are defined for the SPKM GSS-API
   mechanism, and are used as input to gss_sign() and gss_seal() to
   select among alternate integrity-checking algorithms.  Once a set of
   algorithms has been agreed upon by the context initiator and target,
   the QOP parameter simply selects from this ordered set.

   More specifically, the SPKM_REQ token may send a sequence of "n" Alg.
   IDs specifying integrity-checking algorithms supported by the
   initiator.  The target may support only a subset m (m <= n) of these,
   and so will return the sequence of "m" Alg. IDs which it supports in
   the SPKM_REP_TI token.  The first Alg. ID is therefore the default
   algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through
   QOP = m-1, respectively.  Any QOP value greater than or equal to m is
   equated to m-1 and is therefore mapped to the last Alg. ID in the
   agreed set.

   To aid in implementation and interoperability, the following
   stipulations are made.  The set of n Alg. IDs sent by the initiator
   must contain one specifying an algorithm which computes a true
   digital signature in the first position, and must contain one
   specifying any other (non-signature) integrity algorithm in the
   second position.  The set of m Alg. IDs returned by the target must
   also contain one specifying an algorithm which computes a true
   digital signature in the first position, and one specifying a (non-
   signature) integrity algorithm in the second position.

   Note that if the SPKM_REP_TI token is not used (unilateral authen-
   tication using SPKM-2), then m=n and the "agreed" set of Alg. IDs is
   simply taken to be the initiator's set.

   The reason for these stipulations is to allow the QOP parameter to
   convey the semantics of the desired integrity service without forcing
   it to specify the actual algorithms to be used.  The result is that
   the application is always able to choose, in a completely general and
   portable way, an integrity service which provides non-repudiation
   semantics (by passing QOP = Hex 00), and one which does not provide
   non-repudiation semantics (by passing QOP = Hex 01).  Note that an
   application which is aware of its own underlying environment and/or
   is aware of the underlying environment of its peer is not unduly
   constrained by the above stipulations because any other number or
   kind of algorithms may be agreed upon during context establishment,
   making other QOP values perfectly valid and meaningful over that
   context and between those peers.



6. SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.





Adams                Document Expiration: 30 April 1995               19
7. REFERENCES

   [Davi89]:    D. W. Davies and W. L. Price, "Security for Computer
   Networks", Second Edition, John Wiley and Sons, New York, 1989.

   [FIPS-113]:  National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

   [Juen84]:    R. R. Jueneman, C. H. Meyer and S. M. Matyas, ~Message
   Authentication with Manipulation Detection Codes?, in Proceedings of
   the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
   Society Press, 1984, pp.33-54..

   [KRB5]:      J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
   Internet Draft draft-ietf-cat-kerb5gss-01.

   [PKCS1]:     RSA Encryption Standard, Version 1.5, RSA Data Security,
   Inc., Nov. 1993.

   [PKCS3]:     Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
   Data Security, Inc., Nov. 1993.

   [RFC-1321]:  R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.

   [RFC-1422]:  S. Kent, "Privacy Enhancement for Internet Electronic
   Mail:  Part II: Certificate-Based Key Management", RFC 1422.

   [RFC-1507]:  C. Kaufman, "DASS:  Distributed Authentication Security
   Service", RFC 1507.

   [RFC-1508]:  J. Linn, "Generic Security Service Application Program
   Interface", RFC 1508.

   [RFC-1509]:  J. Wray, "Generic Security Service Application Program
   Interface: C-bindings", RFC 1509.

   [RFC-1510]:  J. Kohl and C. Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510.

   [X.509]:     ISO/IEC 9594-8, "Information Technology - Open Systems
   Interconnection - The Directory:  Authentication Framework", CCITT
   Recommendation X.509, 1993.

   [X9.44]:     ANSI, "Public Key Cryptography Using Reversible
   Algorithms for the Financial Services Industry:  Transport of
   Symmetric Algorithm Keys Using RSA", X9.44-1993.

8. AUTHOR'S ADDRESS

   Carlisle Adams
   Bell-Northern Research, Ltd.
   P.O.Box 3511, Station C
   Ottawa, Ontario, CANADA  K1Y 4H7

   Phone: +1 613.763.9008
   E-mail: cadams@bnr.ca

Adams                Document Expiration: 30 April 1995               20


Appendix:  IMPORTS

A.1 ASN.1 encoding

   The following definitions are taken from X.501 and X.509.

   --CCITT Definitions:

   joint-iso-ccitt      OBJECT IDENTIFIER ::= {2}
   ds                   OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
   algorithm            OBJECT IDENTIFIER ::= {ds 8}
   encryptionAlgorithm  OBJECT IDENTIFIER ::= {algorithm 1}
   hashAlgorithm        OBJECT IDENTIFIER ::= {algorithm 2}
   signatureAlgorithm   OBJECT IDENTIFIER ::= {algorithm 3}
   rsa                  OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}

   iso                  OBJECT IDENTIFIER ::= {1}
   identified-organization OBJECT IDENTIFIER ::= {iso 3}


   --1989 OSI Implementors Workshop "Stable" Agreements

   oiw                OBJECT IDENTIFIER ::= {identified-organization 14}
   dssig                  OBJECT IDENTIFIER ::= {oiw 7}
   oiwAlgorithm           OBJECT IDENTIFIER ::= {dssig 2}
   oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
   oiwHashAlgorithm       OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
   oiwSignatureAlgorithm  OBJECT IDENTIFIER ::= {oiwAlgorithm 3}


   --PKCS #1 definition [PKCS1]

   rsaEncryption OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-1(1) 1
   }


   --PKCS #3 definition [PKCS3]

   dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
   }

   -- the parameter to be used with this algorithm is

   DHParameter ::= SEQUENCE {
           prime              INTEGER,  -- p
           base               INTEGER,  -- g
           privateValueLength INTEGER OPTIONAL
   }



Adams                Document Expiration: 30 April 1995               21
   --X.501 definitions

   AttributeType ::= OBJECT IDENTIFIER
   AttributeValue ::= ANY
   AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}

   Name ::= CHOICE {       --only one for now
                   RDNSequence
                   }
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   DistinguishedName ::= RDNSequence

   RelativeDistinguishedName ::= SET OF AttributeValueAssertion


   --X.509 definitions (with proposed 1992 extensions presumed)

   ENCRYPTED MACRO ::=
   BEGIN
   TYPE NOTATION   ::= type(ToBeEnciphered)
   VALUE NOTATION  ::= value(VALUE BIT STRING)
   END     -- of ENCRYPTED


   SIGNED MACRO    ::=
   BEGIN
   TYPE NOTATION   ::= type (ToBeSigned)
   VALUE NOTATION  ::= value (VALUE
   SEQUENCE{
           ToBeSigned,
           AlgorithmIdentifier,    --of the algorithm used to
                                   --generate the signature
           ENCRYPTED OCTET STRING  --where the octet string is the
                                   --result of the hashing of the
                                   --value of "ToBeSigned"
           }
                           )
   END     -- of SIGNED


   SIGNATURE MACRO ::=
   BEGIN
   TYPE NOTATION   ::= type (OfSignature)
   VALUE NOTATION  ::= value (VALUE
   SEQUENCE {
           AlgorithmIdentifier,    --of the algorithm used to compute
           ENCRYPTED OCTET STRING  -- the signature where the octet
                                   -- string is a function (e.g., a
                                   -- compressed or hashed version)
                                   -- of the value 'OfSignature',
                                   -- which may include the
                                   -- identifier of the algorithm
                                   -- used to compute the signature
           }
                           )
   END     -- of SIGNATURE

Adams                Document Expiration: 30 April 1995               22


   Certificate ::= SIGNED SEQUENCE {
           version [0]        Version DEFAULT v1,
           serialNumber [1]   CertificateSerialNumber,
           signature [2]      AlgorithmIdentifier,
           issuer [3]         Name,
           validity [4]       Validity,
           subject [5]        Name,
           subjectPublicKeyInfo [6] SubjectPublicKeyInfo,
           issuerUID [7]      IMPLICIT UID OPTIONAL,  -- used in v2 only
           subjectUID [8]     IMPLICIT UID OPTIONAL   -- used in v2 only
           }

   Version ::= INTEGER {v1(0), v2(1)}

   CertificateSerialNumber ::= INTEGER

   Validity ::= SEQUENCE {
           NotBefore         UTCTime,
           NotAfter          UTCTime
           }

   AlgorithmIdentifier ::= SEQUENCE {
           algorithm         OBJECT IDENTIFIER,
           parameter         ANY DEFINED BY algorithm OPTIONAL
           }

   SubjectPublicKeyInfo ::= SEQUENCE {
           algorithm         AlgorithmIdentifier,
           subjectPublicKey  BIT STRING
           }

   UID ::= BIT STRING



   CertificatePair ::= SEQUENCE {
           forward [0]      SingleCertificate OPTIONAL,
           reverse [1]      SingleCertificate OPTIONAL
           }            -- at least one of the pair shall be present

   CertificateList ::= SIGNED SEQUENCE {
           signature [0]           AlgorithmIdentifier,
           issuer [1]              Name,
           thisUpdate [2]          UTCTime,
           nextUpdate [3]          UTCTime OPTIONAL,
           revokedCertificates [4] SEQUENCE OF SEQUENCE {
                userCertificate       CertificateSerialNumber,
                revocationDate        UTCTime
                } OPTIONAL
           }





Adams                Document Expiration: 30 April 1995               23

   AuthorizationData ::=   SEQUENCE OF SEQUENCE {
                           ad-type[0]               INTEGER,
                           ad-data[1]               OCTET STRING
   }

     -- ad-data   This field contains authorization data to be
     --           interpreted according to the value of the
     --           corresponding ad-type field.

     -- ad-type   This field specifies the format for the ad-data
     --           subfield.  All negative values are reserved for
     --           local use.  Non-negative values are reserved for
     --           registered use.







A.2 Encoding Rules

   Whenever a structure is to be signed it must always be constructed
   the same way. This is particularly important where a signed structure
   has to be reconstructed by the recipient before the signature is
   verified. The rules listed below are taken from X.509.

    - the definite form of length encoding shall be used, encoded in
      the minimum number of octets;

    - for string types, the constructed form of encoding shall not
      be used;

    - if the value of a type is its default value, it shall be
      absent;

    - the components of a Set type shall be encoded in ascending
      order of their tag values;

    - the components of a Set-of type shall be encoded in ascending
      order of their octet values;

    - if the value of a Boolean type is true, the encoding shall
      have its contents octet set to Hex 'FF';

    - unused bits in the final octet of the encoding of a BitString
      value, if there are any, shall be set to zero;

    - the encoding of a Real type shall be such that bases 8, 10 and
      16 shall not  be used, and the binary scaling factor shall be
      zero.





Adams                Document Expiration: 30 April 1995               24


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/