Internet DRAFT - draft-adamson-rfc2847-bis
draft-adamson-rfc2847-bis
Network Working Group C. Adams
Internet-Draft M. Eisler
Expires: February 19, 2007 Authors
W. Adamson
O. Kornievskaia
Editors
August 18, 2006
Low Infrastructure Public Key Mechanisms: SPKM-3 and LIPKEY
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 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 February 19, 2007 [Page 1]
Internet-Draft SPKM-3 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 . . . . . . . . . . . . . . . . . . 16
2.4.1.2 SPKM-REP-TI Token . . . . . . . . . . . . . . . . 22
2.4.1.3 SPKM-REP-IT Token . . . . . . . . . . . . . . . . 24
2.4.2 Error Tokens . . . . . . . . . . . . . . . . . . . . . 25
2.4.2.1 SPKM-ERROR Token . . . . . . . . . . . . . . . . . 25
2.4.2.2 SPKM-GSS-ERROR Token . . . . . . . . . . . . . . . 26
2.4.3 Per-message Tokens . . . . . . . . . . . . . . . . . . 28
2.4.3.1 SPKM-MIC Token . . . . . . . . . . . . . . . . . . 28
2.4.3.1.1 Checksum . . . . . . . . . . . . . . . . . . . 29
2.4.3.1.2 Sequence Number . . . . . . . . . . . . . . . 29
2.4.3.1.3 Sequence Number Processing . . . . . . . . . . 30
2.4.3.2 SPKM-WRAP Token . . . . . . . . . . . . . . . . . 30
2.4.3.2.1 Checksum . . . . . . . . . . . . . . . . . . . 31
2.4.3.2.2 Sequence Number . . . . . . . . . . . . . . . 32
2.4.3.2.3 Data Encryption . . . . . . . . . . . . . . . 32
2.4.4 Context Deletion Token . . . . . . . . . . . . . . . . 33
2.5 Name Types and Object Identifiers . . . . . . . . . . . . 34
2.5.1 Mandatory Name Forms . . . . . . . . . . . . . . . . . 34
2.5.1.1 SPKM3 Principal Name Form . . . . . . . . . . . . 34
2.5.1.2 Host-Based Service Name Form . . . . . . . . . . . 34
2.5.1.3 Anonymous Name Form . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 37
2.7 Parameter Definitions . . . . . . . . . . . . . . . . . . 37
2.7.1 Minor Status Codes . . . . . . . . . . . . . . . . . . 37
2.7.2 Non-SPKM-3-specific codes . . . . . . . . . . . . . . 37
2.7.2.1 GSS-Related codes . . . . . . . . . . . . . . . . 37
2.7.2.2 Implementation-Related codes . . . . . . . . . . . 38
2.7.3 SPKM-3-specific-codes . . . . . . . . . . . . . . . . 38
2.8 Quality of Protection Values . . . . . . . . . . . . . . . 39
3. A Low Infrastructure Public Key Mechanism Using SPKM-3
(LIPKEY) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1 How LIPKEY Initiator Uses SPKM-3 . . . . . . . . . . . . . 44
3.1.1 GSS_Import_name . . . . . . . . . . . . . . . . . . . 44
3.1.2 GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . 44
3.1.3 GSS_Init_sec_context . . . . . . . . . . . . . . . . . 44
3.1.3.1 LIPKEY Caller Specified anon_req_flag as TRUE . . 45
3.1.3.2 LIPKEY Caller Specified anon_req_flag as FALSE . . 45
3.1.4 Other operations . . . . . . . . . . . . . . . . . . . 47
3.2 How LIPKEY Target Uses SPKM-3 . . . . . . . . . . . . . . 47
3.2.1 GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . 47
3.2.2 GSS_Accept_sec_context . . . . . . . . . . . . . . . . 47
3.3 LIPKEY Description . . . . . . . . . . . . . . . . . . . . 48
3.3.1 Mechanism Type . . . . . . . . . . . . . . . . . . . . 48
3.3.2 Token Formats . . . . . . . . . . . . . . . . . . . . 48
3.3.2.1 Context Tokens Prior to SPKM-3 Context
Establishment . . . . . . . . . . . . . . . . . . 48
3.3.2.2 Post-SPKM-3 Context Establishment Tokens . . . . . 49
3.3.2.2.1 From LIPKEY Initiator . . . . . . . . . . . . 49
3.3.2.2.2 From LIPKEY Target . . . . . . . . . . . . . . 49
3.3.2.3 Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . 49
3.3.3 Name Types . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Quality of Protection . . . . . . . . . . . . . . . . 50
4. Security Considerations . . . . . . . . . . . . . . . . . . . 51
4.1 Password Management . . . . . . . . . . . . . . . . . . . 51
4.2 Certification Authorities . . . . . . . . . . . . . . . . 51
4.3 HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 51
4.4 Security of cast5CBC . . . . . . . . . . . . . . . . . . . 51
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
A. Appendix A: SPKM-3 ANS.1 Module Definition . . . . . . . . . . 53
B. Appendix B: Changes from RFC2847 and RFC2025 . . . . . . . . . 60
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . 65
Adams, et al. Expires February 19, 2007 [Page 3]
Internet-Draft SPKM-3 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 February 19, 2007 [Page 4]
Internet-Draft SPKM-3 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 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
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 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".
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
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 [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 [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 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.
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 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].
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
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 be
include in a list of negotiated 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]. 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 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].
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)
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 February 19, 2007 [Page 10]
Internet-Draft SPKM-3 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).
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.
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 [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))
Adams, et al. Expires February 19, 2007 [Page 12]
Internet-Draft SPKM-3 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.
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], all the tokens emitted by the SPKM-3 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
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-err [7] 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.
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 information which is included in 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 Distinguished
Encoding Rules (DER) as described in [X690]. SPKM-3 proposes to use
extensibility markers for most of the 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
...
}
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath OPTIONAL,
certificateRevocationList [1] CertificateList 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,
...
} -- 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.
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,
-- "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.
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,
-- will not be use in SPKM-3.
auth-data AuthorizationData OPTIONAL,
-- see RFC1964 for a discussion of auth-data. note,
-- auth-data is 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 February 19, 2007 [Page 18]
Internet-Draft SPKM-3 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,
-- 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 mechanism implementation is responsible for maintaining a
mapping between the context-id value which is included in every token
and a context_handle, thus associating an individual token with its
proper context. Clearly the value of context_handle may be locally
determined and may, in fact, be associated with memory containing
sensitive data on the local system, and so having the context-id
actually be set equal to a computed context_handle will not work in
general. Conversely, having the context_handle actually be set equal
to a computed context-id will not work in general either, because
context_handle must be returned to the application by the 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 be involved in the
computation. Consequently, context_handle and context-id must be
Adams, et al. Expires February 19, 2007 [Page 19]
Internet-Draft SPKM-3 August 2006
computed separately and the mechanism implementation must be able to
map from one to the other by the completion of context establishment
at the latest.
Computation of context-id during context establishment is
accomplished as follows. Each SPKM-3 implementation 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 in the context-id field of the SPKM-
REQ token. If no further context establishment tokens are expected
(as for unilateral authentication in SPKM-3), then this value is
taken to be the context-id (if this is unacceptable to the target
then an error token must be generated). Otherwise, the target
generates its random number and concatenates it to the end of the
initiator's random number. This concatenated value is then taken to
be the context-id and 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 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 the target in the case of
unilateral authentication using SPKM-3, simply because it has not
contributed to the freshness of the computed context-id (instead, it
must trust the freshness of the initiator's random number, or reject
the context).
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 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 of time specified by "validity" is to be
taken as definitive (rather than the actual times given in this
parameter).
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
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 mutual-req bit is not set in the
application's call to GSS_Init_sec_context(). SPKM-3 accomplishes
this using both SPKM-REQ and SPKM-REP-TI (thereby authenticating the
target to the initiator).
Applications requiring authentication of both peers (initiator and
target) MUST request mutual authentication, resulting in "mutual-
state" being set within SPKM-REQ Options. In response to such a
request, the context target will reply to the initiator with an SPKM-
REP-TI token. If SPKM-REP-TI is sent, the initiator will then reply
to the target with an SPKM-REP-IT token, completing the (random-
number-based) mutual authentication context establishment exchange.
Other bits in the Options field 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
...
}
-- 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
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 is anonymous and will not have a
certificate for itself, the initiator cannot use an integrity
algorithm that uses a digital signature; it MUST use a MAC algorithm.
If the SPKM-3 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 OF AlgorithmIdentifier
-- Contains exactly one algorithm in REQ-TOKEN for SPKM-3
-- 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 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
...
}
Adams, et al. Expires February 19, 2007 [Page 22]
Internet-Draft SPKM-3 August 2006
Rep-ti-contents ::= SEQUENCE {
tok-id INTEGER (512), -- shall contain 0200 (hex)
context-id Random-Integer, -- see Section 2.9.2
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
-- 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 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.
auth-data AuthorizationData OPTIONAL,
...
}
The protocol version number (pvno) parameter is a BIT STRING which
uses as many bits as necessary to specify a single SPKM protocol
version offered by the initiator which is supported by the target
(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 by the target, a error token MUST be returned so that the
context is never established. If the initiator's pvno has only one
bit set and the target happens to support this protocol version, then
this version is 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 February 19, 2007 [Page 23]
Internet-Draft SPKM-3 August 2006
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 proper version (essentially starting context
establishment anew).
The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a
signature algorithm like md5WithRSAEncryption, sha1WithRSAEncryption,
or dsaWithSHA1.
If the req-token has an algId of NULL-MAC, then the target MUST
compute the rep-ti-integ on the concatenation of the req-contents and
rep-ti-contents.
When mutual authentication is used, the target verifies the
initiator's SPKM-REQ token by verifying that the req-integrity field
was computed by the owner of the userCertif field. This is phase 1
of authenticating the target.
A note for implementors. Let's assume that the requestor calls the
GSS_Init_sec_context() and does not request integrity or
confidentiality services and, therefore, only authentication step is
required. An artifact of [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-REP-IT ::= SEQUENCE {
responseToken REP-IT-TOKEN,
algId AlgorithmIdentifier,
-- MUST contain whatever value was supplied in REQ-TOKEN
rep-it-integ Integrity, -- "token" is REP-IT-TOKEN
...
}
Adams, et al. Expires February 19, 2007 [Page 24]
Internet-Draft SPKM-3 August 2006
REP-IT-TOKEN ::= SEQUENCE {
tok-id INTEGER (768), -- shall contain 0300 (hex)
context-id Random-Integer, -- see Section 2.9.2
randSrc Random-Integer,
-- MUST contain whatever value was supplied in REQ-TOKEN
randTarg Random-Integer,
-- MUST contain whatever value was supplied in REP-TI-TOKEN
targ-name Name,
-- MUST contain whatever value was supplied in REP-TI-TOKEN
src-name Name OPTIONAL,
key-estb-rep BIT STRING OPTIONAL,
-- contains the response to targets key-estb-str
-- (if target selected a 2-pass K-ALG)
...
}
The randTarg field in the 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 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 February 19, 2007 [Page 25]
Internet-Draft SPKM-3 August 2006
SPKM-ERROR ::= SEQUENCE {
error-token ERROR-TOKEN,
algId AlgorithmIdentifier,
-- MUST be one of the digital 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 the integrity
of the token. In the low infrastructure and the absence of directory
services, the receiving side of the SPKM-ERROR token is therefore
unable to verify the integrity of the 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 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) 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().
2.4.3.1 SPKM-MIC 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,
-- 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, -- 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, -- 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
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
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 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,
...
}
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, -- sequence number field
...
}
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
-- Checksum of header and data, calculated according
-- to algorithm specified in int-alg field.
data BIT STRING,
-- encrypted or plaintext data.
...
}
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] 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
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(). [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 [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:
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
This section discusses the name types which may be passed as input to
the SPKM3's GSS_Import_name() call, and 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 the SPKM3 GSS-API mechanism.
2.5.1.1 SPKM3 Principal Name Form
This name form shall be represented by the Object Identifier (FIXME:
need an OID). The recommended symbolic name for this type is
GSS_SPKM3_NT_PRINCIPAL_NAME.
This name type corresponds to the 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 represent services associated with host
computers and should use the symbolic name 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 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
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. "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", then, encoding it in a single RDN sequence.
When the initiator processes REP-TI-TOKEN, it verifies that target
name the initiator constructed matches the information in the
target's certificate. A note to 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 "directoryName" extension of the
target's subject alternate name (SAN) in the 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/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 SAN in the
target 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=nfs/citi.umich.edu"
-- if the target name contains just a 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 "dsnName" entry of the target's
SAN in the 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 initiator and should
use the symbolic name of GSS_C_NT_ANONYMOUS and a printable string
"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.5.1.4 Exported Name Object Form
This name type represents a self-describing object, whose framing
structure is defined at the mechanism-independent level by GSS-API
Version 2. When generated by the SPKM3 mechanism, the mechanism OID
within the exportable name shall be that of the SPKM3 mechanism. The
mechanism-specific name component within the exportable name should
be created by taking the following steps:
First, start with the GSS_SPKM3_NT_PRINCIPAL_NAME name form. This
name type corresponds to the string representation of an X500
Distinguished Name. It is an RFC2253 [RFC2253] compliant string
representation of the distinguished name with the 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.
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" */
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 */
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
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.
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.
-- 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, 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, 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.
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.
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 to produce SPKM tokens. Since the
mechanism that the application uses is LIPKEY, LIPKEY will wrap some
of the SPKM-3 tokens with LIPKEY prefixes. The exact definition of
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 the target's name,
typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE
name type. Ultimately, the output of GSS_Import_name will apply to
an SPKM-3 mechanism type because a LIPKEY target is 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 user name and password. How the
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 graphical user interface running might
trigger the appearance of a pop up window that prompts for the
information. A application embedded into the operating system, such
as an NFS [Sandberg] client implemented as a native file system might
broadcast a message to the user's terminals telling him to invoke a
command that prompts for the information.
Because the credentials will not be used until GSS_Init_sec_context
is called, the LIPKEY implementation will need to safeguard the
credentials. If this is a problem, the implementation may instead
defer actual acquisition of the user name and password until
GSS_Init_sec_context is ready to send the user name and password to
the target. In that event, the output_cred_handle argument of
GSS_Acquire_cred would simply be a reference that mapped to the
principal corresponding to the desired_name argument. A subsequent
GSS_Init_sec_context call would consider the mapping of
claimant_cred_handle to principal when it acquires the user name and
password. For example, the aforementioned pop up window might fill
in the user name portion of the dialog with a default value that maps
to the principal referred to in claimant_cred_handle.
3.1.3 GSS_Init_sec_context
When a program invokes GSS_Init_sec_context on the LIPKEY mechanism
type, if the context handle is NULL, the 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 requirements described previously. This call to
SPKM-3 MUST have the following attributes:
claimant_cred_handle is NULL
mutual_req_flag is FALSE
anon_req_flag is TRUE
input_token is NULL
mech_type is the OID of the SPKM-3 mechanism
Keep in mind the above attributes are in the GSS_Init_sec_context
call from the LIPKEY mechanism down to 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 the LIPKEY GSS_Init_sec_context arguments.
The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3
context handle. The remainder of the description of the LIPKEY
GSS_Init_sec_context call depends on whether the caller of the LIPKEY
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 LIPKEY caller all the outputs from the
SPKM-3 GSS_Init_sec_context call, including the
output_context_handle, output_token, and mech_type. In this way,
LIPKEY now "gets out of the way" of GSS-API processing between the
application and SPKM-3, because nothing in the returned outputs
relates to LIPKEY. This is necessary, because LIPKEY context tokens
do not have provision for specifying anonymous initiators. This is
because SPKM-3 is sufficient for purpose of supporting anonymous
initiators in a low infrastructure environment.
If all goes well, the caller of LIPKEY will be returned a
major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and so the caller
of LIPKEY will send the output_token to the target. The caller of
LIPKEY then receives the response token from the target, and directly
invokes the SPKM-3 GSS_Init_sec_context. Upon return, 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 to allocate a context handle for
itself, and record in the LIPKEY context handle the 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 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 SPKM-3 Context
Establishment." All the other returned outputs will be those that
the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all
went well, the SPKM-3 mechanism will have returned a major_status of
GSS_S_CONTINUE_NEEDED.
The caller of the LIPKEY GSS_Init_sec_context routine will see a
major_status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY
will send the output_token to the target. The caller of LIPKEY then
receives the target's response token, and 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 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 claimant_cred_handle on the first call to the LIPKEY
GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3
context handle as the input to GSS_Wrap (with conf_req_flag set to
TRUE) to encrypt what the claimant_cred_handle refers to (user name
and password), and returns that as the output_token to the caller of
LIPKEY (provided the conf_state output from the call to SPKM-3's
GSS_Wrap is TRUE), along with a major_status of
GSS_S_CONTINUE_NEEDED.
The caller of LIPKEY sends its second context establishment token to
the target, and waits for a token provided by the target's
GSS_Accept_sec_context routine. The target's LIPKEY
GSS_Accept_sec_context routine invokes 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 receives the target's response token, and passes
this via the input_token parameter to the LIPKEY GSS_Init_sec_context
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 February 19, 2007 [Page 46]
Internet-Draft SPKM-3 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 a secure channel to transmit the
user name and password. The target must authenticate the initiator
when it receives the user name and password.
The SPKM-3 context remains established while the LIPKEY context is
established. If the SPKM-3 context expires before the LIPKEY context
is destroyed, the LIPKEY implementation should expire the LIPKEY
context and return the appropriate error on the next GSS-API
operation.
3.1.4 Other operations
For other operations, the LIPKEY context acts as a pass through to
the SPKM-3 context. Operations that affect or inquire context state,
such as GSS_Delete_sec_context, GSS_Export_sec_context,
GSS_Import_sec_context, and GSS_Inquire_context will require a pass
through to the SPKM-3 context and a state modification of the LIPKEY
context.
3.2 How LIPKEY Target Uses SPKM-3
As with the initiator, the imported name will be that of the target.
3.2.1 GSS_Acquire_cred
The target calls the LIPKEY GSS_Acquire_cred routine to get a
credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred
routine. The desired_name is 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 handle is 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 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, and the LIPKEY GSS_Accept_sec_context call
returns the output_token to the caller, but with a major_status of
GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected
to send the user name and password.
Adams, et al. Expires February 19, 2007 [Page 47]
Internet-Draft SPKM-3 August 2006
Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token
the target receives will contain the user name and password, wrapped
by the output of an SPKM-3 GSS_Wrap call. The target invokes the
LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3
GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then
compares the user name and password with its user name name and
password database. If the initiator's user name and password are
valid, GSS_S_COMPLETE is returned to the caller. Otherwise
GSS_S_FAILURE is returned. In either case, an output_token - equal
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 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 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 SPKM-3 context is established, there is just one token sent
from the initiator to the target, and one token returned 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 February 19, 2007 [Page 49]
Internet-Draft SPKM-3 August 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 February 19, 2007 [Page 50]
Internet-Draft SPKM-3 August 2006
4. Security Considerations
Security issues are discussed throughout this memo.
4.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.
4.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.
4.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].
4.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 an OPTIONAL 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 February 19, 2007 [Page 51]
Internet-Draft SPKM-3 August 2006
5. Acknowledgments
We are extremely grateful for contributions to the makings of this
document by Nicollas Williams, Martix Rex, Kevin Coffman, and Sandeep
Patel.
Adams, et al. Expires February 19, 2007 [Page 52]
Internet-Draft SPKM-3 August 2006
Appendix A. Appendix A: SPKM-3 ANS.1 Module Definition
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.
-- Module SpkmGssTokens (RFC 2025:10/1996)
SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}
--
-- Copyright (C) The Internet Society (1996). This version of
-- this ASN.1 module is part of RFC 2025;
-- see 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) };
-- types
CertificatePair ::= SEQUENCE {
issuedByThisCA [0] Certificate OPTIONAL,
issuedToThisCA [1] Certificate OPTIONAL
} -- at least one of the pair shall be present
SPKM-REQ ::= SEQUENCE {
requestToken REQ-TOKEN,
certif-data [0] CertificationData OPTIONAL,
...
}
CertificationData ::= SEQUENCE {
Adams, et al. Expires February 19, 2007 [Page 53]
Internet-Draft SPKM-3 August 2006
certificationPath [0] CertificationPath OPTIONAL,
certificateRevocationList [1] CertificateList OPTIONAL,
...
} -- at least one of the above shall be present
CertificationPath ::= SEQUENCE {
userKeyId [0] OCTET STRING OPTIONAL,
userCertif [1] Certificate OPTIONAL,
verifKeyId [2] OCTET STRING OPTIONAL,
userVerifCertif [3] Certificate OPTIONAL,
theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL,
...
} -- Presence of [2] or [3] implies that [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.
REQ-TOKEN ::= SEQUENCE {
req-contents Req-contents,
algId AlgorithmIdentifier,
req-integrity Integrity,
...
}
Integrity ::= BIT STRING
Req-contents ::= SEQUENCE {
tok-id INTEGER(256), -- shall contain 0100 (hex)
context-id Random-Integer,
pvno BIT STRING,
timestamp UTCTime OPTIONAL, -- 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 February 19, 2007 [Page 54]
Internet-Draft SPKM-3 August 2006
options Options,
conf-alg Conf-Algs,
intg-alg Intg-Algs,
owf-alg OWF-Algs,
...
}
ChannelId ::= OCTET STRING
Options ::= BIT STRING {
delegation-state(0), mutual-state(1), replay-det-state(2),
sequence-state(3), conf-avail(4), integ-avail(5),
target-certif-data-required(6) }
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL,
...
}
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
SPKM-REP-TI ::= 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 ::= 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 February 19, 2007 [Page 55]
Internet-Draft SPKM-3 August 2006
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 ::= SEQUENCE {
responseToken REP-IT-TOKEN,
algId AlgorithmIdentifier,
rep-it-integ Integrity ,
...
}
REP-IT-TOKEN ::= SEQUENCE {
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,
...
}
SPKM-GSS-ERROR ::= SEQUENCE {
error-token GSS-ERROR-TOKEN,
algId AlgorithmIdentifier,
certif-data CertificationData,
integrity Integrity,
...
}
GSS-ERROR-TOKEN ::= 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 ::= SEQUENCE {
errorToken ERROR-TOKEN,
algId AlgorithmIdentifier,
integrity Integrity -- "token" is ERROR-TOKEN
}
Adams, et al. Expires February 19, 2007 [Page 56]
Internet-Draft SPKM-3 August 2006
ERROR-TOKEN ::= SEQUENCE {
tok-id INTEGER(1024), -- shall contain 0400 (hex)
context-id Random-Integer
}
SPKM-MIC ::= SEQUENCE {
mic-header Mic-Header,
int-cksum BIT STRING,
...
}
Mic-Header ::= SEQUENCE {
tok-id INTEGER(257), -- shall contain 0101 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL,
...
}
SeqNum ::= SEQUENCE {
num INTEGER,
dir-ind BOOLEAN,
...
}
SPKM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body,
...
}
Wrap-Header ::= SEQUENCE {
tok-id INTEGER(513), -- shall contain 0201 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
conf-alg [1] Conf-Alg OPTIONAL,
snd-seq [2] SeqNum OPTIONAL,
...
}
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] NULL,
...
}
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
Adams, et al. Expires February 19, 2007 [Page 57]
Internet-Draft SPKM-3 August 2006
data BIT STRING,
...
}
SPKM-DEL ::= SEQUENCE {
del-header Del-Header,
int-cksum BIT STRING
}
Del-Header ::= 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 ::= OBJECT IDENTIFIER
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken SPKMInnerContextToken
}
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-err [7] SPKM-GSS-ERROR,
...
}
-- from [RFC-1510]
AuthorizationData ::=
SEQUENCE OF SEQUENCE {ad-type INTEGER,
ad-data OCTET STRING}
-- object identifier assignments
md5-DES-CBC OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
integrity(3) md5-DES-CBC(1)}
sum64-DES-CBC OBJECT IDENTIFIER ::=
Adams, et al. Expires February 19, 2007 [Page 58]
Internet-Draft SPKM-3 August 2006
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
integrity(3) sum64-DES-CBC(2)}
spkm-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) spkm(1) spkm-1(1)}
spkm-2 OBJECT IDENTIFIER ::=
{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 gss-error choice of
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 integrity protected.
SPKM3 suggest to deprecate the use of DELETE tokens.
SPKM3 clarifies the use of names. It defines a new name type to
represent distinguished names.
SPKM3 includes an ASN1 module for SPKM3 structures.
SPKM3 must send the 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.
[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
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 February 19, 2007 [Page 63]
Internet-Draft SPKM-3 August 2006
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 February 19, 2007 [Page 64]
Internet-Draft SPKM-3 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 February 19, 2007 [Page 65]
