view Side-By-Side changes

Network Working Group                                           C. Adams
Internet-Draft                                                 M. Eisler
Expires: October 1, 2006 February 19, 2007                                       Authors
                                                              W. Adamson
                                                         O. Kornievskaia
                                                                 Editors
                                                          March 30,
                                                         August 18, 2006


      Low Infrastructure Public Key Mechanisms: SPKM-3 and LIPKEY
                    draft-adamson-rfc2847-bis-00.txt
                    draft-adamson-rfc2847-bis-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 1, 2006. February 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memorandum describes a method whereby one can use GSS-API
   [RFC2078] to supply a public-key based secure channel between a
   client and a server without the need for an external Public Key
   Infrastructure for certificate verification.  The method leverages
   the existing Simple Public Key Mechanism (SPKM), and is specified as



Adams, et al.           Expires October 1, 2006 February 19, 2007               [Page 1]

Internet-Draft                   SPKM-3                       March                      August 2006


   two separate GSS-API mechanisms, SPKM-3 and LIPKEY, with LIPKEY
   layered above SPKM-3.

   SPKM-3 describes a method for creation of the secure channel using
   mutual authentication where both a user and server authenticate with
   public-key certificates [RFC3280].  SPKM-3 also describes a method
   for creation of the secure channel where only the server
   authenticates with a public-key certificate, and the user is
   anonymous.  LIPKEY then uses the SPKM-3 anonymous secure channel to
   authenticate a user with a password, completing the mutual
   authentication.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Simple Public Key GSS-API Mechanism Version 3 (SPKM-3) . .  5
     2.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2   Mechanism Type . . . . . . . . . . . . . . . . . . . . . .  6
     2.3   Algorithms . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.3.1   Integrity Algorithms (I-ALG) . . . . . . . . . . . . .  7
       2.3.2   Confidentiality Algorithms (C-ALG) . . . . . . . . . . 10
       2.3.3   Key Establishment Algorithms (K-ALG) . . . . . . . . . 11
       2.3.4   One-Way Function (O-ALG) for Subkey Derivation
               Algorithm  . . . . . . . . . . . . . . . . . . . . . . 12
     2.4   Token Formats  . . . . . . . . . . . . . . . . . . . . . . 13
       2.4.1   Context Establishment Tokens . . . . . . . . . . . . . 14
         2.4.1.1   SPKM-REQ Token . . . . . . . . . . . . . . . . . . 15 16
         2.4.1.2   SPKM-REP-TI Token  . . . . . . . . . . . . . . . . 20 22
         2.4.1.3   SPKM-REP-IT Token  . . . . . . . . . . . . . . . . 22 24
       2.4.2   Error Tokens . . . . . . . . . . . . . . . . . . . . . 23 25
         2.4.2.1   SPKM-ERROR Token . . . . . . . . . . . . . . . . . 23 25
         2.4.2.2   SPKM-GSS-ERROR Token . . . . . . . . . . . . . . . 24 26
       2.4.3   Per-message Tokens . . . . . . . . . . . . . . . . . . 25 28
         2.4.3.1   SPKM-MIC Tokens Token . . . . . . . . . . . . . . . . . 26 . 28
           2.4.3.1.1   Checksum . . . . . . . . . . . . . . . . . . . 26 29
           2.4.3.1.2   Sequence Number  . . . . . . . . . . . . . . . 27 29
           2.4.3.1.3   Sequence Number Processing . . . . . . . . . . 27 30
         2.4.3.2   SPKM-WRAP Tokens Token  . . . . . . . . . . . . . . . . . 28 30
           2.4.3.2.1   Checksum . . . . . . . . . . . . . . . . . . . 29 31
           2.4.3.2.2   Sequence Number  . . . . . . . . . . . . . . . 30 32
           2.4.3.2.3   Data Encryption  . . . . . . . . . . . . . . . 30 32
       2.4.4   Context Deletion Token . . . . . . . . . . . . . . . . 30 33
     2.5   Name Types and Object Identifiers  . . . . . . . . . . . . 31
     2.6   Credential Management 34
       2.5.1   Mandatory Name Forms . . . . . . . . . . . . . . . . . 34
         2.5.1.1   SPKM3 Principal Name Form  . 32
     2.7   Parameter Definitions . . . . . . . . . . . 34
         2.5.1.2   Host-Based Service Name Form . . . . . . . 33
       2.7.1   Minor Status Codes . . . . 34
         2.5.1.3   Anonymous Name Form  . . . . . . . . . . . . . . 33
       2.7.2   Non-SPKM-3-specific codes . 35
         2.5.1.4   Exported Name Object Form  . . . . . . . . . . . . 36



Adams, et al.           Expires February 19, 2007               [Page 2]

Internet-Draft                   SPKM-3                      August 2006


     2.6   Credential Management  . 33
         2.7.2.1   GSS-Related codes . . . . . . . . . . . . . . . . 33



Adams, et al.            Expires October 1, 2006                [Page 2]

Internet-Draft                   SPKM-3                       March 2006


         2.7.2.2   Implementation-Related codes . 37
     2.7   Parameter Definitions  . . . . . . . . . . 34
       2.7.3   SPKM-3-specific-codes . . . . . . . . 37
       2.7.1   Minor Status Codes . . . . . . . . 34
     2.8   Quality of Protection Values . . . . . . . . . . 37
       2.7.2   Non-SPKM-3-specific codes  . . . . . 35
     2.9   Support Functions . . . . . . . . . 37
         2.7.2.1   GSS-Related codes  . . . . . . . . . . . 39
       2.9.1   The token_type Output Parameter . . . . . 37
         2.7.2.2   Implementation-Related codes . . . . . . . . . . . 38
       2.7.3   SPKM-3-specific-codes  . . . . . . . . . . . . . . . 39
       2.9.2   The context_handle Output Parameter . 38
     2.8   Quality of Protection Values . . . . . . . . . . . . . . . 39
   3.  A Low Infrastructure Public Key Mechanism Using SPKM-3
       (LIPKEY) . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 44
     3.1   How LIPKEY Initiator Uses SPKM-3 . . . . . . . . . . . . . 41 44
       3.1.1   GSS_Import_name  . . . . . . . . . . . . . . . . . . . 41 44
       3.1.2   GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . 41 44
       3.1.3   GSS_Init_sec_context . . . . . . . . . . . . . . . . . 41 44
         3.1.3.1   LIPKEY Caller Specified anon_req_flag as TRUE  . . 42 45
         3.1.3.2   LIPKEY Caller Specified anon_req_flag as FALSE . . 42 45
       3.1.4   Other operations . . . . . . . . . . . . . . . . . . . 44 47
     3.2   How LIPKEY Target Uses SPKM-3  . . . . . . . . . . . . . . 44 47
       3.2.1   GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . 44 47
       3.2.2   GSS_Accept_sec_context . . . . . . . . . . . . . . . . 44 47
     3.3   LIPKEY Description . . . . . . . . . . . . . . . . . . . . 45 48
       3.3.1   Mechanism Type . . . . . . . . . . . . . . . . . . . . 45 48
       3.3.2   Token Formats  . . . . . . . . . . . . . . . . . . . . 45 48
         3.3.2.1   Context Tokens Prior to SPKM-3 Context
                   Establishment  . . . . . . . . . . . . . . . . . . 45 48
         3.3.2.2   Post-SPKM-3 Context Establishment Tokens . . . . . 46 49
           3.3.2.2.1   From LIPKEY Initiator  . . . . . . . . . . . . 46 49
           3.3.2.2.2   From LIPKEY Target . . . . . . . . . . . . . . 46 49
         3.3.2.3   Tokens from GSS_GetMIC and GSS_Wrap  . . . . . . . 46 49
       3.3.3   Name Types . . . . . . . . . . . . . . . . . . . . . . 46 49
       3.3.4   Quality of Protection  . . . . . . . . . . . . . . . . 47 50
   4.  Issues . . . . .  Security Considerations  . . . . . . . . . . . . . . . . . . . 51
     4.1   Password Management  . . . . 48
   5.  Security Considerations . . . . . . . . . . . . . . . 51
     4.2   Certification Authorities  . . . . 50
     5.1   Password Management . . . . . . . . . . . . 51
     4.3   HMAC-MD5 and MD5 Weaknesses  . . . . . . . 50
     5.2   Certification Authorities . . . . . . . . 51
     4.4   Security of cast5CBC . . . . . . . . 50
     5.3   HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . 51
   5.  Acknowledgments  . . . . 50
     5.4   Security of cast5CBC . . . . . . . . . . . . . . . . . . . 50 52
   A.  Appendix A: SPKM-3 ANS.1 Module Definition . . . . . . . . . . 53
   B.  Appendix B: Changes from RFC2847 and RFC2025 . . . . . . . 51 . . 60
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 60
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 66 63
       Intellectual Property and Copyright Statements . . . . . . . . 68 65









Adams, et al.           Expires October 1, 2006 February 19, 2007               [Page 3]

Internet-Draft                   SPKM-3                       March                      August 2006


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This memorandum describes two new security mechanism under the GSS-
   API, a new version of the Simple Public Mechanism (SPKM-3) and the
   Low Infrastructure Public Key Mechanism (LIPKEY).

   The current versions of the SPKM GSS-API mechanisms, SPKM-1 and
   SPKM-2, require a great deal of infrastructure to set up.  Both
   initiator and target must have the ability to obtain each others
   public-key certificate(s) which correspond to a given name, as well
   as to obtain the certificate chains needed for certificate
   verification.  The actual mechanism used is declared as outside the
   scope of the SPKM specification.

   Using a mechanism resembling SPKM-1, SPKM-3 specifies a method for
   mutual and unilateral authentication in the case of low public-key
   infrastructure, where the target and initiator have no knowledge of
   each others certificates and no way to obtain them except through
   SPKM-3.  Instead, it assume that the parties share a common CA.

   By using unilateral authentication with an anonymous user, SPKM-3 can
   create a secure channel that requires only target public-key
   certificate (s).  An application that uses GSS-API is certainly free
   to use GSS-API's GSS_Wrap() routine to encrypt a user name and
   password and send them to the target across this secure channel, for
   it to decrypt and verify.  Applications often have application
   protocols associated with them, and there might not be any provision
   in the protocol to specify a password.  Layering a thin GSS-API
   mechanism (LIPKEY) over SPKM-3 can mitigate this problem.  This can
   be a useful approach to avoid modifying applications that have
   already bound to GSS-API, assuming the applications are not
   statically bound to specific GSS-API mechanisms.

   The intent of this draft is to issue a revised SPKM-3/LIPKEY RFC that
   provides one-stop shopping for all the information necessary to
   implement SPKM-3 and LIPKEY; a complete specification that doesn't
   need [RFC2025] and that replaces [RFC2847].  SPKM-3 shares the SPKM-1
   [RFC2025] specification.  We give credit here for text in this
   memorandum derived from [RFC2025] and [RFC2847].








Adams, et al.           Expires October 1, 2006 February 19, 2007               [Page 4]

Internet-Draft                   SPKM-3                       March                      August 2006


2.  The Simple Public Key GSS-API Mechanism Version 3 (SPKM-3)

2.1  Overview

   The goal of the Generic Security Service Application Program
   Interface (GSS-API) is stated in the abstract of [RFC2078] 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."

   SPKM-3 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 [RFC2078], SPKM-3 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 digital signatures supporting non-repudiation
   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
   [RFC2078] 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



Adams, et al.            Expires October 1, 2006                [Page 5]

Internet-Draft                   SPKM-3                       March 2006
      transfers the tokens to a peer on a remote system; that peer
      passes the received tokens to its local GSS-API implementation for
      processing.



Adams, et al.           Expires February 19, 2007               [Page 5]

Internet-Draft                   SPKM-3                      August 2006


   Many PKI-based protocols require a great deal of infrastructure, such
   as directory service that stores public-key certificates, protocols
   and applications that retreieve retrieve them for authentication procedures.
   To establish a mutually authenticated secure communication channel,
   SPKM-3 does not require directory services hence the term "low
   infrastructure".  SPKM-3 provides the following features:

   1.  SPKM-3 allows both unilateral (where the target is authenticated
       to the initiator) and mutual authentication to be accomplished
       without the use of secure timestamps.  This enables environments
       which do not have access to secure time to nevertheless have
       access to secure authentication.

   2.  SPKM-3 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.

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

   It is envisioned that typical use of SPKM-3 will involve mutual
   authentication, or (anonymous) unilateral authentication in
   conjunction with LIPKEY.  Although unilateral authentication is
   available for use independent of LIPKEY, this is not generally
   recommended.

2.2  Mechanism Type

   The SPKM-3 GSS-API mechanism will be identified by the following
   Object Identifier:

      spkm-3 OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) spkm(1) 3 }


2.3  Algorithms

   SPKM-3 employs four types of algorithms: integrity algorithms
   (I-ALG), confidentiality algorithms (C-ALG), key establishment
   algorithms (K-ALG), and one-way functions (O-ALG) used to derive



Adams, et al.            Expires October 1, 2006                [Page 6]

Internet-Draft                   SPKM-3                       March 2006
   subkey for I-ALGs and C-ALGs.  Each type, along with its purpose and
   a set of specific algorithms of a given type, is described in this
   section.  In order to ensure at least a minimum level of
   interoperability among various implementations of SPKM-3, one of the
   integrity algorithms is specified as MANDATORY; all remaining
   examples (and any other algorithms) may optionally be supported by a
   given SPKM-3 implementation.

   During context establishment in SPKM-3, the initiator offers a set of
   possible confidentiality algorithms and a set of possible integrity
   algorithms to the target (note that the term "integrity algorithms"
   includes digital signature algorithms).  The confidentiality
   algorithms selected by the target become ones that may be used for
   C-ALG over the established context, and the integrity algorithms
   selected by the target become ones that may be used for I-ALG over
   the established context (the target "selects" algorithms by
   returning, in the same relative order, the subset of each offered
   list that it supports).  Note that any C-ALG and I-ALG may be used
   for any message over the context and that the first confidentiality
   algorithm and the first integrity algorithm in the agreed sets become



Adams, et al.           Expires February 19, 2007               [Page 6]

Internet-Draft                   SPKM-3                      August 2006


   the default algorithms for that context.  The agreed confidentiality
   and integrity algorithms for a specific context define the valid
   values of the Quality of Protection (QOP) parameter used in the
   GSS_GetMIC() and GSS_Wrap() calls -- see Section 2.8 for further
   details.

   As per [RFC-2743], [RFC2743], a context initiator can request that per-message
   integrity and confidentiality be available on context, by adding the
   GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG to the flags passed to the
   GSS_Init_sec_context().  As per [RFC-2743], [RFC2743], confidentiality cannot be
   requested without integrity.  Furthermore, if no integrity or
   confidentiality is requested, then no I-ALGs, C-ALGs, or OW-ALGs are
   negotiated, only (anonymous or mutual) authentication step happens.


2.3.1  Integrity Algorithms (I-ALG)

   An integrity 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 support non-repudiation for the message.  During the context
   establishment, initiator and target negotiate which integrity
   algorithms might be used on tokens after the security context is
   established.  Additionally, the integrity of the context
   establishment tokens must be observed.  Consequently, the integrity
   algorithms used during the context establishment might differ from
   the negotiated integrity algorithm.




Adams, et al.            Expires October 1, 2006                [Page 7]

Internet-Draft                   SPKM-3                       March 2006

   A consequence of unilateral authentication is that the initiator does
   not have a certificate of its own.  Therefore, the initiator cannot
   use a digital signature algorithm during or after the context
   establishment.  Instead, the initiator can only negotiate a message
   authentication code (MAC) algorithm that is based on a symmetric key,
   derived during the security context establishment.  However, such
   algorithm cannot be used for integrity of the context establishment
   tokens because the symmetric key has not yet been estalished. established.
   Therefore, for integrity during the context establishment, a new
   NULL-MAC algorithm is defined and used by the initiator during
   anonymous authentication.  During the context establishment, the
   target must use one of the digital signature algorithm in order to
   prevent a man-in-the-middle attack.  Next, we list the I-AlGs for
   SPKM-3.









Adams, et al.           Expires February 19, 2007               [Page 7]

Internet-Draft                   SPKM-3                      August 2006


   NULL-MAC

         NULL-MAC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) dod(6) internet(1)
            security(5) integrity(3) 3 }

   This algorithm (MANDATORY) is a null I-ALG that returns a zero length
   bit string regardless of the input passed to it.  In unilateral
   authentication, the initiator MUST use the NULL-MAC in the first
   context establishment token.  In general, NULL-MAC SHOULD NOT be
   included in a list of negotiated I-ALGs between the initiator and the
   target because it does not carry any security benefits (instead, the
   GSS_Init_sec_context() integ_avail flag SHOULD be set to false).

   HMAC-MD5

         HMAC-MD5 OBJECT IDENTIFIER ::= {
            iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
            ipsec(8) isakmpOakley(1) 1 }

   This algorithm (MANDATORY) is described in [RFC2104].  The HMAC-SHA1
   algorithm is not a mandatory SPKM-3 I-ALG because SHA-1 is about half
   the speed of MD5 [Young].  A MAC based on an encryption algorithm
   like cast5CBC, DES EDE3, or RC4 is not mandatory because MD5 is 31
   percent faster than the fastest of the three encryption algorithms
   [Young].










Adams, et al.            Expires October 1, 2006                [Page 8]

Internet-Draft                   SPKM-3                       March 2006

   md5WithRSAEncryption

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

   This algorithm (MANDATORY) provides data integrity and authenticity
   and supports non-repudiation
   by computing an RSA signature on the MD5 hash of that data (details
   in [RFC1321]).  For the integrity of the target to the initiator
   token, the target MUST use this algorithm for token integrity.  In
   general, after the context is established a symmetric key is derived.
   For the performance reasons, md5WithRSAEncryption should not SHOULD NOT be
   include in a list of negotiated
   I-ALGs unless non-repudiation property of that data is needed. I-ALGs.  For anonymous SPKM-3,
   md5WithRSAEncryption MUST NOT be included.










Adams, et al.           Expires February 19, 2007               [Page 8]

Internet-Draft                   SPKM-3                      August 2006


   sha1WithRSAEncryption

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

   This algorithm (OPTIONAL) is described in [RFC2437].  It is listed in
   addition to md5WithRSAEncryption due to weaknesses in the MD5 hash
   algorithm [Dobbertin].

   dsaWithSHA1

         dsaWithSHA1 OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }

   This algorithm  As with md5WithRSAEncryption, for performance
   reasons, sha1WithRSAEncryption SHOULD NOT be negotiated and for
   anonymous SPKM-3 MUST NOT be included.

   dsaWithSHA1

         dsaWithSHA1 OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }

   This algorithm (RECOMMENDED) is described in [RFC3279].  It is listed
   as an alternative to the RSA-based algorithms.  If either initiator
   or target has DSA keys in their X509 certificiate, certificate, this algorithm
   should be used for integrity of the context establishment tokens
   and/or an I-ALG.  As with previous digital signature algorithms,
   dsaWithSHA1 SHOULD NOT be negotiated and for anonymous SPKM-3 MUST
   NOT be included.

   DES-MAC

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

   This algorithm (OPTIONAL) provides integrity by computing a DES MAC
   (as specified by [FIPS113]) on the data.  It employs a derived
   symmetric key (see Section 2.3.4) and a zero IV.  Padding procedures
   to accommodate plaintext data lengths which may not be integral
   multiples of 8bytes are defined in [FIPS113].




Adams, et al.            Expires October 1, 2006                [Page 9]

Internet-Draft                   SPKM-3                       March 2006

   MD5-DES-CBC

         md5-DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) dod(6) internet(1)
            security(5) integrity(3) 1 }

   This algorithm (OPTIONAL) is included for backward compatibility with
   RFC2025.  The algorithm provides integrity by, first, computing the
   "confounded" MD5 hash over the plaintext data (see Section 2.4.3.2.3
   for more details on computing a confounder) and, then, computing a
   DES-CBC MAC on the 16-byte MD5 result.  DES-CBC employs a derived



Adams, et al.           Expires February 19, 2007               [Page 9]

Internet-Draft                   SPKM-3                      August 2006


   symmetric key (see Section 2.3.4) and a zero IV.  Note that without
   the confounder the strength of this integrity mechanism is (at most)
   equal to the strength of DES under a known-plaintext attack.

   SUM64-DES-CBC

         sum64-DES-CBC OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) integrity(3) 2 }

   This algorithm (OPTIONAL) is included for backward compatibility with
   RFC2025.  The algorithm provides data integrity by encrypting, using
   DES CBC, the concatenation of the confounded 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.  Therefore, if this algorithm is specified,
   then DES-CBC confidentiality algorithm also MUST be specified.  For
   comments regarding the security of this integrity algorithm, see
   [Juen84].

2.3.2  Confidentiality Algorithms (C-ALG)

   GSS-conformant

   A GSS  mechanism need not support confidentiality.  Making a
   confidentiality algorithm mandatory may preclude exportability of the
   mechanism implementation; this document therefore specifies certain
   algorithms as RECOMMENDED (that is, interoperability will be enhanced
   if these algorithms are included in all SPKM-3 implementations for
   which exportability is not a concern).  Confidentiality algorithms
   are used to generate the encrypted data for GSS_Wrap()/GSS_Unwrap.

   AES256-CBC

         id-aes256-CBC OBJECT IDENTIFIER ::= {
            joint-iso-itu-t(2) country(16) us(840) organization(1)
            gov(101) csor(3) nistAlgorithm(4) aes(1) 42 }

   This algorithm (RECOMMENDED) is defined in [RFC3565].

   AES128-CBC

         id-aes256-CBC OBJECT IDENTIFIER ::= {
            joint-iso-itu-t(2) country(16) us(840) organization(1)
            gov(101) csor(3) nistAlgorithm(4) aes(1) 2 }

   This algorithm (RECOMMENDED) is defined in [RFC3565].






Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 10]

Internet-Draft                   SPKM-3                       March                      August 2006


   DES-EDE3-CBC

         des-ede3-cbc OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) us(840) rsadsi(113549)
            encryptionAlgorithm(3) 7 }

   This algorithm (RECOMMENDED) is defined in [3DES].

   cast5CBC

         cast5CBC OBJECT IDENTIFIER ::= {
            iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
            algorithms(66) 10 }

         Parameters ::= SEQUENCE {
            iv OCTET STRING DEFAULT 0, - - Initialization vector
            keyLength INTEGER          - - Key length, in bits
         }

   This algorithm is included for backward compatibility with RFC2025.
   The reference for the OID and description of the (OPTIONAL) cast5CBC
   algorithm is [RFC2144].  The keyLength in the Parameters MUST be set
   to 128 bits.  PKCS#5 padding (standard block padding) is recommended.
   All input data MUST be padded to the block length (64-bits).

   AES256-CBC

         id-aes256-CBC OBJECT IDENTIFIER ::= {
            joint-iso-itu-t(2) country(16) us(840) organization(1)
            gov(101) csor(3) nistAlgorithm(4) aes(1) 42 }

   This algorithm (RECOMMENDED) is defined in [RFC3565].

   AES128-CBC

         id-aes256-CBC OBJECT IDENTIFIER ::= {
            joint-iso-itu-t(2) country(16) us(840) organization(1)
            gov(101) csor(3) nistAlgorithm(4) aes(1) 2 }

   This algorithm (RECOMMENDED) is defined in [RFC3565].

   DES-EDE3-CBC

         des-ede3-cbc OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) us(840) rsadsi(113549)
            encryptionAlgorithm(3) 7 }

   This algorithm (RECOMMENDED) is defined in XXX.>.

2.3.3  Key Establishment Algorithms (K-ALG)

   This algorithm type is used to establish a symmetric key for use by
   both the initiator and the target over the established context.  The
   keys used for C-ALG and any keyed I-ALGs (for example, DES-MAC) are
   derived from this context key.

   For SPKM-3, the key establishment algorithm must be dhKeyAgreement.



Adams, et al.            Expires October 1, 2006               [Page 11]

Internet-Draft                   SPKM-3                       March 2006
   This is because the initiator doesn't know the target's public key,
   and so cannot encrypt a session key with the target's public key.
















Adams, et al.           Expires February 19, 2007              [Page 11]

Internet-Draft                   SPKM-3                      August 2006


   dhKeyAgreement

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

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

   In this (MANDATORY) algorithm, the context key is generated jointly
   by the initiator and the target using the Diffie-Hellman key
   establishment algorithm. algorithm [RFC2631] [IEEE1363].  The DH public key is
   encoded as a BIT STRING according to [RFC3279].  Implementations MUST
   support Oakley 1024-bit Modular Exponential (MODP) well-known group 2
   [RFC2412] and Oakley 2048-bit MODP well-known group 14 [RFC3526] and
   SHOULD support Oakley 4096-bit MODP well-known group 16 [RFC3526].

2.3.4  One-Way Function (O-ALG) for Subkey Derivation Algorithm

   Having established a context key using the negotiated K-ALG, both
   initiator and target must be able to derive a set of subkeys for the
   various C-ALGs and keyed I-ALGs.  Let the (ordered) list of agreed
   C-ALGs be numbered consecutively, so that the first algorithm (the
   "default") is numbered "0", the next is numbered "1", and so on.  Let
   the numbering for the (ordered) list of agreed I-ALGs be identical.
   Finally, let the context key be a binary string of arbitrary length
   "M", subject to the following constraint:

   L < = M < = U

   where the lower limit "L" is the bit length of the longest key needed
   by any agreed C-ALG or keyed I-ALG, and the upper limit "U" is the
   largest bit size which will fit within the K-ALG parameters.

   For example, if cast5CBC and HMAC-MD5 are the negotiated
   confidentiality and integrity algorithms, then the context key must
   be at least 256 bits.  When the dhKeyAgreement is the K-ALG, then the
   length of the context key is the length of the Diffie-Hellman
   modulus, p, minus 8 bits.  It is recommended that, at least, p =
   1024.

   The derivation algorithm for a k-bit subkey is specified as follows:

   rightmost_k_bits(OWF(context_key || x || n || s || context_key))

   where




Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 12]

Internet-Draft                   SPKM-3                       March                      August 2006


   where

   -- "x" is the ASCII character "C" (0x43) if the subkey is for a
      confidentiality algorithm or the ASCII character "I" (0x49) if the
      subkey is for a keyed integrity algorithm;

   -- "n" is the number of the algorithm in the appropriate agreed list
      for the context (the ASCII character "0" (0x30), "1" (0x31), and
      so on);

   -- "s" is the "stage" of processing -- always the ASCII character "0"
      (0x30), unless "k" is greater than the output size of OWF, in
      which case the OWF is computed repeatedly with increasing ASCII
      values of "stage" (each OWF output being concatenated to the end
      of previous OWF outputs), until "k" bits have been generated;

   -- "||" is the concatenation operation; and

   -- "OWF" is any appropriate One-Way Function.

   It is recognized that existing hash functions may not satisfy
   required properties of OWFs.  This is the reason for allowing
   negotiation of the O-ALG OWF during the context establishment
   process, since in this way future improvements in OWF design can
   easily be accommodated.  For example, in some environments a
   preferred OWF technique might be an encryption algorithm which
   encrypts the input specified above using the context_key as the
   encryption key.

   [RFC2025] lists MD5 as a mandatory algorithm.  Since MD5 has been
   found to have weaknesses when used as a hash [Dobbertin], MD5 is
   excluded as an O-ALG for SPKM-3.

   ID-SHA1

         id-sha1 OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithms(2) 26 }

   The reference for the (MANDATORY) algorithm OID of id-sha1 is
   [RFC2437].  The reference for SHA-1 algorithm corresponding to id-
   sha1 is [FIPS].

2.4  Token Formats

   This section discusses protocol-visible characteristics of SPKM-3; it
   defines elements of protocol for interoperability and is independent
   of language bindings per [RFC2744].  Tokens transferred between GSS-



Adams, et al.           Expires February 19, 2007              [Page 13]

Internet-Draft                   SPKM-3                      August 2006


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



Adams, et al.            Expires October 1, 2006               [Page 13]

Internet-Draft                   SPKM-3                       March 2006

2.4.1  Context Establishment Tokens

   Two 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() and "Target" tokens, emitted by
   calls to GSS_Accept_sec_context() and consumed by calls to
   GSS_Init_sec_context().

   Per [RFC2743], Appendix B, all the tokens emitted by the SPKM-3 GSS-
   API GSS-API mechanism
   SHALL be enclosed within framing as follows:

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

                                 Figure 18

   The SPKM-3 innerContextToken is slightly different from the
   innerContextToken defined in [RFC2025].  Previously proposed SPKM-
   ERROR token lacks certificate information and without a directory
   information makes it impossible to verify the token.  Due to backward
   compatability,
   compatibility, we leave the old SPKM-ERROR token, but add a new token
   SPKM-GSS-ERROR which we describe in Section Section 2.4.2.2.  The new
   innerContextToken is defined as follows:

      SPKMInnerContextToken ::= CHOICE {
         req       [0] SPKM-REQ,
         rep-ti    [1] SPKM-REP-TI,
         rep-it    [2] SPKM-REP-IT,
         error     [3] SPKM-ERROR,
         mic       [4] SPKM-MIC,
         wrap      [5] SPKM-WRAP,
         del       [6] SPKM-DEL,
         gss-error
         gss-err   [7] SPKM-GSS-ERROR SPKM-GSS-ERROR,
         ...
      }

   The tag values provided in SPKMInnerContextToken ("[0]" through
   "[7]") specify a token-id for each token; similar information is
   contained in each token's tok-id field.  While seemingly redundant,
   the tag value and tok-id actually perform different tasks:  the tag
   ensures that InitialContextToken can be properly decoded; tok-id
   ensures, among other things, that data associated with the per-



Adams, et al.           Expires February 19, 2007              [Page 14]

Internet-Draft                   SPKM-3                      August 2006


   message tokens is cryptographically linked to the intended token
   type.  Every innerContextToken also includes a context-id field; see
   Section 2.9.1 for a discussion of both

   The following token types are defined:

      GSS_INIT_TOKEN   = 1
      GSS_ACCEPT_TOKEN = 2
      GSS_ERROR_TOKEN  = 3
      GSS_SIGN_TOKEN   = GSS_GETMIC_TOKEN = 4
      GSS_SEAL_TOKEN   = GSS_WRAP_TOKEN   = 5
      GSS_DELETE_TOKEN = 6
      GGS_NEW_ERROR_TOKEN = 7

   SPKM-3 implementation shall be able to perform the mapping from the
   token-id and context-id information and their use which is included in an SPKM-3 support function.



Adams, et al.            Expires October 1, 2006               [Page 14]

Internet-Draft                   SPKM-3                       March 2006 every token (through the
   tag values in SPKMInnerContextToken or through the tok-id field) to
   one of the above token types.

   All innerContextTokens are encoded using ASN.1 BER (constrained,  Distinguished
   Encoding Rules (DER) as described in
   the interests of parsing simplicity, [X690].  SPKM-3 proposes to use
   extensibility markers for most of the DER subset defined in
   [X509], clause 8.7). it's ASN1 structures.

   The SPKM-3 context establishment tokens are defined according to
   [X509] Section 10 and are compatible with [9798].  SPKM-3 uses
   Section 10.3, "Two-way Authentication", when performing unilateral
   authentication of the target to the initiator and uses Section 10.4,
   "Three-way Authentication", when mutual authentication is requested
   by the initiator.  SPKM-3 uses random numbers for replay detection
   during context establishment.  Sequence numbers are used to provide
   replay and out-of-sequence detection during the context
   initialization, if this has been requested by the application.

   SPKM-3 with mutual authentication sets up a context with an initiator
   first token (SPKM-REQ), a target reply token (SPKM-REP-TI), and
   finally an initiator second token (SPKM-REP-IT).  For SPKM-3 with
   unilateral authentication used by LIPKEY, the SPKM-REP-IT token is
   not used.  LIPKEY and SPKM-3 with mutual authentication place certain
   requirements on the contents of the SPKM-3 tokens, but the syntax of
   the SPKM-3 tokens are not different from [RFC2025] SPKM-1 tokens.

   SPKM-3's use of dhKeyAgreement and token options allows for the
   initiator and target to exchange all public-key certificate(s) needed
   to accomplish context establishment.

   SPKM-3 MUST support X509 v3 certificates.  The target always has an
   X.509 certificate and uses it to authenticate to the initiator.  In
   unilateral authentication, the initiator is an anonymous principal.
   In SPKM-3, certificate validation follows the TLS model where the



Adams, et al.           Expires February 19, 2007              [Page 15]

Internet-Draft                   SPKM-3                      August 2006


   source provides its certificate and the certification chain up to the
   root certificate (mutual authentication).  The target then provides
   its certificate and the certification chain up to the root
   certificate (unilateral and mutual authentication).  Thus, the
   certification data consists of the root certificate followed by any
   certificates required to reach the user certificate.

2.4.1.1  SPKM-REQ Token

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

      SPKM-REQ ::= SEQUENCE {
         requestToken      REQ-TOKEN,
         certif-data [0]   CertificationData OPTIONAL,
            -- for mutual authentication, certif-data MUST be present
         auth-data   [1]   AuthorizationData OPTIONAL
            -- see [RFC4120] for a discussion of auth-data



Adams, et al.            Expires October 1, 2006               [Page 15]

Internet-Draft                   SPKM-3                       March 2006
         ...
      }


      CertificationData ::= SEQUENCE {
         certificationPath [0]          CertificationPath OPTIONAL,
         certificateRevocationList [1]  CertificateList OPTIONAL OPTIONAL,
         ...
      }  -- at least one of the above shall be present


      CertificationPath ::= SEQUENCE {
         userKeyId         [0] OCTET STRING OPTIONAL,
            -- identifier for user's public key
         userCertif        [1] Certificate OPTIONAL,
            -- certificate containing user's public key
         verifKeyId        [2] OCTET STRING OPTIONAL,
            -- identifier for user's public verification key
         userVerifCertif   [3] Certificate OPTIONAL,
            -- certificate containing user's public verification key
         theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL OPTIONAL,
         ...
      }     -- certification path from target to source



       CertificatePair ::= SEQUENCE {
          issuedByThisCA   [0] Certificate OPTIONAL,
          issuedToThisCA   [1] Certificate OPTIONAL
       } -- SPKM-3 states that issuedByThisCA field is used.

   Having separate verification fields allows different key pairs



Adams, et al.           Expires February 19, 2007              [Page 16]

Internet-Draft                   SPKM-3                      August 2006


   (possibly corresponding to different algorithms) to be used for
   encryption/decryption and signing/verification.  In
   CertificationPath, presence of [0] or [1] and absence of [2] and [3]
   implies that the same key pair is to be used for enc/dec and verif/
   signing (note that this practice is not typically recommended).
   Presence of [2] or [3] implies that a separate key pair is to be used
   for verif/signing, and so [0] or [1] must also be present.  Presence
   of [4] implies that at least one of [0], [1], [2], and [3] must also
   be present.

   When using unilateral anonymous authentication, the optional SPKM-REQ
   certif-data field is not used.  When using mutual authentication, the
   CertificationPath userCertif field MUST contain the user (initiator)
   public-key certificate.  It is needed in order for the target to
   authenticate the initiator in a later step.








Adams, et al.            Expires October 1, 2006               [Page 16]

Internet-Draft                   SPKM-3                       March 2006

      REQ-TOKEN ::= SEQUENCE {
         req-contents     Req-contents,
         algId            AlgorithmIdentifier,
            -- in unilateral authentication, algId MUST be NULL-MAC
            -- in mutual authentication, algId MUST be one of
            -- the digital signature algorithms md5WithRSAEncryption,
            -- sha1WithRSAEncryptio, dsaWithSHA1
         req-integrity    Integrity    Integrity,
            -- "token" is Req-contents
         ...
      }


      Integrity ::= BIT STRING
         -- If corresponding algId specifies a signing algorithm,
         -- "Integrity" holds the result of applying the signing
         -- procedure specified in algId the string which results
         -- from applying the hashing procedure (also specified
         -- in algId) to the DER-encoded octets of "token".
         -- Alternatively, if corresponding algId specifies a
         -- MAC-ing algorithm, "Integrity" holds the result of applying
         -- the MAC-ing procedure specified in algId to the DER-encoded
         -- octets of "token" (note that for MAC, algId MUST be one of
         -- the integrity algorithms offered by the initiator with the
         -- appropriate subkey derived from the context key used as
         -- the key input)

   When using unilateral authentication, if the SPKM-3 initiator cannot
   calculate a req-integrity field due to the lack of a target
   certificate, it MUST use the NULL-MAC I-ALG described earlier in this
   memorandum.  This will produce a zero length bit string in the
   Integrity field.  When using mutual authentication, the algId needs



Adams, et al.           Expires February 19, 2007              [Page 17]

Internet-Draft                   SPKM-3                      August 2006


   to be one of md5WithRSAEncryption, or sha1WithRSAEncryption, or
   dsaWithSHA1.  The signature will be based on the initiator's private
   key that corresponds to the certificate included in the certif-data
   field of the SPKM-REQ token.

















Adams, et al.            Expires October 1, 2006               [Page 17]

Internet-Draft                   SPKM-3                       March 2006

      Req-contents ::= SEQUENCE {
         tok-id           INTEGER (256),    -- shall contain 0100 (hex)
         context-id       Random-Integer,   -- see Section 2.9.2
         pvno             BIT STRING,       -- protocol version number
         timestamp        UTCTime OPTIONAL,
         randSrc          Random-Integer,
         targ-name        Name,
            -- see Section 2.5.1.2 for construction and verification
            -- of the target name. The target can use the "targ-name"
            -- to select among available certificates.
         src-name [0]     Name OPTIONAL,
         req-data         Context-Data,
         validity [1]     Validity OPTIONAL,
            -- validity interval for key (may be used in the
            -- computation of security context lifetime)
         key-estb-set     Key-Estb-Algs,
            -- specifies the MANDATORY and only K-ALG, dhKeyAgreement
         key-estb-req     BIT STRING OPTIONAL,
            -- key estb. parameter corresponding to the initiator
            -- half of the dhKeyAgreement key.
            -- Established key MUST satisfy the key length constraints
            -- specified in Section 2.3.4.
         key-src-bind     OCTET STRING OPTIONAL OPTIONAL,
            -- will not be use in SPKM-3.
         }


      -- The protocol version number (pvno) parameter is a BIT STRING
      -- which uses as many bits as necessary to specify all the
      -- SPKM-3 protocol versions supported by the initiator
      -- (one bit per protocol version).  The protocol specified by
      -- this document is version 0.
      -- Bit 0 of pvno is therefore set if this version is supported;
      -- similarly, bit 1 is set if version 1 (if defined in the future)
      -- is supported, and so on.  The version of REQ-TOKEN MUST
      -- correspond to the highest bit set in pvno.
      -- The "validity" parameter above is the only way within SPKM-3
         auth-data        AuthorizationData OPTIONAL,
            -- see RFC1964 for the initiator to transmit desired context lifetime to the
      -- target.  Since it cannot be guaranteed that the initiator and
      -- target have synchronized time, the span a discussion of time specified by auth-data. note,
            -- "validity" auth-data is to be taken as definitive (rather than the actual
      -- times given in this parameter). integrity protected but not encrypted.
         ...
      }


      Random-Integer ::= BIT STRING
         -- Each SPKM-3 implementation is responsible for generating a
         -- "fresh" random number for the purpose of context
         -- establishment; that is, one which (with high probability)
         -- has not been used previously. There are no cryptographic
         -- requirements on this random number (i.e., it need not be
         -- unpredictable, it simply needs to be fresh).








Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 18]

Internet-Draft                   SPKM-3                       March                      August 2006


      Context-Data ::= SEQUENCE {
         channelId       ChannelId OPTIONAL, -- channel bindings
            -- SPKM-3 does not specify any channel bindings
         seq-number      INTEGER OPTIONAL,   -- sequence number
         options         Options,            -- GSS-API service options
         conf-alg        Conf-Algs,
            -- a list of confidentiality algorithms
         intg-alg        Intg-Algs,
            -- a list of  integrity algorithms
         owf-alg         OWF-Algs         OWF-Algs,
            -- a list of one-way functions for subkey derivation
         ...
      }


      ChannelId ::= OCTET STRING





      Options ::= BIT STRING {
         delegation-state (0), -- not supported by SPKM-3
         mutual-state (1),
         replay-det-state (2), -- used for replay det. during context
         sequence-state (3),   -- used for sequencing during context
         conf-avail (4),
         integ-avail (5),
         target-certif-data-required (6)
            -- used to request target's certificate data.
            -- it is always set to 1.
         ...
      }

   The SPKM-3 implementations MUST set the target-certif-data-required bit
   to 1 since (in most cases) the initiator does not have the target's
   certificate.

   A context establishment sequence based on SPKM-3 will perform
   unilateral authentication if mechanism implementation is responsible for maintaining a
   mapping between the mutual-req bit context-id value which is not set included in the
   application's call to GSS_Init_sec_context().  SPKM-3 accomplishes
   this using both SPKM-REQ every token
   and SPKM-REP-TI (thereby authenticating the
   target to a context_handle, thus associating an individual token with its
   proper context.  Clearly the initiator).

   Applications requiring authentication value of both peers (initiator context_handle may be locally
   determined and
   target) MUST request mutual authentication, resulting may, in "mutual-
   state" being fact, be associated with memory containing
   sensitive data on the local system, and so having the context-id
   actually be set within SPKM-REQ Options.  In response equal to such a
   request, computed context_handle will not work in
   general.  Conversely, having the context target context_handle actually be set equal
   to a computed context-id will reply not work in general either, because
   context_handle must be returned to the initiator with an SPKM-
   REP-TI token.  If SPKM-REP-TI is sent, application by the initiator will then reply first call
   to GSS_Init_sec_context() or GSS_Accept_sec_context(), whereas
   uniqueness of the context-id (over all contexts at both ends) may
   require that both initiator and target with an SPKM-REP-IT token, completing be involved in the (random-
   computation.  Consequently, context_handle and context-id must be



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 19]

Internet-Draft                   SPKM-3                       March                      August 2006


   number-based) mutual authentication


   computed separately and the mechanism implementation must be able to
   map from one to the other by the completion of context establishment exchange.

   Other bits in
   at the Options field latest.

   Computation of Context-Data are explained in
   [RFC2743].

      Conf-Algs ::= CHOICE {
         algs [0]        SEQUENCE OF AlgorithmIdentifier,
         null [1]        NULL
            -- used when conf. is not available over context-id during context
      }

      -- for C-ALG (see Section 2.8 for discussion of QOP)

   If the establishment is
   accomplished as follows.  Each SPKM-3 implementation supports an algorithm weaker than
   cast5CBC, cast5CBC MUST be listed before the weaker algorithm to
   encourage is responsible
   for generating a "fresh" random number; that is, one which (with high
   probability) has not been used previously.  Note that there are no
   cryptographic requirements on this random number (i.e., it need not
   be unpredictable, it simply needs to be fresh).  The initiator passes
   its random number to the target to negotiate in the stronger algorithm.

      Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier

      -- for I-ALG (see Section 2.8 for discussion context-id field of QOP)

   In the case where the initiator is anonymous and will not have a
   certificate SPKM-
   REQ token.  If no further context establishment tokens are expected
   (as for itself, unilateral authentication in SPKM-3), then this value is
   taken to be the initiator cannot use an integrity
   algorithm that supports non-repudiation; it MUST use a MAC algorithm.
   If context-id (if this is unacceptable to the SPKM-3 implementation supports target
   then an algorithm weaker than HMAC-
   MD5, HMAC-MD5 MUST error token must be listed before generated).  Otherwise, the weaker algorithm target
   generates its random number and concatenates it to encourage the target end of the
   initiator's random number.  This concatenated value is then taken to negotiate
   be the stronger algorithm.

      OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
         -- Contains exactly one algorithm in REQ-TOKEN for SPKM-3
         -- unilateral, context-id and contains at least one algorithm otherwise.
         -- Always contains exactly one algorithm is used in REP-TOKEN.


      Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
         -- to allow negotiation of K-ALG


2.4.1.2 SPKM-REP-TI Token



      SPKM-REP-TI ::= SEQUENCE {
         responseToken    REP-TI-TOKEN,
         certif-data      CertificationData
           -- and in all subsequent
   tokens over that context.

   Having both peers contribute to avoid "man-in-the-middle" attack, the target MUST
           -- sign responseToken using one context-id assures each peer of the digital signature
           -- algorithms
   freshness and include its certificate so that therefore precludes replay attacks between contexts
   (where a token from an old context between two peers is maliciously
   injected into a new context between the



Adams, et al.            Expires October 1, 2006               [Page 20]

Internet-Draft                   SPKM-3                       March 2006


           -- initiator can verify same or different peers).
   Such assurance is not available to the signature
      }

   In both target in the case of
   unilateral and mutual authentication in using SPKM-3, simply because it has not
   contributed to the target
   always sends it's public-key certificate and certification chain, and
   the field target-certif-data-required is always set.  The SPKM-REP-TI
   certif-data field is no longer OPTIONAL.

      REP-TI-TOKEN ::= SEQUENCE {
         rep-ti-contents Rep-ti-contents,
         algId           AlgorithmIdentifier,
            -- should be one freshness of the digital signature algorithms
         rep-ti-integ    Integrity  -- "token" is Rep-ti-contents
      }



      Rep-ti-contents ::= SEQUENCE {
         tok-id           INTEGER (512),   -- shall contain 0200 (hex) computed context-id       Random-Integer,  -- see Section 2.9.2
         pvno [0]         BIT STRING OPTIONAL, -- prot. (instead, it
   must trust the freshness of the initiator's random number, or reject
   the context).

   The protocol version number
         timestamp        UTCTime OPTIONAL,
         randTarg         Random-Integer,
         src-name [1]     Name OPTIONAL,
         targ-name        Name,
            -- MUST contain whatever value was supplied in REQ-TOKEN
         randSrc          Random-Integer,
            -- MUST contain whatever value was supplied in REQ-TOKEN
         rep-data         Context-Data,
         validity [2]     Validity  OPTIONAL,
            -- validity interval for key (used if the target can only
            -- support a shorter context lifetime than was offered in
            -- REQ-TOKEN)
         key-estb-id      AlgorithmIdentifier OPTIONAL,
            -- used if target is changing key estb. algorithm (MUST be
            -- a member of initiators key-estb-set)
         key-estb-str      BIT STRING OPTIONAL
            -- contains (1) the response to the initiators
            -- key-estb-req (if init. used a 2-pass K-ALG), or (2) the
            -- key-estb-req corresponding to the K-ALG supplied in
            -- above key-estb-id, or (3) the key-estb-req corresponding
            -- to the first K-ALG supplied in initiator's key-estb-id,
            -- if initiator's (OPTIONAL) key-estb-req was not used
            -- (target's key-estb-str MUST be present in this case).
            -- Established key MUST satisfy the key length constraints
            -- specified in Section 2.3.4.
      }




Adams, et al.            Expires October 1, 2006               [Page 21]

Internet-Draft                   SPKM-3                       March 2006


   The protocol version number (pvno) parameter (pvno) parameter is a BIT STRING which
   uses as many bits as necessary to specify a single SPKM protocol
   version offered by all the initiator which is SPKM-3 protocol
   versions supported by the target initiator (one bit per protocol version); that is, the target sets exactly one
   bit of pvno.  If none of the versions offered by the initiator are
   supported version).
   The protocol specified by the target, a error token MUST be returned so that the
   context this document is never established.  If the initiator's version 0.  Bit 0 of pvno has only one
   bit
   is therefore set and the target happens to support this protocol version, then if this version is used over supported; similarly, bit 1 is
   set if version 1 (if defined in the context future) is supported, and so on.
   The version of REQ-TOKEN MUST correspond to the pvno highest bit set in
   pvno.

   The "validity" parameter of REP-
   TI-TOKEN can above is the only way within SPKM-3 for the
   initiator to transmit desired context lifetime to the target.  Since
   it cannot be omitted.  Finally, if guaranteed that the initiator and target do have one or more versions in common but
   synchronized time, the version span of the REQ-TOKEN
   received is not supported time specified by the target, a REP-TI-TOKEN must "validity" is to be sent
   with a desired version bit set in pvno (and dummy values used for all
   subsequent token fields).  The initiator can then respond with a new
   REQ-TOKEN of
   taken as definitive (rather than the proper version (essentially starting context
   establishment anew).

   The actual times given in this
   parameter).

   SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it implementations MUST use a
   signature algorithm like md5WithRSAEncryption, sha1WithRSAEncryption,
   or dsaWithSHA1.

   If set the req-token has an algId of NULL-MAC, then target-certif-data-required bit
   to 1 since (in most cases) the target MUST
   compute initiator does not have the rep-ti-integ target's



Adams, et al.           Expires February 19, 2007              [Page 20]

Internet-Draft                   SPKM-3                      August 2006


   certificate.

   A context establishment sequence based on SPKM-3 will perform
   unilateral authentication if the concatenation of mutual-req bit is not set in the req-contents
   application's call to GSS_Init_sec_context().  SPKM-3 accomplishes
   this using both SPKM-REQ and
   rep-ti-contents.

   When mutual authentication is used, SPKM-REP-TI (thereby authenticating the
   target verifies to the
   initiator's initiator).

   Applications requiring authentication of both peers (initiator and
   target) MUST request mutual authentication, resulting in "mutual-
   state" being set within SPKM-REQ token by verifying that the req-integrity field
   was computed by Options.  In response to such a
   request, the owner of context target will reply to the userCertif field.  This initiator with an SPKM-
   REP-TI token.  If SPKM-REP-TI is phase 1
   of authenticating sent, the target.

   A note for implementators.  Let's assume that initiator will then reply
   to the requestor calls target with an SPKM-REP-IT token, completing the
   GSS_Init_sec_context() and does not request integrity or
   confidentiality services and, therefore, only (random-
   number-based) mutual authentication step is
   required.  An artifact context establishment exchange.

   Other bits in the Options field of [RFC-2025] mandates that Context-Data
   contains conf-alg, intg-alg, and owf-alg.  Therefore to be backward
   compatable, we require that intg-alg and owf-alg are negotiated
   (since conf-alg explained in
   [RFC2743].

      Conf-Algs ::= CHOICE {
         algs [0]        SEQUENCE OF AlgorithmIdentifier,
         null [1]        NULL,
            -- used when conf. is a CHOICE, it can be null).  However, a better
   solution would not available over context
         ...
      }

      -- for C-ALG (see Section 2.8 for discussion of QOP)

   If the SPKM-3 implementation supports an algorithm weaker than
   cast5CBC, cast5CBC MUST be listed before the weaker algorithm to make conf-alg, intg-alg, and owf-alg OPTIONAL.

2.4.1.3  SPKM-REP-IT Token

   When mutual authentication is requested,
   encourage the target to negotiate the stronger algorithm.

      Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier

      -- for I-ALG (see Section 2.8 for discussion of QOP)

   In the case where the initiator must construct
   a SPKM-REP-IT token.  This is because attackers could replay SPKM-REQ
   tokens, anonymous and since the target doesn't will not have a
   certificate for itself, the initiator cannot use an infinite cache, and
   since SPKM-3 does not require synchronized time, integrity
   algorithm that uses a 3-way handshake is
   needed.

   Relevant SPKM-REP-IT syntax is as follows:



Adams, et al.            Expires October 1, 2006               [Page 22]

Internet-Draft digital signature; it MUST use a MAC algorithm.
   If the SPKM-3                       March 2006


      SPKM-REP-IT implementation supports an algorithm weaker than HMAC-
   MD5, HMAC-MD5 MUST be listed before the weaker algorithm to encourage
   the target to negotiate the stronger algorithm.

      OWF-Algs ::= SEQUENCE {
         responseToken    REP-IT-TOKEN,
         algId            AlgorithmIdentifier, OF AlgorithmIdentifier
         -- MUST contain whatever value was supplied Contains exactly one algorithm in REQ-TOKEN
         rep-it-integ     Integrity for SPKM-3
         -- "token" unilateral, and contains at least one algorithm otherwise.
         -- Always contains exactly one algorithm in REP-TOKEN.




Adams, et al.           Expires February 19, 2007              [Page 21]

Internet-Draft                   SPKM-3                      August 2006


      Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
         -- to allow negotiation of K-ALG


2.4.1.2  SPKM-REP-TI Token



      SPKM-REP-TI ::= SEQUENCE {
         responseToken    REP-TI-TOKEN,
         certif-data      CertificationData,
           -- to avoid "man-in-the-middle" attack, the target MUST
           -- sign responseToken using one of the digital signature
           -- algorithms and include its certificate so that the
           -- initiator can verify the signature
         ...
      }

   In both unilateral and mutual authentication in SPKM-3, the target
   always sends it's public-key certificate and certification chain, and
   the field target-certif-data-required is REP-IT-TOKEN always set.  The SPKM-REP-TI
   certif-data field is no longer OPTIONAL.

      REP-TI-TOKEN ::= SEQUENCE {
         rep-ti-contents Rep-ti-contents,
         algId           AlgorithmIdentifier,
            -- should be one of the digital signature algorithms
         rep-ti-integ    Integrity,  -- "token" is Rep-ti-contents
         ...
      }


      REP-IT-TOKEN





















Adams, et al.           Expires February 19, 2007              [Page 22]

Internet-Draft                   SPKM-3                      August 2006


      Rep-ti-contents ::= SEQUENCE {
         tok-id           INTEGER (768), (512),   -- shall contain 0300 0200 (hex)
         context-id       Random-Integer,  -- see Section 2.9.2
         randSrc
         pvno [0]         BIT STRING OPTIONAL, -- prot. version number
         timestamp        UTCTime OPTIONAL,
         randTarg         Random-Integer,
         src-name [1]     Name OPTIONAL,
         targ-name        Name,
            -- MUST contain whatever value was supplied in REQ-TOKEN
         randTarg
            -- See Section 2.5.1.2 for construction and verification of
            -- the targ-name. The initiator MUST verify that it is
            -- talking to the right target.
         randSrc          Random-Integer,
            -- MUST contain whatever value was supplied in REP-TI-TOKEN
         targ-name        Name, REQ-TOKEN
         rep-data         Context-Data,
         validity [2]     Validity  OPTIONAL,
            -- MUST contain whatever value validity interval for key (used if the target can only
            -- support a shorter context lifetime than was supplied offered in REP-TI-TOKEN
         src-name         Name
            -- REQ-TOKEN)
         key-estb-id      AlgorithmIdentifier OPTIONAL,
         key-estb-rep
            -- used if target is changing key estb. algorithm (MUST be
            -- a member of initiators key-estb-set)
         key-estb-str      BIT STRING OPTIONAL OPTIONAL,
            -- contains (1) the response to targets key-estb-str the initiators
            -- key-estb-req (if target selected init. used a 2-pass K-ALG)
      }

   The randTarg field in K-ALG), or (2) the SPKM-REP-IT responseToken is randomly
   generated by
            -- key-estb-req corresponding to the initiator, and so should be K-ALG supplied in
            -- above key-estb-id, or (3) the same value that key-estb-req corresponding
            -- to the first K-ALG supplied in initiator's key-estb-id,
            -- if initiator's (OPTIONAL) key-estb-req was not used
            -- (target's key-estb-str MUST be present in this case).
            -- Established key MUST satisfy the SPKM-REP-TI rep-ti-contents randTarg field. key length constraints
            -- specified in Section 2.3.4.
         auth-data        AuthorizationData OPTIONAL,
         ...
      }

   The SPKM-REP-IT token algId field used protocol version number (pvno) parameter is a BIT STRING which
   uses as many bits as necessary to create specify a single SPKM protocol
   version offered by the rep-it-integ
   field should use md5WithRSAEncryption, sha1WithRSAEncryption, or
   dsaWithSHA2.  The initiator verifies the SPKM-REP-IT token which is supported by
   verifying that the req-it-integ field was computed by target
   (one bit per protocol version); that is, the owner target sets exactly one
   bit of pvno.  If none of the targets certificate, obtained in versions offered by the SPKM-REP-TI certif-data
   certificationPath userCertif field.

2.4.2  Error Tokens

2.4.2.1  SPKM-ERROR Token

   "Error" tokens initiator are potentially emitted by calls to
   GSS_Init_sec_context() or GSS_Accept_sec_context(), and potentially
   consumed
   supported by calls to GSS_Init_sec_context() or
   GSS_Accept_sec_context().  The SPKM-ERROR token proposed in [RFC-
   2025] is left in SPKM-3 only for backward compatability.  The new the target, a error token MUST be returned so that the
   context is described in never established.  If the next section.  The syntax of initiator's pvno has only one
   bit set and the
   SPKM-ERROR target happens to support this protocol version, then
   this version is as follows: used over the context and the pvno parameter of REP-
   TI-TOKEN can be omitted.  Finally, if the initiator and target do
   have one or more versions in common but the version of the REQ-TOKEN
   received is not supported by the target, a REP-TI-TOKEN must be sent



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 23]

Internet-Draft                   SPKM-3                       March                      August 2006


      SPKM-ERROR ::= SEQUENCE {
         error-token      ERROR-TOKEN,
         algId            AlgorithmIdentifier,
           -- MUST be one


   with a desired version bit set in pvno (and dummy values used for all
   subsequent token fields).  The initiator can then respond with a new
   REQ-TOKEN of the digital proper version (essentially starting context
   establishment anew).

   The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a
   signature algorithms
         integrity        Integrity  -- "token" is ERROR-TOKEN
      }

      ERROR-TOKEN ::=   SEQUENCE {
         tok-id           INTEGER (1024), -- shall contain 0400 (hex)
         context-id       Random-Integer
      }



2.4.2.2  SPKM-GSS-ERROR Token

   SPKM-ERROR token lacks the certificate used to compute algorithm like md5WithRSAEncryption, sha1WithRSAEncryption,
   or dsaWithSHA1.

   If the integrity req-token has an algId of NULL-MAC, then the token.  In the low infrastructure and target MUST
   compute the absence of directory
   services, rep-ti-integ on the receiving side concatenation of the SPKM-ERROR token req-contents and
   rep-ti-contents.

   When mutual authentication is therefore
   unable to verify used, the integrity of target verifies the SPKM-ERROR.  Therefore, in
   initiator's SPKM-REQ token by verifying that the
   SPKM-GSS-ERROR token, we propose to add certificate information.
   Furthermore, req-integrity field
   was computed by the old token lacks any information regarding owner of the error userCertif field.  This is phase 1
   of authenticating the target.

   A note for implementors.  Let's assume that had occuried.  Therefore, in the SPKM-GSS-ERROR token, we
   propose to add requestor calls the return major_status
   GSS_Init_sec_context() and minor_status values of
   GSS_init_sec_context() does not request integrity or GSS_accept_sec_context().  The syntax
   confidentiality services and, therefore, only authentication step is
   required.  An artifact of
   SPKM-GSS-ERROR [RFC-2025] mandates that Context-Data
   contains conf-alg, intg-alg, and owf-alg.  Therefore to be backward
   compatible, we require that intg-alg and owf-alg are negotiated
   (since conf-alg is a CHOICE, it can be null).  However, a better
   solution would be to make conf-alg, intg-alg, and owf-alg OPTIONAL.

2.4.1.3  SPKM-REP-IT Token

   When mutual authentication is requested, the initiator must construct
   a SPKM-REP-IT token.  This is because attackers could replay SPKM-REQ
   tokens, and since the target doesn't have an infinite cache, and
   since SPKM-3 does not require synchronized time, a 3-way handshake is
   needed.

   Relevant SPKM-REP-IT syntax is as follows:

      SPKM-GSS-ERROR

      SPKM-REP-IT ::= SEQUENCE {
         error-token      ERROR-TOKEN,
         certif-data      CertificationData,
         responseToken    REP-IT-TOKEN,
         algId            AlgorithmIdentifier,
            -- MUST be one of the digital signature algorithms
         integrity        Integrity contain whatever value was supplied in REQ-TOKEN
         rep-it-integ     Integrity,  -- "token" is ERROR-TOKEN REP-IT-TOKEN
         ...
      }

      ERROR-TOKEN







Adams, et al.           Expires February 19, 2007              [Page 24]

Internet-Draft                   SPKM-3                      August 2006


      REP-IT-TOKEN ::= SEQUENCE {
         tok-id           INTEGER (1024), (768),  -- shall contain 0400 0300 (hex)
         context-id       Random-Integer       Random-Integer, -- if sent by target, this field should see Section 2.9.2
         randSrc          Random-Integer,
            -- MUST contain the whatever value
           -- of the context-id was supplied in Req-contents REQ-TOKEN
         randTarg         Random-Integer,
            -- if sent by initiator, this field should MUST contain the
           -- whatever value of the context-id was supplied in Rep-ti-contents
         major-status [0] INTEGER REP-TI-TOKEN
         targ-name        Name,
            -- the GSS major status MUST contain whatever value
         minor-status [1] INTEGER was supplied in REP-TI-TOKEN
         src-name         Name OPTIONAL,
         key-estb-rep     BIT STRING OPTIONAL,
            -- contains the GSS minor status value response to targets key-estb-str
            -- (if target selected a 2-pass K-ALG)
         ...
      }


   As with the old token,

   The randTarg field in the SPKM-GSS-ERROR token SPKM-REP-IT responseToken is randomly
   generated by the initiator, and so should be the same value that was
   in the SPKM-REP-TI rep-ti-contents randTarg field.

   The SPKM-REP-IT token algId field used to create the rep-it-integ
   field should use md5WithRSAEncryption, sha1WithRSAEncryption, or
   dsaWithSHA2.  The initiator verifies the SPKM-REP-IT token by
   verifying that the req-it-integ field was computed by the owner of
   the targets certificate, obtained in the SPKM-REP-TI certif-data
   certificationPath userCertif field.

2.4.2  Error Tokens

2.4.2.1  SPKM-ERROR Token

   "Error" tokens are potentially emitted by calls to
   GSS_Init_sec_context() or GSS_Accept_sec_context(), and potentially
   consumed by calls to GSS_Init_sec_context() or
   GSS_Accept_sec_context().  The SPKM-ERROR token proposed in [RFC-
   2025] is left in SPKM-3 only during for backward compatibility.  The new
   error token is described in the next section.  The syntax of the
   SPKM-ERROR is as follows:













Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 24] 25]

Internet-Draft                   SPKM-3                       March                      August 2006


      SPKM-ERROR ::= SEQUENCE {
         error-token      ERROR-TOKEN,
         algId            AlgorithmIdentifier,
           -- MUST be one of the context establishment process.  If an SPKM-REQ or SPKM-REP-TI
   token digital signature algorithms
         integrity        Integrity  -- "token" is received in error, the receiving function (either
   GSS_Init_sec_context() or GSS_Accept_sec_context()) will generate an ERROR-TOKEN
      }

      ERROR-TOKEN ::=   SEQUENCE {
         tok-id           INTEGER (1024), -- shall contain 0400 (hex)
         context-id       Random-Integer
      }



2.4.2.2  SPKM-GSS-ERROR Token

   SPKM-ERROR token lacks the certificate used to be sent to compute the peer (if integrity
   of the peer is still in token.  In the context establishment process) low infrastructure and will return
   GSS_S_CONTINUE_NEEDED.  If, on the other hand, no context
   establishment response is expected from absence of directory
   services, the peer (i.e., receiving side of the peer has
   completed context establishment), SPKM-ERROR token is therefore
   unable to verify the function will return integrity of the
   appropriate major SPKM-ERROR.  Therefore, in the
   SPKM-GSS-ERROR token, we propose to add certificate information.
   Furthermore, the old token lacks any information regarding the error
   that had occurred.  Therefore, in the SPKM-GSS-ERROR token, we
   propose to add the return major_status and minor_status values of
   GSS_init_sec_context() or GSS_accept_sec_context().  The syntax of
   SPKM-GSS-ERROR is as follows:

      SPKM-GSS-ERROR ::= SEQUENCE {
         error-token      GSS-ERROR-TOKEN,
         algId            AlgorithmIdentifier,
         certif-data      CertificationData,
           -- MUST be one of the digital signature algorithms
         integrity        Integrity,  -- "token" is ERROR-TOKEN
         ...
      }

      GSS-ERROR-TOKEN ::=   SEQUENCE {
         tok-id           INTEGER (1280), -- shall contain 0500 (hex)
         context-id       Random-Integer,
           -- if sent by target, this field should contain the value
           -- of the context-id in Req-contents
           -- if sent by initiator, this field should contain the
           -- value of the context-id in Rep-ti-contents
         major-status [0] INTEGER,  -- the GSS major status value
         minor-status [1] INTEGER,  -- the GSS minor status value
         ...
      }




Adams, et al.           Expires February 19, 2007              [Page 26]

Internet-Draft                   SPKM-3                      August 2006


   As with the old token, the SPKM-GSS-ERROR token is used only during
   the context establishment process.  If an SPKM-REQ or SPKM-REP-TI
   token is received in error, the receiving function (either
   GSS_Init_sec_context() or GSS_Accept_sec_context()) will generate an
   SPKM-GSS-ERROR token to be sent to the peer (if the peer is still in
   the context establishment process) and will return
   GSS_S_CONTINUE_NEEDED.  If, on the other hand, no context
   establishment response is expected from the peer (i.e., the peer has
   completed context establishment), the function will return the
   appropriate major status code (e.g., GSS_S_BAD_SIG) along with a
   minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-
   relevant information will be deleted.

   If GSS_Init_sec_context() receives an error token (whether valid or
   invalid), the initiator decides if it can recover from the error sent
   by the target.  If not, the initiator will regenerate SPKM-REQ as its output create an error token with
   major status of GSS_S_FAILURE and the minor status
   GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and will return
   GSS_S_CONTINUE_NEEDED along with the token.  If the initiator can
   recover from the error, it will regenerate SPKM-REQ as its output
   token and return a major status code of GSS_S_CONTINUE_NEEDED.  (Note
   that if the peer's GSS_Accept_sec_context() receives SPKM-REQ token
   when it is expecting a SPKM-REP-IT token, it will ignore SPKM-REQ and
   return a zero-length output token with a major status of
   GSS_S_CONTINUE_NEEDED.)

   Similarly, if GSS_Accept_sec_context() receives an error token
   (whether valid or invalid), invalid) when it was expecting an SPKM-REP-IT
   token, if the target decides to recover from the error sent by the
   initiator, the target will regenerate SPKM-REP-TI as its output token
   and return a major status code of GSS_S_CONTINUE_NEEDED.  If the
   target can not cover, it should return an appropriate major status
   code (e.g., GSS_S_NO_CRED) along with a minor status of
   GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-relevant information
   will be deleted.

   If GSS_Accept_sec_context() receives an error token when it was
   expecting an SPKM-REQ token, it should return an appropriate major
   status code (e.g., GSS_S_BAD_SIG) along with a minor status of
   GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-relevant information
   will be deleted.

   md5WithRsaEncryption is currently stipulated for the signing of
   context establishment tokens.  Discrepancies involving modulus
   bitlength can be resolved through judicious use of the SPKM-GSS-ERROR
   token.  The context initiator signs REQ-TOKEN using the strongest RSA
   it supports (e.g., 1024 bits).  If the target is unable to verify
   signatures of this length, it sends SPKM-GSS- ERROR signed with the



Adams, et al.           Expires February 19, 2007              [Page 27]

Internet-Draft                   SPKM-3                      August 2006


   strongest RSA that it supports (e.g. 512).  Furthermore, the target
   can include an appropriate minor_status value
   (GSS_SPKM_S_SG_WEAK_KEY).

   At the completion of this exchange, both sides know what RSA
   bitlength the other supports, since the size of the signature is
   equal to the size of the modulus.  Further exchanges can be made
   (using successively smaller supported bitlengths) until either an
   agreement is reached or context establishment is aborted because no
   agreement is possible.

2.4.3  Per-message Tokens

   Three classes of tokens are defined in this section: "MIC" tokens,
   emitted by calls to GSS_GetMIC() and consumed by calls to
   GSS_VerifyMIC(); "Wrap" tokens, emitted by calls to GSS_Wrap() and
   consumed by calls to GSS_Unwrap().




Adams, et al.            Expires October 1, 2006               [Page 25]

Internet-Draft                   SPKM-3                       March 2006

2.4.3.1  SPKM-MIC Tokens Token

   Use of the GSS_wrap() / GSS_GetMIC() 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 may be
   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-MIC token has the following format:

      SPKM-MIC ::= SEQUENCE {
         mic-header       Mic-Header,
         int-cksum        BIT STRING STRING,
            -- Checksum over header and data, calculated according to
            -- algorithm specified in int-alg field.
         ...
      }


      Mic-Header ::= SEQUENCE {
         tok-id           INTEGER (257),   -- shall contain 0101 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
            -- Integrity algorithm indicator (MUST be one of the agreed
            -- integrity algorithms for this context).
            -- field not present = default id.
         snd-seq [1]      SeqNum OPTIONAL OPTIONAL,  -- sequence number field.
         ...
      }



Adams, et al.           Expires February 19, 2007              [Page 28]

Internet-Draft                   SPKM-3                      August 2006


      SeqNum ::= SEQUENCE {
         num      INTEGER, -- the sequence number itself
         dir-ind  BOOLEAN  BOOLEAN,  -- a direction indicator
         ...
      }


2.4.3.1.1  Checksum

   Checksum calculation procedure (common to all algorithms -- note that
   for SPKM-3 the term "checksum" includes digital signatures as well as
   hashes and MACs): Checksums are calculated over the data field,
   logically prepended by the bytes of the plaintext token header (mic-
   header).  The result binds the data to the entire plaintext header,
   so as to minimize the possibility of malicious splicing.

   For example, if the int-alg specifies the md5WithRSAEncryption
   algorithm, then the checksum is formed by computing an MD5 [RFC1321]
   hash over the plaintext data (prepended by the header), and then



Adams, et al.            Expires October 1, 2006               [Page 26]

Internet-Draft                   SPKM-3                       March 2006
   computing an RSA signature [PKCS1] on the 16-byte MD5 result.  The
   signature is computed using the RSA private key retrieved from the
   credential 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 appropriate
   subkey derived from the context key (see Section 2.3.4).  Again, the
   result (whose length is implied by int-alg) is stored in the int-
   cksum field.  For block cipher-based algorithms, before encryption
   plaintext data is padded to the next highest multiple of the block
   size (8bytes for DES-based algorithms), by appending between 1 and
   block size bytes, the value of each such byte being the total number
   of pad bytes.

2.4.3.1.2  Sequence Number

   It is assumed that the underlying transport layers (of whatever
   protocol 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, sequence numbers are used in SPKM-3 purely for security,
   as opposed to reliability, reasons (that is, to avoid malicious loss,
   replay, or re-ordering of SPKM-3 tokens) -- it is therefore
   recommended that applications request sequencing and replay detection
   over all contexts.  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



Adams, et al.           Expires February 19, 2007              [Page 29]

Internet-Draft                   SPKM-3                      August 2006


   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 sequence number field is formed from the
   sender's four-byte sequence number and a Boolean direction-indicator
   (FALSE - sender is the context initiator, TRUE - sender is the
   context acceptor).  After constructing a GSS_GetMIC() or GSS_Wrap()
   token, the sender's seq. number is incremented by 1.

2.4.3.1.3  Sequence Number Processing

   The receiver of the token will verify the sequence number field by
   comparing the sequence number with the expected sequence number and
   the direction indicator with the expected direction indicator.  If
   the sequence number in the token is higher than the expected number,
   then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is
   returned.  If the token sequence number is lower than the expected



Adams, et al.            Expires October 1, 2006               [Page 27]

Internet-Draft                   SPKM-3                       March 2006
   number, then the expected sequence number is not adjusted and
   GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is
   returned, whichever is appropriate.  If the direction indicator is
   wrong, then the expected sequence number is not adjusted and
   GSS_S_UNSEQ_TOKEN is returned.

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

2.4.3.2  SPKM-WRAP Tokens Token

   Use of the GSS_Wrap() call yields a token which encapsulates the
   input user data (optionally encrypted) along with associated
   integrity check quantities.  The token emitted by GSS_Wrap() consists
   of an integrity header followed by a body portion that contains
   either the plaintext data (if conf-alg = NULL) or encrypted data
   (using the appropriate subkey specified in Section Section 2.3.4 for
   one of the agreed C-ALGs for this context).

   The SPKM-WRAP token has the following format:

      SPKM-WRAP ::= SEQUENCE {
         wrap-header       Wrap-Header,
         wrap-body         Wrap-Body         Wrap-Body,
         ...
      }



Adams, et al.           Expires February 19, 2007              [Page 30]

Internet-Draft                   SPKM-3                      August 2006


      Wrap-Header ::= SEQUENCE {
         tok-id           INTEGER (513),   -- shall contain 0201 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
            -- Integrity algorithm indicator (MUST be one of
            -- the agreed integrity algorithms for this context).
            -- field not present = default id.
         conf-alg [1]     Conf-Alg OPTIONAL,
            -- Confidentiality algorithm indicator (MUST be NULL
            -- or one of the agreed confidentiality algorithms
            -- for this context).
            -- field not present = default id.
            -- NULL = none (no conf. applied).
         snd-seq [2]      SeqNum OPTIONAL OPTIONAL, -- sequence number field. field
         ...
      }






Adams, et al.            Expires October 1, 2006               [Page 28]

Internet-Draft                   SPKM-3                       March 2006


      Wrap-Body ::= SEQUENCE {
         int-cksum        BIT STRING,
            -- Checksum of header and data, calculated according
            -- to algorithm specified in int-alg field.
         data             BIT STRING STRING,
            -- encrypted or plaintext data.
         ...
      }


      Conf-Alg ::= CHOICE {
         algId [0]        AlgorithmIdentifier,
         null [1]         NULL         NULL,
         ...
      }


2.4.3.2.1  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 (wrap-header).  As with
   GSS_GetMIC(), the result binds the data to the entire plaintext
   header, so as to minimize the possibility of malicious splicing.

   The examples for md5WithRSA and DES-MAC are exactly as specified in
   Section 2.4.3.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



Adams, et al.           Expires February 19, 2007              [Page 31]

Internet-Draft                   SPKM-3                      August 2006


   Section 2.4.3.1.1 and the result is stored in int-cksum.  However, if
   conf-alg specifies DES-CBC then the encryption and the integrity are
   done as follows.  An MD5 [RFC1321] 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 DES-CBC subkey (see
   Section 2.3.4) and placed in the "data" field of Wrap-Body.  The
   final two blocks of ciphertext (i.e., the encrypted MD5 hash) are
   also placed in the int-cksum field of Wrap-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-3 will return an error).  Encryption and integrity are done
   in a single pass using the DES-CBC subkey 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



Adams, et al.            Expires October 1, 2006               [Page 29]

Internet-Draft                   SPKM-3                       March 2006
   is then CBC encrypted and placed in the "data" field of Wrap-Body.
   The final block of ciphertext (i.e., the encrypted sum) is also
   placed in the int-cksum field of Wrap-Body as the integrity checksum.

2.4.3.2.2  Sequence Number

   Sequence numbers are computed and processed for GSS_Wrap() exactly as
   specified in Section 2.4.3.1.3 and Section 2.4.3.1.3.

2.4.3.2.3  Data Encryption

   The following procedure is followed unless (a) conf-alg is NULL (no
   encryption), or (b) conf-alg is DES-CBC and int-alg is md5-DES-CBC
   (encryption as specified in Section 2.4.3.2.1), or (c) int-alg is
   sum64-DES-CBC (encryption as specified in Section 2.4.3.2.1):

   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.  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 the appropriate subkey derived
   from the established context key using the subkey derivation
   algorithm described in Section Section 2.3.4 (this ensures that the
   subkey used for encryption and the subkey used for a separate, keyed
   integrity algorithm -- for example DES-MAC, but not sum64-DES-CBC --
   are different).  For block cipher-based algorithms, before encryption
   plaintext data is padded to the next highest multiple of the block



Adams, et al.           Expires February 19, 2007              [Page 32]

Internet-Draft                   SPKM-3                      August 2006


   size (8bytes for DES-based algorithms), by appending between 1 and
   block size bytes, the value of each such byte being the total number
   of pad bytes.

2.4.4  Context Deletion Token

   The token emitted by GSS_Delete_sec_context() is based on the format
   for tokens emitted by GSS_GetMIC().  [RFC-2743]  [RFC2743] includes
   GSS_Delete_sec_context() only for backward compatibility with GSS-API
   Version 1.  Therefore, in SPKM-3 we propose to follow the procedure
   recommended in [RFC-2743]. [RFC2743].  Both peers should invoke
   GSS_Delete_sec_context() independently and pass a null
   output_context_token buffer to indicate that no context_token is
   required but should delete relevant locally-stored context
   information.  Peers should signal the deletion of context via other
   channel (eg., closing a network connection, or a higher level error
   message such as an RPCSEC_GSS error message).

   The SPKM-DEL token has the following format:




Adams, et al.            Expires October 1, 2006               [Page 30]

Internet-Draft                   SPKM-3                       March 2006

      SPKM-DEL ::= SEQUENCE {
         del-header       Del-Header,
         int-cksum        BIT STRING
            -- Checksum of header, calculated according to algorithm
            -- specified in int-alg field.
      }


      Del-Header ::= SEQUENCE {
         tok-id           INTEGER (769),
            -- shall contain 0301 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
            -- Integrity algorithm indicator (MUST be one of the agreed
            -- integrity algorithms for this context).
            -- field not present = default id.
         snd-seq [1]      SeqNum OPTIONAL
            -- sequence number field.
      }

   The field snd-seq will be calculated as for tokens emitted by
   GSS_GetMIC().  The field int-cksum will be calculated as for tokens
   emitted by GSS_GetMIC(), except that the user-data component of the
   checksum data will be a zero-length string.

   If a valid delete token is received, then the SPKM-3 implementation
   will delete the context and GSS_Process_context_token() will return a
   major status of GSS_S_COMPLETE and a minor status of



Adams, et al.           Expires February 19, 2007              [Page 33]

Internet-Draft                   SPKM-3                      August 2006


   GSS_SPKM_S_SG_CONTEXT_DELETED.  If, on the other hand, the delete
   token is invalid, the context will not be deleted and
   GSS_Process_context_token() will return the appropriate major status
   (GSS_S_BAD_SIG, for example) and a minor status of
   GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD.  The application may wish to
   take some action at this point to check the context status (such as
   sending a sealed/wrapped test message to its peer and waiting for a
   sealed/wrapped response).

2.5  Name Types and Object Identifiers

   In this section, we clarify

   This section discusses the construction name types which may be passed as input to
   the SPKM3's GSS_Import_name() call, and verification their associated identifier
   values.

2.5.1  Mandatory Name Forms

   This section discusses name forms which are to be supported by all
   conformant implementations of
   names in SPKM-3. src-name represents the initiator and targ-name
   represents SPKM3 GSS-API mechanism.

2.5.1.1  SPKM3 Principal Name Form

   This name form shall be represented by the target.  In anonymous SPKM-3, src-name Object Identifier (FIXME:
   need an OID).  The recommended symbolic name for this type is not filled
   out.  In mutual SPKM-3, having a src-name in
   GSS_SPKM3_NT_PRINCIPAL_NAME.

   This name type corresponds to the Req-contents does
   not add string representation of an X500
   Distinguished Name.  It is an RFC2253 [RFC2253] compliant string
   representation of the distinguished name.

2.5.1.2  Host-Based Service Name Form

   This name form is used to security.  The target retrieves represent services associated with host
   computers and should use the subject symbolic name from of
   GSS_C_NT_HOSTBASED_SERVICE.  This name form is constructed using two
   elements, "service" and "hostname", as follows: "service@hostname".
   If only "service" is specified as an input, then the
   supplied certificate. default of the
   localhost's "hostname" is used.

   The initiator always constructs a target name.  We assume that during
   the construction of the REQ-TOKEN the initiator has no access to the



Adams, et al.            Expires October 1, 2006               [Page 31]

Internet-Draft                   SPKM-3                       March 2006
   target's certificate and therefore has to construct the target name
   with the information provided by the application which might be of
   the form "service@host" which is of GSS_C_NT_HOSTBASED_SERVICE name
   type.  In such case, "host" is canonicalized by attempting a DNS lookup and using
   the fully-qualified domain name which is returned, or by using the
   "host" as provided if the DNS lookup fails.  Then, the initiator
   should convert the GSS_C_NT_HOSTBASED_SERVICE name to



Adams, et al.           Expires February 19, 2007              [Page 34]

Internet-Draft                   SPKM-3                      August 2006


   GSS_SPKM3_NT_PRINCIPAL_NAME name by first writing it as a common name
   "CN=service/host", encoded then, encoding it in a single RDN sequence.

   When the initiator processes REP-TI-TOKEN, it verifies that target
   name is the initiator constructed matches the information in the
   target's certificate.  A note to implementator, implementors, a target can also
   perform name matching of the supplied target name in REQ-TOKEN
   against the target's certificate, this would provide early error
   detection.  The target can use the provided name to locate the
   appropriate credentials.

   During the validation of a name (either when the target validates the
   name of the initiator or vice versa), a match occurs:

   -- if the target name is the same as the target's subject name in the
      target's certificate or the DN entry "directoryName" extension of the
      target's subject alternate name (SAN) in the target target's certificate.
      In this case, subject names are first represented in the RFC2253
      format.  A match is performed according to the rules listed in
      RFC2252 [RFC2252].

   -- if the target name is just a common name ("CN=service") ("CN=service/host") and
      the common name matches the CN portion of the target's subject
      name or the CN portion of a DN entry of the target's subject alternate
      name SAN in the
      target certificate.  For instance, if target name is
      "CN=nfs" "CN=nfs/
      citi.umich.edu" and target's subject name is "C=US, ST=Michigan,
      L=Ann Arbor, O=University of Michigan, OU=CITI Production KCA, CN=nfs"
      CN=nfs/citi.umich.edu"

   -- if the target name is contains just a service common name ("CN=service/host")
      and the "host" matches the CN portion of the target's subject name
      in the target's certificate or a DNS "dsnName" entry of the target's subject
      alternate name
      SAN in the target target's certificate.  For instance, if target name is
      "CN=nfs/citi.umich.edu" and target's subject name is  "C=US,
      ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=CITI
      Production KCA, CN=citi.umich.edu" or if the certificate has
      "dNSName" SAN extension with a value of "citi.umich.edu".

   We RECOMMEND that target's certificate is restricted with an extended
   key usage (EKU).  For instance, an NFSv4 server should have a
   certificate with an EKU of id-spkm3-nfsv4 (FIXME: need an OID for
   it!).

2.5.1.3  Anonymous Name Form

   This name form is used to represent an anonymous SPKM-3, GSS_display_name() returns initiator and should
   use the symbolic name of GSS_C_NT_ANONYMOUS and a printable string
   "<anonymous>".  Also,
   "CN=<anonymous>".



Adams, et al.           Expires February 19, 2007              [Page 35]

Internet-Draft                   SPKM-3                      August 2006


   For anonymous SPKM-3, in REQ-TOKEN, since the field is OPTIONAL, no
   src_name is filled in.  When the target process such token, it knows
   that initiator is anonymous.  If the initiator uses a digital
   signature algorithm for integrity of the REQ-TOKEN but does not
   include the source name, it is a protocol error.

2.6  Credential Management

   Since in SPKM-3

2.5.1.4  Exported Name Object Form

   This name type represents a self-describing object, whose framing
   structure is defined at the target always authenticates to mechanism-independent level by GSS-API
   Version 2.  When generated by the initiator, it
   must possess an X.509 certificate and a corresponding private key.
   Typically, SPKM3 mechanism, the certificate and private key are stored on mechanism OID
   within the local
   file system (or also possibly on a secure hardware such as a smart
   card).  The SPKM-3 implementation must have means exportable name shall be that of finding where the credentials are stored and SPKM3 mechanism.  The
   mechanism-specific name component within the exportable name should
   be able to retrieve them.  If created by taking the



Adams, et al.            Expires October 1, 2006               [Page 32]

Internet-Draft                   SPKM-3                       March 2006


   initiator engages in mutual authentication following steps:

   First, start with the target, GSS_SPKM3_NT_PRINCIPAL_NAME name form.  This
   name type corresponds to the
   initiator must have string representation of an X.509 certificate as well.

   Both the target and the initiator have to have access to and ability
   to retrieve certificates X500
   Distinguished Name.  It is an RFC2253 [RFC2253] compliant string
   representation of the trusted Certification Authorities.

2.7  Parameter Definitions

   This section defines parameter values used by distinguished name with the SPKM-3 GSS-API
   mechanism.  It defines interface elements following
   additional canonicalizations:

   -- Leading zeros are removed from attribute types that are encoded as
      dotted decimal OIDs.

   -- DirectoryString attribute values of type PrintableString and
      UTF8String are not in hexadecimal format

   -- DirectoryString attribute values of types other than
      PrintableString and UTF8String are output in hexadecimal format

   -- Leading and trailing white space characters are removed from non-
      hexadecimal attribute values (unless the value consists entirely
      of white space characters)

   -- Internal substrings of one or more white space characters are
      converted to a single space in non-hexadecimal attribute values

   -- Relative Distinguished Names containing more than one Attribute
      Value Assertion (AVA) are output in the following order: an
      alphabetical ordering of AVAs containing standard keywords,
      followed by a numeric ordering of AVAs containing OID keywords.

   -- The only characters in attribute values that are escaped are those
      which section 2.4 of RFC2253 states must be escaped (they are
      escaped using a preceding backslash character)

   Then, take the resulting string and create an ASN1 Name.  Then DER
   encode the ASN1 name structure.



Adams, et al.           Expires February 19, 2007              [Page 36]

Internet-Draft                   SPKM-3                      August 2006


2.6  Credential Management

   Since in SPKM-3 the target always authenticates to the initiator, it
   must possess an X.509 certificate and a corresponding private key.
   Typically, the certificate and private key are stored on the local
   file system (or also possibly on a secure hardware such as a smart
   card).  The SPKM-3 implementation must have means of finding where
   the credentials are stored and be able to retrieve them.  If the
   initiator engages in mutual authentication with the target, the
   initiator must have an X.509 certificate as well.

   Both the target and the initiator have to have access to and ability
   to retrieve certificates of the trusted Certification Authorities.

2.7  Parameter Definitions

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

2.7.1  Minor Status Codes

   This section recommends common symbolic names for minor_status values
   to be returned by the SPKM-3 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 must 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.

2.7.2  Non-SPKM-3-specific codes

   Minor Status Code MSB, bit 31, SET.

2.7.2.1  GSS-Related codes

   Minor Status Code bit 30 SET.

      GSS_S_G_VALIDATE_FAILED
          /* "Validation









Adams, et al.           Expires February 19, 2007              [Page 37]

Internet-Draft                   SPKM-3                      August 2006


      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" */




Adams, et al.            Expires October 1, 2006               [Page 33]

Internet-Draft                   SPKM-3                       March 2006


2.7.2.2  Implementation-Related codes

   Minor Status Code bit 30 OFF.

      GSS_S_G_MEMORY_ALLOC
          /* "Couldn't perform requested memory allocation" */


2.7.3  SPKM-3-specific-codes

   Minor Status Code MSB, bit 31, OFF.

      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_CONF_ALG_TYPE
          /* "Unknown confidentiality 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_CONF_ALG_SET
          /* "No confidentiality 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_BAD_OWF_ALG_SET
          /* "No owf algorithm in common from offered set" */
      GSS_SPKM_S_SG_NO_PVNO_IN_COMMON
          /* "No protocol version number in common from offered set" */



Adams, et al.           Expires February 19, 2007              [Page 38]

Internet-Draft                   SPKM-3                      August 2006


      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" */
      GSS_SPKM_S_SG_CONTEXT_DELETED
          /* "Context deleted at peer's request" */
      GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD
          /* "Invalid delete token received -- context not deleted" */
      GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT
          /* "Unrecoverable context establishment error. Context
             deleted" */
      GSS_SPKM_S_SG_ASN1_ERROR
          /* "Problem with ASN1 encoding/decoding */



Adams, et al.            Expires October 1, 2006               [Page 34]

Internet-Draft                   SPKM-3                       March 2006


      GSS_SPKM_S_SG_BAD_TOKEN

      GSS_SPKM_S_SG_X509_VERIFY_FAILED
          /* failed to verify a certificate */
      GSS_SPKM_S_SG_X509_CRL_FAILED
          /* failed to verify a certificate because it was revoked */
      GSS_SPKM_S_SG_X509_BAD_PRV_KEY
          /* failed to acquire credentials: unable to get
             the private key */
      GSS_SPKM_S_SG_BAD_SIG_ALG_TYPE
          /* Unknown integrity algorithm in context establishment
             token */
      GSS_SPKM_S_SG_SIG_FAILED
          /* failed to verify the integrity of the token */
      GSS_SPKM_S_SG_BAD_CRED_USAGE
          /* requested credential for neither initiator or target */
      GSS_SPKM_S_SG_BAD_CRED_FILENAME
          /* provided invalid (filename) location for the credentials */
      GSS_SPKM_S_SG_BAD_DIRECTION
          /* bad direction in the checksum */
      GSS_SPKM_S_SG_BAD_NAME
          /* provided name did not match the name in credentials */


2.8  Quality of Protection Values

   The Quality of Protection (QOP) parameter is used in the SPKM-3 GSS-
   API mechanism as input to GSS_GetMIC() and GSS_Wrap()) to select
   among alternate confidentiality and integrity- checking algorithms.
   Once these sets of algorithms have been agreed upon by the context
   initiator and target, the QOP parameter simply selects from these
   ordered sets.



Adams, et al.           Expires February 19, 2007              [Page 39]

Internet-Draft                   SPKM-3                      August 2006


   More specifically, the SPKM-REQ token sends an ordered sequence of
   Alg. IDs specifying integrity-checking algorithms supported by the
   initiator and an ordered sequence of Alg. IDs specifying
   confidentiality algorithms supported by the initiator.  The target
   returns the subset of the offered integrity-checking Alg. IDs which
   it supports and the subset of the offered confidentiality Alg. IDs
   which it supports in the SPKM-REP-TI token (in the same relative
   orders as those given by the initiator).  Thus, the initiator and
   target each know the algorithms which they themselves support and the
   algorithms which both sides support (the latter are defined to be
   those supported over the established context).  The QOP parameter has
   meaning and validity with reference to this knowledge.  For example,
   an application may request integrity algorithm number 3 as defined by
   the mechanism specification.  If this algorithm is supported over
   this context then it is used; otherwise, GSS_S_FAILURE and an



Adams, et al.            Expires October 1, 2006               [Page 35]

Internet-Draft                   SPKM-3                       March 2006
   appropriate minor status code are returned.

   The QOP parameter for SPKM-3 is defined to be a 32-bit unsigned
   integer (an OM_uint32) with the following bit-field assignments:

    Confidentiality                     Integrity
   31 (MSB)                        16 15                         (LSB) 0
   ----------------------------------|----------------------------------
   | TS (5) | U(3) | IA (4) | MA (4) | TS (5)  | U(3) | IA (4) | MA(4) |
   ----------------------------------|----------------------------------

   where

   -- TS is a 5-bit Type Specifier (a semantic qualifier whose value
      specifies the type of algorithm which may be used to protect the
      corresponding token -- see below for details);

   -- U is a 3-bit Unspecified field (available for future use/
      expansion);

   -- IA is a 4-bit field enumerating Implementation-specific
      Algorithms; and

   -- MA is a 4-bit field enumerating Mechanism-defined Algorithms.

   The interpretation of the QOP parameter is as follows (note that the
   same procedure is used for both the confidentiality and the integrity
   halves of the parameter).  The MA field is examined first.  If it is
   non-zero then the algorithm used to protect the token is the
   mechanism-specified algorithm corresponding to that integer value.

   If MA is zero then IA is examined.  If this field value is non-zero
   then the algorithm used to protect the token is the implementation-



Adams, et al.           Expires February 19, 2007              [Page 40]

Internet-Draft                   SPKM-3                      August 2006


   specified algorithm corresponding to that integer value (if this
   algorithm is available over the established context).  Note that use
   of this field may hinder portability since a particular value may
   specify one algorithm in one implementation of the mechanism and may
   not be supported or may specify a completely different algorithm in
   another implementation of the mechanism.

   Finally, if both MA and IA are zero then TS is examined.  A value of
   zero for TS specifies the default algorithm for the established
   context, which is defined to be the first algorithm on the
   initiator's list of offered algorithms (confidentiality or integrity,
   depending on which half of QOP is being examined) which is supported
   over the context.  A non-zero value for TS corresponds to a
   particular algorithm qualifier and selects the first algorithm
   supported over the context which satisfies that qualifier.



Adams, et al.            Expires October 1, 2006               [Page 36]

Internet-Draft                   SPKM-3                       March 2006

   The following TS values (i.e., algorithm qualifiers) are specified;
   other values may be added in the future.

      For the Confidentiality TS field:

         00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
         00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
         00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK

      For the Integrity TS field:

         00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT
         00010 (2) = SPKM_INT_ALG_REPUDIABLE

   Clearly, qualifiers such as strong, medium, and weak are debatable
   and likely to change with time, but for the purposes of this version
   of the specification we define these terms as follows.  A
   confidentiality algorithm is "weak" if the effective key length of
   the cipher is 40 bits or less; it is "medium-strength" if the
   effective key length is strictly between 40 and 80 bits; and it is
   "strong" if the effective key length is 80 bits or greater.  (Note
   that "effective key length" describes the computational effort
   required to break a cipher using the best-known cryptanalytic attack
   against that cipher.)

   A five-bit TS field allows up to 31 qualifiers for each of
   confidentiality and integrity (since "0" is reserved for "default").
   This document specifies three for confidentiality and two for
   integrity, leaving a lot of room for future specification.
   Suggestions of qualifiers such as "fast", "medium-speed", and "slow"
   have been made, but such terms are difficult to quantify (and in any
   case are platform- and processor-dependent), and so have been left



Adams, et al.           Expires February 19, 2007              [Page 41]

Internet-Draft                   SPKM-3                      August 2006


   out of this initial specification.  The intention is that the TS
   terms be quantitative, environment-independent qualifiers of
   algorithms, as much as this is possible.

   Use of the QOP structure as defined above is ultimately meant to be
   as follows.

   -- TS values are specified at the GSS-API level and are therefore
      portable across mechanisms.  Applications which know nothing about
      algorithms are still able to choose "quality" of protection for
      their message tokens.

   -- MA values are specified at the mechanism level and are therefore
      portable across implementations of a mechanism.





Adams, et al.            Expires October 1, 2006               [Page 37]

Internet-Draft                   SPKM-3                       March 2006

   -- IA values are specified at the implementation level (in user
      documentation, for example) and are therefore typically non-
      portable.  An application which is aware of its own mechanism
      implementation and the mechanism implementation of its peer,
      however, is free to use these values since they will be perfectly
      valid and meaningful over that context and between those peers.

   The receiver of a token must pass back to its calling application a
   QOP parameter with all relevant fields set.  For example, if cast5CBC
   has been specified by a mechanism as algorithm 8, then a receive of a
   cast5CBC-protected token must pass to its application (QOP
   Confidentiality TS=1, IA=0, MA=8).  In this way, the application is
   free to read whatever part of the QOP it understands (TS or IA/MA).

   To aid in implementation and interoperability, the following
   stipulation is made.  The set of integrity Alg. IDs sent by the
   initiator must contain at least one specifying an algorithm which
   computes a digital signature supporting non-repudiation, signature, and must contain at least one
   specifying any other (repudiable) integrity algorithm.  The subset of
   integrity Alg. IDs returned by the target must also contain at least
   one specifying an algorithm which computes a digital signature supporting non-repudiation, signature, and
   at least one specifying a repudiable integrity algorithm.

   The reason for this stipulation is to ensure that every SPKM-3
   implementation will provide an integrity service which supports non-
   repudiation and one which does not support non-repudiation.  An
   application with no knowledge of underlying algorithms can choose one
   or the other by passing (QOP Integrity TS=1, IA=MA=0) or (QOP
   Integrity TS=2, IA=MA=0).  Although an initiator who wishes to remain
   anonymous will never actually use the non-repudiable digital
   signature, this integrity service must be available over the context
   so that the target can use it if desired.




Adams, et al.           Expires February 19, 2007              [Page 42]

Internet-Draft                   SPKM-3                      August 2006


   Finally, in accordance with the MANDATORY and RECOMMENDED algorithms
   given in Section Section 2.3, the following QOP values are specified
   for SPKM-3.

   For the Confidentiality MA field:

      0001 (1) = DES-CBC
      0010 (2) = cast5CBC
      0011 (3) = aes256-CBC

   Where "0001" through "0011" are in base 2.  An SPKM-3 peer that
   negotiates a confidentiality MA algorithm value of "0010" MUST use a
   128 bit key, i.e. set the keyLength values in the cast5CBC Parameters
   to 128 bits.



Adams, et al.            Expires October 1, 2006               [Page 38]

Internet-Draft                   SPKM-3                       March 2006

   For the Integrity MA field:

      0001 (1) = md5WithRSAEncryption
      0010 (2) = DES-MAC
      0011 (3) = dsaWithSHA1
      0100 (4) = HMAC-MD5
      0101 (5) = sha1WithRSAEncryption
      0110 (6) = md5-DES-CBC
      0111 (7) = sum64-DES-CBC

   Where "0001" through "0111" are in base 2.

2.9  Support Functions

2.9.1  The token_type Output Parameter

   The following token types are defined:

      GSS_INIT_TOKEN   = 1
      GSS_ACCEPT_TOKEN = 2
      GSS_ERROR_TOKEN  = 3
      GSS_SIGN_TOKEN   = GSS_GETMIC_TOKEN = 4
      GSS_SEAL_TOKEN   = GSS_WRAP_TOKEN   = 5
      GSS_DELETE_TOKEN = 6

























Adams, et al.           Expires February 19, 2007              [Page 43]

Internet-Draft                   SPKM-3                      August 2006


3.  A Low Infrastructure Public Key Mechanism Using SPKM-3 (LIPKEY)

   LIPKEY will invoke SPKM-3 shall be able to perform produce SPKM tokens.  Since the mapping from
   mechanism that the token-id
   information which application uses is included in every token (through the tag values
   in SPKMInnerContextToken or through the tok-id field) to one LIPKEY, LIPKEY will wrap some
   of the
   above token types.  Applications should be able to decide, on the
   basis SPKM-3 tokens with LIPKEY prefixes.  The exact definition of token_type, which GSS function to call (for example, if
   the
   token tokens is a GSS_INIT_TOKEN then described later in this memorandum.

3.1  How LIPKEY Initiator Uses SPKM-3

3.1.1  GSS_Import_name

   The initiator uses GSS_Import_name to import the application will call
   GSS_Accept_sec_context(), and if target's name,
   typically, but not necessarily, using the token is a GSS_WRAP_TOKEN then GSS_C_NT_HOSTBASED_SERVICE
   name type.  Ultimately, the application output of GSS_Import_name will call GSS_Unwrap()).

2.9.2  The context_handle Output Parameter

   The apply to
   an SPKM-3 mechanism implementation type because a LIPKEY target is responsible for maintaining an SPKM-3 target.

3.1.2  GSS_Acquire_cred

   The initiator calls GSS_Acquire_cred.  The credentials that are
   acquired are LIPKEY credentials, a
   mapping between user name and password.  How the context-id value which is included in every token
   user name and password is acquired is dependent upon the operating
   environment.  A application that invokes GSS_Acquire_cred() while the
   application's user has a context_handle, thus associating an individual token with its
   proper context.  Clearly graphical user interface running might
   trigger the value appearance of context_handle may be locally
   determined and may, in fact, be associated with memory containing
   sensitive data on a pop up window that prompts for the local system, and so having
   information.  A application embedded into the context-id
   actually be set equal to operating system, such
   as an NFS [Sandberg] client implemented as a computed context_handle will not work in
   general.  Conversely, having native file system might
   broadcast a message to the context_handle actually be set equal user's terminals telling him to invoke a computed context-id
   command that prompts for the information.

   Because the credentials will not work in general either, because
   context_handle must be returned to the application by used until GSS_Init_sec_context
   is called, the first call LIPKEY implementation will need to GSS_Init_sec_context() or GSS_Accept_sec_context(), whereas
   uniqueness of safeguard the context-id (over all contexts at both ends)
   credentials.  If this is a problem, the implementation may



Adams, et al.            Expires October 1, 2006               [Page 39]

Internet-Draft                   SPKM-3                       March 2006


   require that both initiator and target be involved in instead
   defer actual acquisition of the
   computation.  Consequently, context_handle and context-id must be
   computed separately user name and the mechanism implementation must be able to
   map from one password until
   GSS_Init_sec_context is ready to send the other by user name and password to
   the completion of context establishment
   at target.  In that event, the latest.

   Computation output_cred_handle argument of context-id during context establishment is
   accomplished as follows.  Each SPKM-3 implementation is responsible
   for generating
   GSS_Acquire_cred would simply be a "fresh" random number; that is, one which (with high
   probability) has not been used previously.  Note reference that there are no
   cryptographic requirements on this random number (i.e., it need not
   be unpredictable, it simply needs mapped to be fresh).  The initiator passes
   its random number the
   principal corresponding to the target in desired_name argument.  A subsequent
   GSS_Init_sec_context call would consider the context-id field mapping of
   claimant_cred_handle to principal when it acquires the SPKM-
   REQ token.  If no further context establishment tokens are expected
   (as for unilateral authentication user name and
   password.  For example, the aforementioned pop up window might fill
   in SPKM-3), then this the user name portion of the dialog with a default value is
   taken that maps
   to be the context-id (if this is unacceptable principal referred to in claimant_cred_handle.

3.1.3  GSS_Init_sec_context

   When a program invokes GSS_Init_sec_context on the target
   then an error token must be generated).  Otherwise, LIPKEY mechanism
   type, if the target
   generates its random number and concatenates it to context handle is NULL, the end of LIPKEY mechanism will in
   turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented



Adams, et al.           Expires February 19, 2007              [Page 44]

Internet-Draft                   SPKM-3                      August 2006


   according to the
   initiator's random number. requirements described previously.  This concatenated value is then taken call to
   be
   SPKM-3 MUST have the context-id and following attributes:

      claimant_cred_handle is NULL

      mutual_req_flag is FALSE

      anon_req_flag is TRUE

      input_token is NULL

      mech_type is used in SPKM-REP-TI and in all subsequent
   tokens over that context.

   Having both peers contribute to the context-id assures each peer OID of
   freshness and therefore precludes replay attacks between contexts
   (where a token from an old context between two peers is maliciously
   injected into a new context between the same or different peers).
   Such assurance is not available to SPKM-3 mechanism

   Keep in mind the target above attributes are in the case of
   unilateral authentication using SPKM-3, simply because it has not
   contributed to GSS_Init_sec_context
   call from the freshness of LIPKEY mechanism down to the computed context-id (instead, it
   must trust SPKM-3 mechanism.  There
   are no special restrictions placed on the freshness of application invoking
   LIPKEY's GSS_Init_sec_context routine.  All other arguments are
   derived from the initiator's random number, or reject LIPKEY GSS_Init_sec_context arguments.

   The call to the context).




















Adams, et al.            Expires October 1, 2006               [Page 40]

Internet-Draft SPKM-3                       March 2006


3.  A Low Infrastructure Public Key Mechanism Using SPKM-3 (LIPKEY)

   LIPKEY GSS_Init_sec_context will invoke create an SPKM-3 to produce SPKM tokens.  Since
   context handle.  The remainder of the
   mechanism that description of the application uses is LIPKEY, LIPKEY will wrap some
   GSS_Init_sec_context call depends on whether the caller of the SPKM-3 tokens with LIPKEY prefixes.  The exact definition
   GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE.

3.1.3.1  LIPKEY Caller Specified anon_req_flag as TRUE

   If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to
   TRUE, it MUST return to the tokens is described later in this memorandum.

3.1  How LIPKEY Initiator Uses SPKM-3

3.1.1  GSS_Import_name

   The initiator uses GSS_Import_name to import caller all the target's name,
   typically, but not necessarily, using outputs from the GSS_C_NT_HOSTBASED_SERVICE
   name type.  Ultimately,
   SPKM-3 GSS_Init_sec_context call, including the output
   output_context_handle, output_token, and mech_type.  In this way,
   LIPKEY now "gets out of GSS_Import_name will apply the way" of GSS-API processing between the
   application and SPKM-3, because nothing in the returned outputs
   relates to
   an SPKM-3 mechanism type LIPKEY.  This is necessary, because a LIPKEY target context tokens
   do not have provision for specifying anonymous initiators.  This is an
   because SPKM-3 target.

3.1.2  GSS_Acquire_cred

   The initiator calls GSS_Acquire_cred.  The credentials that are
   acquired are is sufficient for purpose of supporting anonymous
   initiators in a low infrastructure environment.

   If all goes well, the caller of LIPKEY credentials, will be returned a user name
   major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and password.  How so the
   user name and password is acquired is dependent upon caller
   of LIPKEY will send the operating
   environment.  A application that output_token to the target.  The caller of
   LIPKEY then receives the response token from the target, and directly
   invokes GSS_Acquire_cred() while the
   application's user has a graphical user interface running might
   trigger SPKM-3 GSS_Init_sec_context.  Upon return, the appearance of
   major_status should be GSS_S_COMPLETE.

3.1.3.2  LIPKEY Caller Specified anon_req_flag as FALSE

   The LIPKEY mechanism will need to allocate a pop up window that prompts context handle for
   itself, and record in the
   information.  A application embedded into LIPKEY context handle the operating system, such
   as an NFS [Sandberg] client implemented as a native file system might
   broadcast a message SPKM-3 context



Adams, et al.           Expires February 19, 2007              [Page 45]

Internet-Draft                   SPKM-3                      August 2006


   handle that was returned in the output_context_handle parameter from
   the call to the user's terminals telling him SPKM-3 GSS_Init_sec_context routine.  The LIPKEY
   GSS_Init_sec_context routine will return in output_context_handle the
   LIPKEY context handle, and in mech_type, the LIPKEY mechanism type.
   The output_token is as defined later in this memorandum, in the
   subsection entitled "Context Tokens Prior to invoke a
   command SPKM-3 Context
   Establishment."  All the other returned outputs will be those that prompts for
   the information.

   Because SPKM-3 GSS_Init_sec_context routine returned to LIPKEY.  If all
   went well, the credentials SPKM-3 mechanism will not be used until have returned a major_status of
   GSS_S_CONTINUE_NEEDED.

   The caller of the LIPKEY GSS_Init_sec_context
   is called, routine will see a
   major_status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY implementation
   will need to safeguard send the
   credentials.  If this is a problem, output_token to the implementation may instead
   defer actual acquisition target.  The caller of LIPKEY then
   receives the user name target's response token, and password until invokes the LIPKEY
   GSS_Init_sec_context routine for a second time.  LIPKEY then invokes
   the SPKM-3 GSS_Init_sec_context for a second time and upon return,
   the major_status should be GSS_S_COMPLETE.

   While SPKM-3's context establishment is ready to now complete, LIPKEY's
   context establishment is not yet complete, because the initiator must
   send to the target the user name and password that were passed to it
   via the target.  In that event, claimant_cred_handle on the output_cred_handle argument of
   GSS_Acquire_cred would simply be a reference that mapped first call to the
   principal corresponding to the desired_name argument.  A subsequent LIPKEY
   GSS_Init_sec_context call would consider routine.  LIPKEY uses the mapping of
   claimant_cred_handle established SPKM-3
   context handle as the input to principal when it acquires GSS_Wrap (with conf_req_flag set to
   TRUE) to encrypt what the user claimant_cred_handle refers to (user name
   and
   password.  For example, password), and returns that as the aforementioned pop up window might fill
   in output_token to the user name portion caller of
   LIPKEY (provided the dialog conf_state output from the call to SPKM-3's
   GSS_Wrap is TRUE), along with a default value that maps major_status of
   GSS_S_CONTINUE_NEEDED.

   The caller of LIPKEY sends its second context establishment token to
   the principal referred to in claimant_cred_handle.

3.1.3  GSS_Init_sec_context

   When target, and waits for a program token provided by the target's
   GSS_Accept_sec_context routine.  The target's LIPKEY
   GSS_Accept_sec_context routine invokes GSS_Init_sec_context the SPKM-3 GSS_Unwrap routine
   on the token, and validates the user name and password.  The target
   then invokes SPKM-3's GSS_Wrap routine on a boolean indicating
   whether or not the user name and password were accepted, and returns
   the output_message result from GSS_Wrap as the output_token result
   for GSS_Accept_sec_context.

   The caller of LIPKEY mechanism
   type, if receives the context handle is NULL, target's response token, and passes
   this via the input_token parameter to the LIPKEY mechanism will in
   turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented
   routine.  LIPKEY then invokes GSS_Unwrap to get the boolean
   acceptance indication, and maps this to a major_status of either
   GSS_S_COMPLETE indicating successful (the boolean was TRUE) and
   completed LIPKEY context establishment, or GSS_S_FAILURE, indicating
   that context establishment failed.  GSS_S_CONTINUE_NEEDED will not be



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 41] 46]

Internet-Draft                   SPKM-3                       March                      August 2006


   according to


   returned.

   Note that the requirements described previously.  This call to
   SPKM-3 MUST have the following attributes:

      claimant_cred_handle is NULL mutual_req_flag parameter is FALSE

      anon_req_flag is TRUE

      input_token is NULL

      mech_type ignored because unilateral
   authentication is impossible.  The initiator must authenticate the OID of the
   target via SPKM-3 mechanism

   Keep in mind the above attributes are in order to create a secure channel to transmit the GSS_Init_sec_context
   call from
   user name and password.  The target must authenticate the LIPKEY mechanism down to initiator
   when it receives the user name and password.

   The SPKM-3 mechanism.  There
   are no special restrictions placed on the application invoking
   LIPKEY's GSS_Init_sec_context routine.  All other arguments are
   derived from context remains established while the LIPKEY GSS_Init_sec_context arguments.

   The call to context is
   established.  If the SPKM-3 GSS_Init_sec_context will create an SPKM-3 context handle.  The remainder of expires before the description of LIPKEY context
   is destroyed, the LIPKEY
   GSS_Init_sec_context call depends implementation should expire the LIPKEY
   context and return the appropriate error on whether the caller of next GSS-API
   operation.

3.1.4  Other operations

   For other operations, the LIPKEY
   GSS_Init_sec_context sets anon_req_flag context acts as a pass through to TRUE
   the SPKM-3 context.  Operations that affect or FALSE.

3.1.3.1  LIPKEY Caller Specified anon_req_flag inquire context state,
   such as TRUE

   If GSS_Delete_sec_context, GSS_Export_sec_context,
   GSS_Import_sec_context, and GSS_Inquire_context will require a pass
   through to the caller SPKM-3 context and a state modification of LIPKEY's GSS_Init_sec_context sets anon_req_flag to
   TRUE, it MUST return to the LIPKEY caller all the outputs from the
   context.

3.2  How LIPKEY Target Uses SPKM-3 GSS_Init_sec_context call, including

   As with the
   output_context_handle, output_token, and mech_type.  In this way,
   LIPKEY now "gets out of initiator, the way" imported name will be that of GSS-API processing between the
   application and SPKM-3, because nothing in target.

3.2.1  GSS_Acquire_cred

   The target calls the returned outputs
   relates LIPKEY GSS_Acquire_cred routine to LIPKEY.  This get a
   credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred
   routine.  The desired_name is necessary, because the output_name from GSS_Import_name.

3.2.2  GSS_Accept_sec_context

   When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism
   type, if the context tokens
   do not have provision for specifying anonymous initiators.  This handle is
   because NULL, the LIPKEY mechanism will in
   turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented
   according the requirements described previously.  This call to SPKM-3
   is sufficient no different than what one would expect for purpose of supporting anonymous
   initiators in a low infrastructure environment. layered call to
   GSS_Accept_sec_context.

   If all goes well, the caller of LIPKEY will be returned a
   major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, SPKM-3 GSS_Accept_sec_context call succeeds
   with GSS_S_COMPLETE, and so the caller
   of LIPKEY will send GSS_Accept_sec_context call
   returns the output_token to the target.  The caller caller, but with a major_status of
   LIPKEY then receives the response token from the target, and directly
   invokes the SPKM-3 GSS_Init_sec_context.  Upon return,
   GSS_S_CONTINUE_NEEDED because the
   major_status should be GSS_S_COMPLETE.

3.1.3.2  LIPKEY Caller Specified anon_req_flag as FALSE

   The LIPKEY mechanism will need initiator is still expected
   to allocate a context handle for
   itself, and record in the LIPKEY context handle send the SPKM-3 context user name and password.




Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 42] 47]

Internet-Draft                   SPKM-3                       March                      August 2006


   handle that was returned


   Once the SPKM-3 context is in a GSS_S_COMPLETE state, the output_context_handle parameter from next token
   the call to target receives will contain the user name and password, wrapped
   by the output of an SPKM-3 GSS_Init_sec_context routine. GSS_Wrap call.  The LIPKEY
   GSS_Init_sec_context routine will return in output_context_handle target invokes the
   LIPKEY context handle, and GSS_Accept_sec_context, which in mech_type, turn invokes the LIPKEY mechanism type. SPKM-3
   GSS_Unwrap routine.  The output_token is as defined later in this memorandum, in LIPKEY GSS_Accept_sec_context routine then
   compares the
   subsection entitled "Context Tokens Prior to SPKM-3 Context
   Establishment."  All user name and password with its user name name and
   password database.  If the other initiator's user name and password are
   valid, GSS_S_COMPLETE is returned outputs will be those that to the SPKM-3 GSS_Init_sec_context routine returned caller.  Otherwise
   GSS_S_FAILURE is returned.  In either case, an output_token - equal
   to LIPKEY.  If all
   went well, the output_message result from an SPKM-3 mechanism will have returned GSS_Wrap call on a major_status of
   GSS_S_CONTINUE_NEEDED.
   boolean value - is returned to the caller.  The caller of boolean value is set
   to TRUE if the the user name and password were valid, FALSE
   otherwise.  The target expects no more context establishment tokens
   from caller.

3.3  LIPKEY Description

3.3.1  Mechanism Type

   The LIPKEY GSS_Init_sec_context routine will see be identified by the following Object Identifier:

      lipkey OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) lipkey(9) }


3.3.2  Token Formats

   The GSS-API initialContexToken (Figure 18) defines a
   major_status per-mechanism
   innerContextToken.  The contents of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY
   will send innerContextToken
   depend on whether the output_token SPKM-3 context is established or not.

3.3.2.1  Context Tokens Prior to the target.  The caller of SPKM-3 Context Establishment

   In a LIPKEY then
   receives the target's response token, and invokes InitialContextToken, thisMech will be the LIPKEY
   GSS_Init_sec_context routine Object
   identifier for a second time. LIPKEY.  However, as long as LIPKEY then invokes has not
   established the SPKM-3 GSS_Init_sec_context mechanism, the innerContextToken for a second time both the
   InitialContextToken and upon return, the major_status should SubsequentContextToken will be GSS_S_COMPLETE.

   While SPKM-3's context establishment is now complete, LIPKEY's
   context establishment is not yet complete, because the initiator must
   send to output
   of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context.  So the target
   LIPKEY innerContextToken would be either:

   -- An InitialContextToken, with thisMech set to the user name and password that were passed object identifier
      for SPKM-3, with innerContextToken defined to it
   via be an
      SPKMInnerContextToken, as defined in Section Section 2.4.1.







Adams, et al.           Expires February 19, 2007              [Page 48]

Internet-Draft                   SPKM-3                      August 2006


   -- A SubsequentContextToken, with innerContextToken defined to be
      SPKMInnerContextToken


3.3.2.2  Post-SPKM-3 Context Establishment Tokens

   Once the claimant_cred_handle on SPKM-3 context is established, there is just one token sent
   from the first call initiator to the target, and one token returned to
   initiator.

3.3.2.2.1  From LIPKEY
   GSS_Init_sec_context routine. Initiator

   The LIPKEY uses initiator generates a token that is the established SPKM-3
   context handle as the input to result of a
   GSS_Wrap (with conf_req_flag (conf_req is set to TRUE) to encrypt what the claimant_cred_handle refers to (user of a user name and password), and returns that as password by the output_token
   SPKM-3 context.  The input_message argument of GSS_Wrap refers to the caller an
   instance of
   LIPKEY (provided the conf_state output from the call to SPKM-3's
   GSS_Wrap UserName-Password type defined below:

      UserName-Password ::= SEQUENCE {
         user-name       OCTET STRING,
            -- each octet is TRUE), along with a major_status an octet of
   GSS_S_CONTINUE_NEEDED.

   The caller a UTF-8 [RFC2279] string
         password        OCTET STRING
            -- each octet is an octet of a UTF-8 [RFC2279] string
      }


3.3.2.2.2  From LIPKEY sends its second context establishment Target

   The target validates the user name and password token to from the target,
   initiator, and waits for generates a response token provided by the target's
   GSS_Accept_sec_context routine.  The target's LIPKEY
   GSS_Accept_sec_context routine invokes that is the output_message
   result of an SPKM-3 GSS_Unwrap routine
   on the token, and validates the user name and password.  The target
   then invokes SPKM-3's GSS_Wrap routine on a boolean indicating
   whether (conf_req may or may not be set to TRUE)
   call on an indication of validation success.  The input_message
   argument of GSS_Wrap refers to an instance of the Valid-UNP type
   defined below:

      Valid-UNP ::= BOOLEAN
         -- If TRUE, user name and password were accepted, and returns
   the output_message result name/password pair was valid.


3.3.2.3  Tokens from GSS_GetMIC and GSS_Wrap as the output_token result
   for GSS_Accept_sec_context.

   The caller of

   LIPKEY receives the target's response token, and passes
   this via the input_token parameter does not add any value to GSS_GetMIC and GSS_Wrap other than
   passing the LIPKEY GSS_Init_sec_context
   routine.  LIPKEY then invokes GSS_Unwrap message to get the boolean
   acceptance indication, and maps this to a major_status of either
   GSS_S_COMPLETE indicating successful (the boolean was TRUE) SPKM-3 GSS_GetMIC and
   completed GSS_Wrap.

3.3.3  Name Types

   LIPKEY context establishment, or GSS_S_FAILURE, indicating
   that context establishment failed.  GSS_S_CONTINUE_NEEDED will not be uses only the mechanism independent name types defined in
   [RFC2078].  All the name types defined in [RFC2078] are REQUIRED.




Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 43] 49]

Internet-Draft                   SPKM-3                       March                      August 2006


   returned.

   Note that the mutual_req_flag parameter is ignored because unilateral
   authentication is impossible.  The initiator must authenticate the
   target via SPKM-3 in order to create


3.3.4  Quality of Protection

   LIPKEY, being a secure channel to transmit the
   user name pass through for GSS_Wrap and password.  The target must authenticate GSS_GetMIC to SPKM-3,
   does not interpret or alter the initiator
   when it receives QOPs passed to the user name aforementioned
   routines or received from their complements, GSS_Unwrap, and password.

   The SPKM-3 context remains established while the
   GSS_VerifyMIC.  Thus, LIPKEY context is
   established.  If supports the same set of QOPs as SPKM-3,
   see Section Section 2.8.












































Adams, et al.           Expires February 19, 2007              [Page 50]

Internet-Draft                   SPKM-3 context expires before the                      August 2006


4.  Security Considerations

   Security issues are discussed throughout this memo.

4.1  Password Management

   LIPKEY context
   is destroyed, sends the LIPKEY implementation should expire clear text password encrypted by 128 bit cast5CBC so
   the LIPKEY
   context and return risk in this approach is in how the appropriate error on target manages the next GSS-API
   operation.

3.1.4  Other operations

   For other operations, password
   after it is done with it.  The approach should be safe, provided the LIPKEY context acts as a pass through to
   target clears the SPKM-3 context.  Operations that affect or inquire context state, memory (primary and secondary, such as GSS_Delete_sec_context, GSS_Export_sec_context,
   GSS_Import_sec_context, and GSS_Inquire_context will require a pass
   through to disk)
   buffers that contained the SPKM-3 context password, and a state modification any hash of the LIPKEY
   context.

3.2  How LIPKEY Target Uses SPKM-3

   As with the initiator, password
   immediately after it has validated the imported name will be that user's password.

4.2  Certification Authorities

   The initiator must have a list of trusted Certification Authorities
   in order to verify the target.

3.2.1  GSS_Acquire_cred

   The target calls checksum (rep-ti-integ) on the LIPKEY GSS_Acquire_cred routine to get SPKM-3 target's
   context reply token.  If it encounters a
   credential for certificate signed by an SPKM-3 target, via
   unknown and/or untrusted certificate authority, the SPKM-3 GSS_Acquire_cred
   routine.  The desired_name is initiator MUST
   NOT silently accept the output_name certificate.  If it does wish to accept the
   certificate, it MUST get confirmation from GSS_Import_name.

3.2.2  GSS_Accept_sec_context

   When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism
   type, if the context handle is NULL, the LIPKEY mechanism will in
   turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented
   according user running the requirements described previously.  This call to SPKM-3
   application that is no different than what one would expect for a layered call to
   GSS_Accept_sec_context.

   If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds
   with GSS_S_COMPLETE, using GSS-API.

4.3  HMAC-MD5 and MD5 Weaknesses

   While the LIPKEY GSS_Accept_sec_context call
   returns the output_token MD5 hash algorithm has been found to have weaknesses
   [Dobbertin], the caller, but with a major_status of
   GSS_S_CONTINUE_NEEDED because weaknesses do not impact the LIPKEY initiator security of HMAC-MD5
   [Dobbertin].

4.4  Security of cast5CBC

   The cast5CBC encryption algorithm is still expected relatively new compared to send the user name and password.




Adams, et al.            Expires October 1, 2006               [Page 44]

Internet-Draft                   SPKM-3                       March 2006


   Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token
   the target receives will contain the user name
   established algorithms like triple DES, and password, wrapped
   by RC4.  Nonetheless, the output
   choice of cast5CBC as an OPTIONAL C-ALG for SPKM-3 GSS_Wrap call. is advisable.  The target invokes the
   LIPKEY GSS_Accept_sec_context, which in turn invokes
   cast5CBC algorithm is a 128 bit algorithm that the SPKM-3
   GSS_Unwrap routine. 256 bit cast6CBC
   [RFC2612] algorithm is based upon.  The LIPKEY GSS_Accept_sec_context routine then
   compares the user name and password with its user name name and
   password database.  If cast6CBC algorithm was judged
   by the initiator's user name U.S. National Institute of Standards and password are
   valid, GSS_S_COMPLETE is returned Technology (NIST) to the caller.  Otherwise
   GSS_S_FAILURE is returned.  In either case, an output_token - equal
   have no known major or minor "security gaps," and to the output_message result from an SPKM-3 GSS_Wrap call on a
   boolean value - is returned to the caller.  The boolean value is set
   to TRUE if the the user name and password were valid, FALSE
   otherwise.  The target expects no more context establishment tokens
   from caller.

3.3  LIPKEY Description

3.3.1  Mechanism Type

   The LIPKEY will be identified by the following Object Identifier:

      lipkey OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) lipkey(9) }


3.3.2  Token Formats

   The GSS-API initialContexToken (Figure 18) defines a per-mechanism
   innerContextToken.  The contents of the LIPKEY innerContextToken
   depend on whether the SPKM-3 context is established or not.

3.3.2.1  Context Tokens Prior to SPKM-3 Context Establishment

   In have a LIPKEY InitialContextToken, thisMech will be the Object
   identifier for LIPKEY.  However, as long as LIPKEY has not
   established the SPKM-3 mechanism, the innerContextToken for both the
   InitialContextToken and the SubsequentContextToken will be the output
   of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context.  So the
   LIPKEY innerContextToken would be either:

   -- An InitialContextToken, with thisMech set to the object identifier
      for SPKM-3, with innerContextToken defined to be an
      SPKMInnerContextToken, as defined in Section Section 2.4.1.







Adams, et al.            Expires October 1, 2006               [Page 45]

Internet-Draft                   SPKM-3                       March 2006


   -- A SubsequentContextToken, with innerContextToken defined to be
      SPKMInnerContextToken


3.3.2.2  Post-SPKM-3 Context Establishment Tokens

   Once the SPKM-3 context is established, there is just one token sent
   from the initiator to the target, and one token returned "high
   security margin" [AES].  NIST did note some vulnerabilities related
   to
   initiator.

3.3.2.2.1  From LIPKEY Initiator

   The LIPKEY initiator generates a token that is the the result of a
   GSS_Wrap (conf_req is set to TRUE) of a user name and password by the
   SPKM-3 context.  The input_message argument of GSS_Wrap refers to an
   instance of the UserName-Password type defined below:

      UserName-Password ::= SEQUENCE {
         user-name       OCTET STRING,
            -- each octet is an octet of a UTF-8 [RFC2279] string
         password        OCTET STRING
            -- each octet is an octet of a UTF-8 [RFC2279] string
      }


3.3.2.2.2  From LIPKEY Target

   The target validates the user name and password token from the
   initiator, and generates a response token that is the output_message
   result of an SPKM-3 GSS_Wrap (conf_req may or may not be set to TRUE)
   call on an indication of validation success.  The input_message
   argument of GSS_Wrap refers to an instance of the Valid-UNP type
   defined below:

      Valid-UNP ::= BOOLEAN
         -- If TRUE, user name/password pair was valid.


3.3.2.3  Tokens from GSS_GetMIC and GSS_Wrap

   LIPKEY does not add any value to GSS_GetMIC and GSS_Wrap other than
   passing the message to the SPKM-3 GSS_GetMIC and GSS_Wrap.

3.3.3  Name Types

   LIPKEY uses only the mechanism independent name types defined in
   [RFC2078].  All the name types defined in [RFC2078] are REQUIRED.




Adams, et al.            Expires October 1, 2006               [Page 46]

Internet-Draft                   SPKM-3                       March 2006


3.3.4  Quality of Protection

   LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3,
   does not interpret or alter the QOPs passed to the aforementioned
   routines or received from their complements, GSS_Unwrap, and
   GSS_VerifyMIC.  Thus, LIPKEY supports the same set of QOPs as SPKM-3,
   see Section Section 2.8.












































Adams, et al.            Expires October 1, 2006               [Page 47]

Internet-Draft                   SPKM-3                       March 2006


4.  Issues

   -- Algorithms questions:



      1.  should HMAC-SHA1 be added as an I-ALG? kerberos proposed to
          use sha1 with aes not md5

      2.  should SPKM have a mandatory confidentiality algorithm? is
          exportability still a problem

      3.  what exactly does it mean: "md5WithRSAEncrytion is essentially
          equivalent to md5WithRSA"?

   -- Token Questions:



      1.  if the initiator receives a REP-TI-TOKEN and the targ_name
          there doesn't match the targ_name in REQ-TOKEN, however, the
          targ_name in REQ-TOKEN matches the target's certificate. is
          this an invalid token?

      2.  should the target verify the targ_name in REQ-TOKEN to its
          certificate as stated in section 2.5?

      3.  if the target receives a REQ-TOKEN such that integrity
          alg=md5WithRSA but the mutual_state within Options within
          ContextData is not set (or set to anonymous). is this an
          invalid token?

      4.  in the spec, we state target-certif-data-required must be set
          to 1. what if it is not? is in an invalid token? or should the
          target still just send the REP-TI back.

   -- Error handling Questions:



      1.  what should happen if an initiator or the target fails to
          process an error token? the spec does say that an invalid
          error token should still require a new SPKM-REQ token to be
          generated and sent.

      2.  after generating an error token, should the target return
          CONTINUE_NEEDED or error codes from accept_sec_context()?




Adams, et al.            Expires October 1, 2006               [Page 48]

Internet-Draft                   SPKM-3                       March 2006


   -- Name Questions:



      1.  we have recommended that the OPTIONAL src_name in REQ_TOKEN
          not be filled in even for mutual authentication - use the
          required user certificate subject name instead. is this a good
          idea?

      2.  we have begun to map SPKM-3 use of RDN's to GSS name types.
          please review.

      3.  should SPKM-3 anonymous user "<anonymous>" string be changed
          to a DN version such as "CN=anonymous" for GSS_display_name?

      4.  should SPKM-3 differentiate between GSS_C_NO_NAME and
          GSS_C_ANONYMOUS_NAME?

      5.  what information should the SPKM-3 GSS_export_name contain?
          the ASN.1 encoded certificate subject name?

   -- Other Questions:



      1.  should SPKM support SSH keys? what does it mean to support SSH
          keys?

      2.  how PKIX1Implicit88 is different from PKIX1Explicit88?

      3.  while deriving subkeys, why is the context_key is concatenated
          twice (1st and last)?

      4.  how should the lifetime of the returned credentials be handled
          in SPKM-3? in GSS_Acquire_cred(), a caller can request
          credentials for a certain lifetime or 0 for defaut lifetime.
          the lifetime of the PKI creds is long, so should the lifetime
          of the cred be the same as the lifetime of the cert?













Adams, et al.            Expires October 1, 2006               [Page 49]

Internet-Draft                   SPKM-3                       March 2006


5.  Security Considerations

   Security issues are discussed throughout this memo.

5.1  Password Management

   LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so
   the risk in this approach is in how the target manages the password
   after it is done with it.  The approach should be safe, provided the
   target clears the memory (primary and secondary, such as disk)
   buffers that contained the password, and any hash of the password
   immediately after it has validated the user's password.

5.2  Certification Authorities

   The initiator must have a list of trusted Certification Authorities
   in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's
   context reply token.  If it encounters a certificate signed by an
   unknown and/or untrusted certificate authority, the initiator MUST
   NOT silently accept the certificate.  If it does wish to accept the
   certificate, it MUST get confirmation from the user running the
   application that is using GSS-API.

5.3  HMAC-MD5 and MD5 Weaknesses

   While the MD5 hash algorithm has been found to have weaknesses
   [Dobbertin], the weaknesses do not impact the security of HMAC-MD5
   [Dobbertin].

5.4  Security of cast5CBC

   The cast5CBC encryption algorithm is relatively new compared to
   established algorithms like triple DES, and RC4.  Nonetheless, the
   choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable.
   The cast5CBC algorithm is a 128 bit algorithm that the 256 bit
   cast6CBC [RFC2612] algorithm is based upon.  The cast6CBC algorithm
   was judged by the U.S. National Institute of Standards and Technology
   (NIST) to have no known major or minor "security gaps," and to have a
   "high security margin" [AES].  NIST did note some vulnerabilities
   related to smart card implementations, but many other algorithms NIST
   analyzed shared the vulnerabilities, and in any case, LIPKEY is by
   definition not aimed at smart cards.









Adams, et al.            Expires October 1, 2006               [Page 50]

Internet-Draft                   SPKM-3                       March 2006


Appendix A.  Appendix A: ANS.1 Module Definition

   The ASN.1 types in Appendix B of [RFC2025] imported from
   InformationFramework (1993) and AuthenticationFramework (1993), and
   [PKCS3] are outdated.  Both the InformationFrameWork and the
   AuthenticationFramework have moved forward to new versions.
   Implementations of this specification MUST be capable of processing
   the Version 3 X.509 certificates and extensions described in the
   [RFC3280] appendix A.1 "Explicitly Tagged Module, 1988 Syntax" with
   the following OID.


   PKIX1Explicit88 {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-pkix1-explicit(18)
   }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL

   -- IMPORTS NONE --

   -- UNIVERSAL Types defined in 1993 and 1998 ASN.1
   -- and required by this specification

   --UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
           -- UniversalString is defined in ASN.1:1993

   -- BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
         -- BMPString is the subtype of UniversalString and models
         -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1

   -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
   -- The content of this type conforms to [RFC 2279].

   -- PKIX specific OIDs

   id-pkix  OBJECT IDENTIFIER  ::=
            { iso(1) identified-organization(3) dod(6) internet(1)
                       security(5) mechanisms(5) pkix(7) }

   -- PKIX arcs

   id-pe OBJECT IDENTIFIER  ::=  { id-pkix 1 }



Adams, et al.            Expires October 1, 2006               [Page 51]

Internet-Draft                   SPKM-3                       March 2006


           -- arc for private certificate extensions
   id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
           -- arc for policy qualifier types
   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
           -- arc for extended key purpose OIDS
   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
           -- arc for access descriptors

   -- policyQualifierIds for Internet policy qualifiers

   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
         -- OID for CPS qualifier
   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
         -- OID for user notice qualifier

   -- access descriptor definitions

   id-ad-ocsp         OBJECT IDENTIFIER ::= { id-ad 1 }
   id-ad-caIssuers    OBJECT IDENTIFIER ::= { id-ad 2 }
   id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
   id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

   -- attribute data types

   Attribute       ::=     SEQUENCE {
         type              AttributeType,
         values    SET OF AttributeValue }
               -- at least one value is required

   AttributeType           ::=  OBJECT IDENTIFIER

   AttributeValue          ::=  ANY

   AttributeTypeAndValue           ::=     SEQUENCE {
           type    AttributeType,
           value   AttributeValue }

   -- suggested naming attributes: Definition of the following
   --   information object set may be augmented to meet local
   --   requirements.  Note that deleting members of the set may
   --   prevent interoperability with conforming implementations.
   -- presented in pairs: the AttributeType followed by the
   --   type definition for the corresponding AttributeValue
   --Arc for standard naming attributes
   id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }

   -- Naming attributes of type X520name




Adams, et al.            Expires October 1, 2006               [Page 52]

Internet-Draft                   SPKM-3                       March 2006


   id-at-name              AttributeType ::= { id-at 41 }
   id-at-surname           AttributeType ::= { id-at 4 }
   id-at-givenName         AttributeType ::= { id-at 42 }
   id-at-initials          AttributeType ::= { id-at 43 }
   id-at-generationQualifier AttributeType ::= { id-at 44 }

   X520name ::= CHOICE {
         teletexString     TeletexString   (SIZE (1..ub-name)),
         printableString   PrintableString (SIZE (1..ub-name)),
         universalString   UniversalString (SIZE (1..ub-name)),
         utf8String        UTF8String      (SIZE (1..ub-name)),
         bmpString         BMPString       (SIZE (1..ub-name))
   }

   -- Naming attributes of type X520CommonName

   id-at-commonName        AttributeType ::= { id-at 3 }

   X520CommonName ::= CHOICE {
         teletexString     TeletexString   (SIZE (1..ub-common-name)),
         printableString   PrintableString (SIZE (1..ub-common-name)),
         universalString   UniversalString (SIZE (1..ub-common-name)),
         utf8String        UTF8String      (SIZE (1..ub-common-name)),
         bmpString         BMPString       (SIZE (1..ub-common-name))
   }

   -- Naming attributes of type X520LocalityName

   id-at-localityName      AttributeType ::= { id-at 7 }

   X520LocalityName ::= CHOICE {
         teletexString     TeletexString   (SIZE (1..ub-locality-name)),
         printableString   PrintableString (SIZE (1..ub-locality-name)),
         universalString   UniversalString (SIZE (1..ub-locality-name)),
         utf8String        UTF8String      (SIZE (1..ub-locality-name)),
         bmpString         BMPString       (SIZE (1..ub-locality-name))
   }

   -- Naming attributes of type X520StateOrProvinceName

   id-at-stateOrProvinceName AttributeType ::= { id-at 8 }

   X520StateOrProvinceName ::= CHOICE {
         teletexString     TeletexString   (SIZE (1..ub-state-name)),
         printableString   PrintableString (SIZE (1..ub-state-name)),
         universalString   UniversalString (SIZE (1..ub-state-name)),
         utf8String        UTF8String      (SIZE (1..ub-state-name)),
         bmpString         BMPString       (SIZE(1..ub-state-name))



Adams, et al.            Expires October 1, 2006               [Page 53]

Internet-Draft                   SPKM-3                       March 2006


   }

   -- Naming attributes of type X520OrganizationName

   id-at-organizationName  AttributeType ::= { id-at 10 }

   X520OrganizationName ::= CHOICE {
         teletexString     TeletexString
                             (SIZE (1..ub-organization-name)),
         printableString   PrintableString
                             (SIZE (1..ub-organization-name)),
         universalString   UniversalString
                             (SIZE (1..ub-organization-name)),
         utf8String        UTF8String
                             (SIZE (1..ub-organization-name)),
         bmpString         BMPString
                             (SIZE (1..ub-organization-name))
   }

   -- Naming attributes of type X520OrganizationalUnitName

   id-at-organizationalUnitName AttributeType ::= { id-at 11 }

   X520OrganizationalUnitName ::= CHOICE {
         teletexString     TeletexString
                             (SIZE (1..ub-organizational-unit-name)),
         printableString   PrintableString
                             (SIZE (1..ub-organizational-unit-name)),
         universalString   UniversalString
                             (SIZE (1..ub-organizational-unit-name)),
         utf8String        UTF8String
                             (SIZE (1..ub-organizational-unit-name)),
         bmpString         BMPString
                             (SIZE (1..ub-organizational-unit-name))
   }

   -- Naming attributes of type X520Title

   id-at-title             AttributeType ::= { id-at 12 }

   X520Title ::= CHOICE {
         teletexString     TeletexString   (SIZE (1..ub-title)),
         printableString   PrintableString (SIZE (1..ub-title)),
         universalString   UniversalString (SIZE (1..ub-title)),
         utf8String        UTF8String      (SIZE (1..ub-title)),
         bmpString         BMPString       (SIZE (1..ub-title))
   }




Adams, et al.            Expires October 1, 2006               [Page 54]

Internet-Draft                   SPKM-3                       March 2006


   -- Naming attributes of type X520dnQualifier

   id-at-dnQualifier       AttributeType ::= { id-at 46 }

   X520dnQualifier ::=     PrintableString

   -- Naming attributes of type X520countryName (digraph from IS 3166)

   id-at-countryName       AttributeType ::= { id-at 6 }

   X520countryName ::=     PrintableString (SIZE (2))

   -- Naming attributes of type X520SerialNumber

   id-at-serialNumber      AttributeType ::= { id-at 5 }

   X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))

   -- Naming attributes of type X520Pseudonym

   id-at-pseudonym         AttributeType ::= { id-at 65 }

   X520Pseudonym ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
      printableString   PrintableString (SIZE (1..ub-pseudonym)),
      universalString   UniversalString (SIZE (1..ub-pseudonym)),
      utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
      bmpString         BMPString       (SIZE (1..ub-pseudonym))
   }

   -- Naming attributes of type DomainComponent (from [RFC 2247])

   id-domainComponent      AttributeType ::=
                             { 0 9 2342 19200300 100 1 25 }

   DomainComponent ::=     IA5String

   -- Legacy attributes

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

   id-emailAddress          AttributeType ::= { pkcs-9 1 }

   EmailAddress ::=         IA5String (SIZE (1..ub-emailaddress-length))

   -- naming data types --




Adams, et al.            Expires October 1, 2006               [Page 55]

Internet-Draft                   SPKM-3                       March 2006


   Name ::= CHOICE { -- only one possibility for now --
         rdnSequence  RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   DistinguishedName ::=   RDNSequence

   RelativeDistinguishedName  ::=
                       SET SIZE (1 .. MAX) OF AttributeTypeAndValue

   -- Directory string type --

   DirectoryString ::= CHOICE {
         teletexString             TeletexString   (SIZE (1..MAX)),
         printableString           PrintableString (SIZE (1..MAX)),
         universalString           UniversalString (SIZE (1..MAX)),
         utf8String              UTF8String      (SIZE (1..MAX)),
         bmpString               BMPString       (SIZE (1..MAX))
   }

   -- certificate and CRL specific structures begin here

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signature            BIT STRING
   }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  Extensions OPTIONAL
                             -- If present, version MUST be v3 --
   }

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

   CertificateSerialNumber  ::=  INTEGER smart card implementations, but many other algorithms NIST
   analyzed shared the vulnerabilities, and in any case, LIPKEY is by
   definition not aimed at smart cards.









Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 56] 51]

Internet-Draft                   SPKM-3                       March                      August 2006


   Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time  }

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   UniqueIdentifier  ::=  BIT STRING

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

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }

   -- CRL structures

   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signature            BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                            -- if present, MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0] Extensions OPTIONAL }
                                            -- if present, MUST be v2

   -- Version, Time, CertificateSerialNumber, and Extensions were
   -- defined earlier


5.  Acknowledgments

   We are extremely grateful for use in contributions to the certificate structure

   AlgorithmIdentifier  ::=  SEQUENCE  { makings of this
   document by Nicollas Williams, Martix Rex, Kevin Coffman, and Sandeep
   Patel.














































Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 57] 52]

Internet-Draft                   SPKM-3                       March                      August 2006


        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                   -- contains a value


Appendix A.  Appendix A: SPKM-3 ANS.1 Module Definition

   Implementations of this specification MUST be capable of processing
   the type
                                   -- registered for use Version 3 X.509 certificates and extensions described in the
   [RFC3280] appendix A.1 "Explicitly Tagged Module, 1988 Syntax" with
   the following OID.


   -- algorithm object identifier value Module SpkmGssTokens (RFC 2025:10/1996)
   SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}
   -- X.400 address syntax starts here

   ORAddress ::= SEQUENCE {
      built-in-standard-attributes BuiltInStandardAttributes,
      built-in-domain-defined-attributes
                      BuiltInDomainDefinedAttributes OPTIONAL,
   -- Copyright (C) The Internet Society (1996). This version of
   -- this ASN.1 module is part of RFC 2025;
   -- see also teletex-domain-defined-attributes
      extension-attributes ExtensionAttributes OPTIONAL } the RFC itself for full legal notices.
   --
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORTS ALL
      IMPORTS
   --    Name
   --    FROM InformationFramework {joint-iso-itu-t(2) ds(5) module(1)
   --      informationFramework(1) 3}
   --  Certificate, CertificateList, CertificatePair,
   --  AlgorithmIdentifier, Validity
   --    FROM AuthenticationFramework {joint-iso-itu-t(2) ds(5)
   --      module(1) authenticationFramework(7) 3};

       Name, Certificate, CertificateList, AlgorithmIdentifier, Validity
         FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-explicit(18) };

   -- Built-in Standard Attributes

   BuiltInStandardAttributes types

   CertificatePair ::= SEQUENCE {
      country-name                  CountryName OPTIONAL,
      administration-domain-name    AdministrationDomainName OPTIONAL,
      network-address
     issuedByThisCA  [0] IMPLICIT NetworkAddress  Certificate OPTIONAL,
        -- see also extended-network-address
      terminal-identifier
     issuedToThisCA  [1] IMPLICIT TerminalIdentifier
                                      OPTIONAL,
      private-domain-name       [2] PrivateDomainName OPTIONAL,
      organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
        -- see also teletex-organization-name
      numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
                                    OPTIONAL,
      personal-name             [5] IMPLICIT PersonalName OPTIONAL,
        -- see also teletex-personal-name
      organizational-unit-names [6] IMPLICIT OrganizationalUnitNames  Certificate OPTIONAL
   } -- see also teletex-organizational-unit-names

   CountryName  at least one of the pair shall be present

   SPKM-REQ ::= [APPLICATION 1] CHOICE SEQUENCE {
      x121-dcc-code         NumericString
                              (SIZE (ub-country-name-numeric-length)),
      iso-3166-alpha2-code  PrintableString
                              (SIZE (ub-country-name-alpha-length))
     requestToken  REQ-TOKEN,
     certif-data   [0]  CertificationData OPTIONAL,
     ...
   }

   AdministrationDomainName

   CertificationData ::= [APPLICATION 2] CHOICE SEQUENCE {
      numeric   NumericString   (SIZE (0..ub-domain-name-length)),
      printable PrintableString (SIZE (0..ub-domain-name-length)) }

   NetworkAddress ::= X121Address  -- see also extended-network-address

   X121Address ::= NumericString (SIZE (1..ub-x121-address-length))



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 58] 53]

Internet-Draft                   SPKM-3                       March                      August 2006


   TerminalIdentifier ::= PrintableString (SIZE
   (1..ub-terminal-id-length))

   PrivateDomainName ::= CHOICE {
      numeric   NumericString   (SIZE (1..ub-domain-name-length)),
      printable PrintableString (SIZE (1..ub-domain-name-length))


     certificationPath          [0]  CertificationPath OPTIONAL,
     certificateRevocationList  [1]  CertificateList OPTIONAL,
     ...
   }

   OrganizationName ::= PrintableString
                               (SIZE (1..ub-organization-name-length)) -- see also teletex-organization-name

   NumericUserIdentifier ::= NumericString
                               (SIZE (1..ub-numeric-user-id-length))

   PersonalName at least one of the above shall be present

   CertificationPath ::= SET SEQUENCE {
      surname
     userKeyId          [0] IMPLICIT PrintableString
                       (SIZE (1..ub-surname-length)),
      given-name  OCTET STRING OPTIONAL,
     userCertif         [1] IMPLICIT PrintableString
                       (SIZE (1..ub-given-name-length))  Certificate OPTIONAL,
      initials
     verifKeyId         [2] IMPLICIT PrintableString
                       (SIZE (1..ub-initials-length))  OCTET STRING OPTIONAL,
      generation-qualifier
     userVerifCertif    [3] IMPLICIT PrintableString
                       (SIZE (1..ub-generation-qualifier-length))
                       OPTIONAL }
     -- see also teletex-personal-name

   OrganizationalUnitNames ::=  Certificate OPTIONAL,
     theCACertificates  [4]  SEQUENCE SIZE
                                (1..ub-organizational-units) OF OrganizationalUnitName CertificatePair OPTIONAL,
     ...
   } -- see Presence of [2] or [3] implies that [0] or [1] must also teletex-organizational-unit-names

   OrganizationalUnitName ::= PrintableString (SIZE
                       (1..ub-organizational-unit-name-length)) be

   -- present.  Presence of [4] implies that at least one of [0], [1],
   -- Built-in Domain-defined Attributes

   BuiltInDomainDefinedAttributes [2], and [3] must also be present.

   REQ-TOKEN ::= SEQUENCE SIZE
                       (1..ub-domain-defined-attributes) OF
                       BuiltInDomainDefinedAttribute

   BuiltInDomainDefinedAttribute {
     req-contents   Req-contents,
     algId          AlgorithmIdentifier,
     req-integrity  Integrity,
     ...
   }

   Integrity ::= BIT STRING

   Req-contents ::= SEQUENCE {
      type PrintableString (SIZE
                      (1..ub-domain-defined-attribute-type-length)),
      value PrintableString (SIZE
                      (1..ub-domain-defined-attribute-value-length)) }
     tok-id        INTEGER(256), -- shall contain 0100 (hex)
     context-id    Random-Integer,
     pvno          BIT STRING,
     timestamp     UTCTime OPTIONAL, -- Extension Attributes mandatory for SPKM-2
     randSrc       Random-Integer,
     targ-name     Name,
     src-name      [0]  Name OPTIONAL,
     req-data      Context-Data,
     validity      [1]  Validity OPTIONAL,
     key-estb-set  Key-Estb-Algs,
     key-estb-req  BIT STRING OPTIONAL,
     key-src-bind  OCTET STRING OPTIONAL,
     auth-data     AuthorizationData OPTIONAL,
     ...
   }

   Random-Integer ::= BIT STRING

   Context-Data ::= SEQUENCE {
     channelId   ChannelId OPTIONAL,
     seq-number  INTEGER OPTIONAL,



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 59] 54]

Internet-Draft                   SPKM-3                       March                      August 2006


   ExtensionAttributes


     options     Options,
     conf-alg    Conf-Algs,
     intg-alg    Intg-Algs,
     owf-alg     OWF-Algs,
     ...
   }

   ChannelId ::= SET SIZE (1..ub-extension-attributes) OF
                  ExtensionAttribute

   ExtensionAttribute OCTET STRING

   Options ::=  SEQUENCE BIT STRING {
      extension-attribute-type [0] IMPLICIT INTEGER
                      (0..ub-extension-attributes),
      extension-attribute-value [1]
                      ANY DEFINED BY extension-attribute-type
     delegation-state(0), mutual-state(1), replay-det-state(2),
     sequence-state(3), conf-avail(4), integ-avail(5),
     target-certif-data-required(6) }

   -- Extension types and attribute values

   common-name INTEGER ::= 1

   CommonName ::= PrintableString (SIZE (1..ub-common-name-length))

   teletex-common-name INTEGER ::= 2

   TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))

   teletex-organization-name INTEGER ::= 3

   TeletexOrganizationName ::=
                   TeletexString (SIZE (1..ub-organization-name-length))

   teletex-personal-name INTEGER ::= 4

   TeletexPersonalName

   Conf-Algs ::= SET CHOICE {
      surname
     algs  [0] IMPLICIT TeletexString
                       (SIZE (1..ub-surname-length)),
      given-name  SEQUENCE OF AlgorithmIdentifier,
     null  [1] IMPLICIT TeletexString
                       (SIZE (1..ub-given-name-length)) OPTIONAL,
      initials    [2] IMPLICIT TeletexString
                       (SIZE (1..ub-initials-length)) OPTIONAL,
      generation-qualifier [3] IMPLICIT TeletexString
                       (SIZE (1..ub-generation-qualifier-length))
                       OPTIONAL  NULL,
     ...
   }

   teletex-organizational-unit-names INTEGER

   Intg-Algs ::= 5

   TeletexOrganizationalUnitNames SEQUENCE OF AlgorithmIdentifier

   OWF-Algs ::= SEQUENCE SIZE
         (1..ub-organizational-units) OF TeletexOrganizationalUnitName

   TeletexOrganizationalUnitName AlgorithmIdentifier

   Key-Estb-Algs ::= TeletexString
                     (SIZE (1..ub-organizational-unit-name-length))

   pds-name INTEGER SEQUENCE OF AlgorithmIdentifier

   SPKM-REP-TI ::= 7

   PDSName SEQUENCE {
     responseToken  REP-TI-TOKEN,
     certif-data    CertificationData OPTIONAL,
     -- present if target-certif-data-required option was
     ...
   } -- set to TRUE in SPKM-REQ

   REP-TI-TOKEN ::= PrintableString (SIZE (1..ub-pds-name-length)) SEQUENCE {
     rep-ti-contents  Rep-ti-contents,
     algId            AlgorithmIdentifier,
     rep-ti-integ     Integrity,
     ...
   }

   Rep-ti-contents ::= SEQUENCE {
     tok-id        INTEGER(512), -- shall contain 0200 (hex)
     context-id    Random-Integer,
     pvno          [0]  BIT STRING OPTIONAL,
     timestamp     UTCTime OPTIONAL,
     randTarg      Random-Integer,
     src-name      [1]  Name OPTIONAL,
     targ-name     Name,



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 60] 55]

Internet-Draft                   SPKM-3                       March                      August 2006


   physical-delivery-country-name INTEGER ::= 8

   PhysicalDeliveryCountryName


     randSrc       Random-Integer,
     rep-data      Context-Data,
     validity      [2]  Validity OPTIONAL,
     key-estb-id   AlgorithmIdentifier OPTIONAL,
     key-estb-str  BIT STRING OPTIONAL,
     auth-data     AuthorizationData OPTIONAL,
     ...
   }

   SPKM-REP-IT ::= CHOICE SEQUENCE {
      x121-dcc-code NumericString (SIZE
   (ub-country-name-numeric-length)),
      iso-3166-alpha2-code PrintableString
                     (SIZE (ub-country-name-alpha-length))
     responseToken  REP-IT-TOKEN,
     algId          AlgorithmIdentifier,
     rep-it-integ   Integrity ,
     ...
   }

   postal-code INTEGER ::= 9

   PostalCode

   REP-IT-TOKEN ::= CHOICE SEQUENCE {
      numeric-code NumericString (SIZE (1..ub-postal-code-length)),
      printable-code PrintableString (SIZE (1..ub-postal-code-length))
     tok-id        INTEGER(768), -- shall contain 0300 (hex)
     context-id    Random-Integer,
     randSrc       Random-Integer,
     randTarg      Random-Integer,
     targ-name     Name,
     src-name      Name OPTIONAL,
     key-estb-rep  BIT STRING OPTIONAL,
     ...
   }

   physical-delivery-office-name INTEGER ::= 10

   PhysicalDeliveryOfficeName ::= PDSParameter

   physical-delivery-office-number INTEGER ::= 11

   PhysicalDeliveryOfficeNumber ::= PDSParameter

   extension-OR-address-components INTEGER ::= 12

   ExtensionORAddressComponents ::= PDSParameter

   physical-delivery-personal-name INTEGER ::= 13

   PhysicalDeliveryPersonalName ::= PDSParameter

   physical-delivery-organization-name INTEGER ::= 14

   PhysicalDeliveryOrganizationName ::= PDSParameter

   extension-physical-delivery-address-components INTEGER

   SPKM-GSS-ERROR ::= 15

   ExtensionPhysicalDeliveryAddressComponents SEQUENCE {
     error-token      GSS-ERROR-TOKEN,
     algId            AlgorithmIdentifier,
     certif-data      CertificationData,
     integrity        Integrity,
     ...
   }

   GSS-ERROR-TOKEN ::= PDSParameter

   unformatted-postal-address   SEQUENCE {
     tok-id           INTEGER (1280), -- shall contain 0500 (hex)
     context-id       Random-Integer,
     major-status [0] INTEGER,  -- the GSS major status value
     minor-status [1] INTEGER,  -- the GSS minor status value
     ...
   }

   SPKM-ERROR ::= 16

   UnformattedPostalAddress ::= SET {
      printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
            OF PrintableString (SIZE (1..ub-pds-parameter-length))
            OPTIONAL,
      teletex-string TeletexString
            (SIZE (1..ub-unformatted-address-length)) OPTIONAL {
     errorToken  ERROR-TOKEN,
     algId       AlgorithmIdentifier,
     integrity   Integrity -- "token" is ERROR-TOKEN
   }

   street-address INTEGER ::= 17



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 61] 56]

Internet-Draft                   SPKM-3                       March                      August 2006


   StreetAddress ::= PDSParameter

   post-office-box-address INTEGER ::= 18

   PostOfficeBoxAddress ::= PDSParameter

   poste-restante-address INTEGER ::= 19

   PosteRestanteAddress ::= PDSParameter

   unique-postal-name INTEGER ::= 20

   UniquePostalName ::= PDSParameter

   local-postal-attributes INTEGER


   ERROR-TOKEN ::= 21

   LocalPostalAttributes SEQUENCE {
     tok-id      INTEGER(1024), -- shall contain 0400 (hex)
     context-id  Random-Integer
   }

   SPKM-MIC ::= PDSParameter

   PDSParameter SEQUENCE {
     mic-header  Mic-Header,
     int-cksum   BIT STRING,
     ...
   }

   Mic-Header ::= SET SEQUENCE {
      printable-string PrintableString
                   (SIZE(1..ub-pds-parameter-length))
     tok-id      INTEGER(257), -- shall contain 0101 (hex)
     context-id  Random-Integer,
     int-alg     [0]  AlgorithmIdentifier OPTIONAL,
      teletex-string TeletexString
                   (SIZE(1..ub-pds-parameter-length)) OPTIONAL
     snd-seq     [1]  SeqNum OPTIONAL,
     ...
   }

   extended-network-address INTEGER ::= 22

   ExtendedNetworkAddress

   SeqNum ::= CHOICE SEQUENCE {
      e163-4-address
     num      INTEGER,
     dir-ind  BOOLEAN,
     ...
   }

   SPKM-WRAP ::= SEQUENCE {
         number      [0] IMPLICIT NumericString
                          (SIZE (1..ub-e163-4-number-length)),
         sub-address [1] IMPLICIT NumericString
                          (SIZE (1..ub-e163-4-sub-address-length))
                          OPTIONAL },
      psap-address [0] IMPLICIT PresentationAddress
     wrap-header  Wrap-Header,
     wrap-body    Wrap-Body,
     ...
   }

   PresentationAddress

   Wrap-Header ::= SEQUENCE {
       pSelector
     tok-id      INTEGER(513), -- shall contain 0201 (hex)
     context-id  Random-Integer,
     int-alg     [0] EXPLICIT OCTET STRING  AlgorithmIdentifier OPTIONAL,
       sSelector
     conf-alg    [1] EXPLICIT OCTET STRING  Conf-Alg OPTIONAL,
       tSelector
     snd-seq     [2] EXPLICIT OCTET STRING  SeqNum OPTIONAL,
       nAddresses    [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING
     ...
   }

   terminal-type  INTEGER

   Conf-Alg ::= 23

   TerminalType CHOICE {
     algId [0]  AlgorithmIdentifier,
     null  [1]  NULL,
     ...
   }

   Wrap-Body ::= INTEGER SEQUENCE {
      telex (3),
      teletex (4),
      g3-facsimile (5),
      g4-facsimile (6),
     int-cksum  BIT STRING,



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 62] 57]

Internet-Draft                   SPKM-3                       March                      August 2006


      ia5-terminal (7),
      videotex (8)


     data       BIT STRING,
     ...
   } (0..ub-integer-options)

   -- Extension Domain-defined Attributes

   teletex-domain-defined-attributes INTEGER ::= 6

   TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
      (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute

   TeletexDomainDefinedAttribute

   SPKM-DEL ::= SEQUENCE {
           type TeletexString
                  (SIZE (1..ub-domain-defined-attribute-type-length)),
           value TeletexString
                  (SIZE (1..ub-domain-defined-attribute-value-length))
     del-header  Del-Header,
     int-cksum   BIT STRING
   }

   --  specifications of Upper Bounds MUST be regarded as mandatory
   --  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
   --  Upper Bounds

   -- Upper Bounds
   ub-name INTEGER ::= 32768
   ub-common-name INTEGER ::= 64
   ub-locality-name INTEGER ::= 128
   ub-state-name INTEGER ::= 128
   ub-organization-name INTEGER ::= 64
   ub-organizational-unit-name INTEGER ::= 64
   ub-title INTEGER ::= 64
   ub-serial-number INTEGER ::= 64
   ub-match INTEGER ::= 128
   ub-emailaddress-length INTEGER ::= 128
   ub-common-name-length INTEGER ::= 64
   ub-country-name-alpha-length INTEGER ::= 2
   ub-country-name-numeric-length INTEGER ::= 3
   ub-domain-defined-attributes INTEGER ::= 4
   ub-domain-defined-attribute-type-length INTEGER ::= 8
   ub-domain-defined-attribute-value-length INTEGER ::= 128
   ub-domain-name-length INTEGER ::= 16
   ub-extension-attributes INTEGER ::= 256
   ub-e163-4-number-length INTEGER ::= 15
   ub-e163-4-sub-address-length INTEGER ::= 40
   ub-generation-qualifier-length INTEGER

   Del-Header ::= 3
   ub-given-name-length INTEGER SEQUENCE {
     tok-id      INTEGER(769), -- shall contain 0301 (hex)
     context-id  Random-Integer,
     int-alg     [0]  AlgorithmIdentifier OPTIONAL,
     snd-seq     [1]  SeqNum OPTIONAL
   }

   -- other types
   -- from [RFC-1508]
   MechType ::= 16
   ub-initials-length INTEGER OBJECT IDENTIFIER

   InitialContextToken ::= 5
   ub-integer-options INTEGER [APPLICATION 0] IMPLICIT SEQUENCE {
     thisMech           MechType,
     innerContextToken  SPKMInnerContextToken
   }

   SPKMInnerContextToken ::= 256
   ub-numeric-user-id-length INTEGER CHOICE {
     req     [0]  SPKM-REQ,
     rep-ti  [1]  SPKM-REP-TI,
     rep-it  [2]  SPKM-REP-IT,
     error   [3]  SPKM-ERROR,
     mic     [4]  SPKM-MIC,
     wrap    [5]  SPKM-WRAP,
     del     [6]  SPKM-DEL,
     gss-err [7]  SPKM-GSS-ERROR,
     ...
   }

   -- from [RFC-1510]
   AuthorizationData ::= 32
   ub-organization-name-length INTEGER
     SEQUENCE OF SEQUENCE {ad-type  INTEGER,
                           ad-data  OCTET STRING}

   -- object identifier assignments
   md5-DES-CBC OBJECT IDENTIFIER ::= 64
   ub-organizational-unit-name-length INTEGER
     {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      integrity(3) md5-DES-CBC(1)}

   sum64-DES-CBC OBJECT IDENTIFIER ::= 32



Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 63] 58]

Internet-Draft                   SPKM-3                       March                      August 2006


   ub-organizational-units INTEGER ::= 4
   ub-pds-name-length INTEGER ::= 16
   ub-pds-parameter-length INTEGER ::= 30
   ub-pds-physical-address-lines INTEGER ::= 6
   ub-postal-code-length INTEGER ::= 16
   ub-pseudonym INTEGER ::= 128
   ub-surname-length INTEGER ::= 40

   ub-terminal-id-length INTEGER ::= 24
   ub-unformatted-address-length INTEGER


     {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      integrity(3) sum64-DES-CBC(2)}

   spkm-1 OBJECT IDENTIFIER ::= 180
   ub-x121-address-length INTEGER
     {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) spkm(1) spkm-1(1)}

   spkm-2 OBJECT IDENTIFIER ::= 16

   -- Note - upper bounds on string types, such as TeletexString, are
   -- measured in characters.  Excepting PrintableString or IA5String,
     {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) spkm(1) spkm-2(2)}

   END







































Adams, et al.           Expires February 19, 2007              [Page 59]

Internet-Draft                   SPKM-3                      August 2006


Appendix B.  Appendix B: Changes from RFC2847 and RFC2025

   SPKM3 mandates one K-ALG (dhKeyAgreement).

   SPKM3 addes aes-256-cbc, aes128-cbc, des-ede3-cbc to C-ALGs.

   SPKM3 extends the SPKMInnerContextToken with a
   -- significantly greater number gss-error choice of octets will
   type SPKM-GSS-ERROR.  This spec defines a new ERROR token (SPKM-GSS-
   ERROR) that contains a certificate information of the sender and
   major and minor status codes.

   SPKM3 requires that for mutual authentication, certif-data in the
   SPKM-REQ must be present (though it is defined OPTIONAL because no
   certif-data is present during anonymous SPKM3).

   SPKM3 clarifies the use of the CertificatePair structure.

   SPKM3 suggest to deprecate the use of authorizationData in SPKM-REQ
   token.  Instead, SPKM-3 moves auth-data to Req-contents and Rep-ti-
   contents so that its contents can be required integrity protected.

   SPKM3 suggest to hold
   -- such a value.  As a minimum, 16 octets, or twice deprecate the specified
   -- upper bound, whichever is use of DELETE tokens.

   SPKM3 clarifies the larger, should be allowed use of names.  It defines a new name type to
   represent distinguished names.

   SPKM3 includes an ASN1 module for
   -- TeletexString.  For UTF8String or UniversalString at least four
   -- times SPKM3 structures.

   SPKM3 must send the upper bound should be allowed.

   END

      --from [PKCS3] (the parameter to be used with dhKeyAgreement) --

      DHParameter ::= SEQUENCE {
        prime              INTEGER,  -- p
        base               INTEGER,  -- g
        privateValueLength INTEGER certif-data in SPKM-REP-TI and therefore changes
   the certif-data from OPTIONAL
      } to mandatory.

   SPKM3 deprecates a mandatory support function spkm_parse_token().

   SPKM3 recommends that digital signature algorithms are only use to
   secure context establishment tokens, but not negotiated for security
   services.

   SPKM-3 proposes to use extensibility markers for most of the it's
   ASN1 structures.

6.  References

   [3DES]     American National Standard X9.52 - 1998, "Triple Data
              Encryption Algorithm Modes of Operation", Accredited
              Standards Committee  X9, July 1998.

   [9798]     ISO/IEC 9798-3, "Information technology - Security
              Techniques - Entity authentication mechanisms - Part 3:



Adams, et al.           Expires February 19, 2007              [Page 60]

Internet-Draft                   SPKM-3                      August 2006


              Entity authentication using a public key algorithm", ISO/
              IEC , 1993.

   [Dobbertin]
              Dobbertin, H., "The Status of Md5 After a Recent Attack",
              RFC 2104, 1996.

   [EFF]      Gilmore, J., "Cracking Des: Secrets of Encryption
              Research, Wiretap Politics & Chip Design", 1998.

   [FIPS]     National Institute of Standards and Technology, "Secure
              Hash Standard (SHA-1)", April 1995.



Adams, et al.            Expires October 1, 2006               [Page 64]

Internet-Draft                   SPKM-3                       March 2006

   [FIPS113]  National Institute of Standards and Technology, Federal
              Information Processing Standard 113, "Computer Data
              Authentication", May 1985.

   [IEEE1363]
              IEEE, "Standard Specifications for Public Key
              Cryptography", IEEE 1363, 2000.

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

   [PKCS1]    "RSA Encryption Standard, Version 1.5, RSA Data Security,
              Inc.,", November 1993.

   [PKCS3]    "Diffie-Hellman Key-Agreement Standard, Version 1.4", RSA
              Data Security , November 1993.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

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

   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
              (SPKM)", RFC 2025, October 1996.

   [RFC2078]  Linn, J., "Generic Security Service Application Program
              Interface, Version 2", RFC 2078, January 1997.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.



Adams, et al.           Expires February 19, 2007              [Page 61]

Internet-Draft                   SPKM-3                      August 2006


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]  Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
              May 1997.

   [RFC2252]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3): Attribute Syntax Definitions",
              RFC 2252, December 1997.

   [RFC2253]  Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
              Access Protocol (v3): UTF-8 String Representation of
              Distinguished Names", RFC 2252, December 1997.

   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
              RFC 2412, November 1998.

   [RFC2437]  Kaliski, B. and J. Standdon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

   [RFC2612]  Adams, C. and J. Gilchrist, "The CAST-256 Encryption
              Algorithm", RFC 2612, June 1999.

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, June 1999.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface, Version 2, Update 1", RFC 2743, January 2000.

   [RFC2744]  Wray, J., "Generic Security Service Application Program



Adams, et al.            Expires October 1, 2006               [Page 65]

Internet-Draft                   SPKM-3                       March 2006
              Interface: C-bindings", RFC 2744, Januart 2000.

   [RFC2847]  Eisler, M. and Zambeel, "LIPKEY - A Low Infrastructure
              Public Key Mechanism Using SPKM", RFC 2847, June 2000.

   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              Lists (CRL) Profile", RFC 3279, April 2002.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003.



Adams, et al.           Expires February 19, 2007              [Page 62]

Internet-Draft                   SPKM-3                      August 2006


   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, July 2003.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [Sandberg]
              Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., and B.
              Lyon, "Design and Implementation of the Sun Network
              Filesystem", Proceedings of the 1985 Summer USENIX
              Technical Conference , 1985.

   [X509]     ISO/IEC 9594-2, "Information Technology - Open Systems
              Interconnection - The Directory:  Models", CCITT/ITU
              Recommendation X.509, 1993.

   [X690]     ISO/IEC 8825-1:1998, "ASN.1 encoding rules: Specification
              of Basic Encoding Rules (BER), Canonical Encoding Rules
              (CER) and Distinguished Encoding Rules (DER)", ITU-T
              Recommendation X.690, 1997.

   [Young]    Young, E., "Collected timing results from the SSLeay
              source code distribution", 1997.


Authors' Addresses

   C. Adams
   Authors


   Mike Eisler
   Authors

   Email: email2mre-ietf@yahoo.com











Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 66] 63]

Internet-Draft                   SPKM-3                       March                      August 2006


   Mike Eisler
   Authors

   Email: email2mre-ietf@yahoo.com


   William A. (Andy) Adamson
   Editors
   CITI, University of Michigan
   535 W. William
   Ann Arbor MI 48103
   USA

   Email: andros@umich.edu


   Olga Kornievskaia
   Editors
   CITI, University of Michigan
   535 W. William
   Ann Arbor MI 48103
   USA

   Email: aglo@umich.edu

































Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 67] 64]

Internet-Draft                   SPKM-3                       March                      August 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Adams, et al.           Expires October 1, 2006 February 19, 2007              [Page 68] 65]

----