One document matched: draft-ietf-cat-spkmgss-02.txt
Differences from draft-ietf-cat-spkmgss-01.txt
Internet Draft C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-02.txt March 31, 1995
The Simple Public-Key GSS-API Mechanism (SPKM)
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.
ABSTRACT
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using the Simple Public-Key Mechanism.
BACKGROUND
Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
well-established in many environments, it is important in some
applications to have a GSS-API mechanism which is based on a public-
key, rather than a symmetric-key, infrastructure. One such mechanism
was described as part of the Distributed Authentication Security
Service (DASS) in [RFC-1507]. However, the mechanism described in
this document has been proposed as an alternative to the DASS
mechanism for several reasons.
1) The SPKM is simpler than DASS, containing no non-essential
functionality.
Adams Document Expiration: 30 Sept. 1995 1
2) The SPKM allows both unilateral and mutual authentication
to be accomplished without the use of secure timestamps,
whereas DASS requires timestamps for replay detection. This
enables environments which do not have access to secure time
to nevertheless have access to secure authentication.
3) The SPKM uses Algorithm Identifiers to specify various
algorithms to be used by the communicating peers. This allows
maximum flexibility for a variety of environments, for future
enhancements, and for alternative algorithms.
4) The SPKM allows the option of a true, asymmetric algorithm-
based, digital signature in the gss_sign() and gss_seal()
operations (now called gss_getMIC() and gss_wrap() in [GSSv2],
whereas DASS uses an integrity checksum based on a MAC
computed with a symmetric algorithm (DES). For some
environments, the availability of true digital signatures
supporting non-repudiation is a necessity.
5) SPKM data formats and procedures are designed to be as similar
to those for the Kerberos mechanism as is practical. This is
done for ease of implementation in those environments where
Kerberos has already been implemented.
For the above reasons, it is felt that the SPKM will offer greater
flexibility and functionality than DASS, without undue complexity or
overhead.
KEY MANAGEMENT
The key management employed in SPKM is intended to be as compatible
as possible with both X.509 [X.509] and PEM [RFC-1422], since these
represent large communities of interest and show relative maturity in
standards.
ACKNOWLEDGMENTS
Much of the material in this document is based on the Kerberos
Version 5 GSS-API mechanism [KRB5], and is intended to be as
compatible with it as possible. This document also owes a great debt
to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
many fruitful discussions, to Kelvin Desplanque of Domus Software
for implementation-related clarifications, and to John Linn of
OpenVision Technologies for helpful comments.
Adams Document Expiration: 30 Sept. 1995 2
1. OVERVIEW
The goal of the Generic Security Service Application Program
Interface (GSS-API) is stated in the abstract of [RFC-1508] as
follows:
"This Generic Security Service Application Program Interface (GSS-
API) definition provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments. This specification defines
GSS-API services and primitives at a level independent of
underlying mechanism and programming language environment, and is
to be complemented by other, related specifications:
- documents defining specific parameter bindings for particular
language environments;
- documents defining token formats, protocols, and procedures to
be implemented in order to realize GSS-API services atop
particular security mechanisms."
The SPKM is an instance of the latter type of document and is
therefore termed a "GSS-API Mechanism". This mechanism provides
authentication, key establishment, data integrity, and data
confidentiality in an on-line distributed application environment
using a public-key infrastructure. Because it conforms to the
interface defined by [RFC-1508], SPKM can be used as a drop-in
replacement by any application which makes use of security services
through GSS-API calls (for example, any application which already
uses the Kerberos GSS-API for security). The use of a public-key
infrastructure allows digital signatures supporting non-repudiation
to be employed for message exchanges, and provides other benefits
such as scalability to large user populations.
The tokens defined in SPKM are intended to be used by application
programs according to the GSS API "operational paradigm" (see
[RFC-1508] for further details):
The operational paradigm in which GSS-API operates is as follows.
A typical GSS-API caller is itself a communications protocol [or
is an application program which uses a communications protocol],
calling on GSS-API in order to protect its communications with
authentication, integrity, and/or confidentiality security
services. A GSS-API caller accepts tokens provided to it by its
local GSS-API implementation [i.e., its GSS-API mechanism] and
transfers the tokens to a peer on a remote system; that peer
passes the received tokens to its local GSS-API implementation for
processing.
This document defines two separate GSS-API mechanisms, SPKM-1 and
SPKM-2, which are identical except that SPKM-2 requires the presence
of secure timestamps for the purpose of replay detection during
context establishment and SPKM-1 does not. This allows greater
flexibility for applications since secure timestamps cannot always
be guaranteed to be available in a given environment.
Adams Document Expiration: 30 Sept. 1995 3
2. ALGORITHMS
A number of algorithm types are employed in SPKM. Each type, along
with its purpose and a set of specific examples, is described in this
section. In order to ensure at least a minimum level of
interoperability among various implementations of SPKM, one of the
integrity algorithms is specified as MANDATORY; all remaining
examples (and any other algorithms) may optionally be supported by a
given SPKM implementation (note that a GSS-conformant 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 implementations for which exportability is not a
concern).
2.1 Integrity Algorithm (I-ALG):
Purpose:
This algorithm is used to ensure that a message has not been
altered in any way after being constructed by the legitimate
sender. Depending on the algorithm used, the application of
this algorithm may also provide authenticity and support non-
repudiation for the message.
Examples:
md5WithRSA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 3
}
This algorithm (MANDATORY) provides data integrity and
supports non-repudiation by computing an RSA signature on
the MD5 hash of that data. Note that this is equivalent to
md5WithRSAEncryption {1 2 840 113549 1 1 4}, which is
defined in [PKCS1].
DES-MAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 10
}
This algorithm (RECOMMENDED) provides data integrity by
computing a DES MAC (as specified by [FIPS-113]) on that
data.
Adams Document Expiration: 30 Sept. 1995 4
md5-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) xx
}
This algorithm provides data integrity by encrypting, using
DES CBC, the MD5 hash of that data. This will typically be
faster in practice than computing a DES MAC unless the input
data is extremely short (e.g., a few bytes). Note that the
strength of this integrity mechanism is (at most) equal to
the strength of DES under a known-plaintext attack.
sum64-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) xx
}
This algorithm provides data integrity by encrypting, using
DES CBC, the concatenation of the data and the sum of all
the input data blocks (the sum computed using addition
modulo 2**64 - 1). Thus, in this algorithm, encryption is a
requirement for the integrity to be secure.
For comments regarding the security of this integrity
algorithm, see [Juen84, Davi89].
2.2 Confidentiality Algorithm (C-ALG):
Purpose:
This symmetric algorithm is used to generate the encrypted
data for gss_seal() / gss_wrap().
Example:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV (encoded as an
} -- OCTET STRING) as a parameter
This algorithm is RECOMMENDED.
Adams Document Expiration: 30 Sept. 1995 5
2.3 Key Establishment Algorithm (K-ALG):
Purpose:
This algorithm is used to establish a symmetric key for use
by both the initiator and the target over the established
context. The keys used for C-ALG and any keyed I-ALGs (for
example, DES-MAC) are derived from this context key. As will
be seen in Section 3.1, key establishment is done within the
X.509 authentication exchange and so the resulting shared
symmetric key is authenticated.
Example:
id-rsa-key-transport OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 22 -- imported from [X9.44]
}
In this algorithm (MANDATORY), the context key is generated
by the initiator, encrypted with the RSA public key of the
target, and sent to the target. The target need not respond
to the initiator for the key to be established.
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
In this algorithm, the context key is generated jointly by
the initiator and the target using the Diffie-Hellman key
establishment algorithm. The target must therefore respond
to the initiator for the key to be established (so this
K-ALG cannot be used with unilateral authentication in
SPKM-2 (see Section 3.1)).
During context establishment in SPKM, the initiator offers a set of
possible 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
the default algorithms for that context.
Adams Document Expiration: 30 Sept. 1995 6
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 5.2 for further details. If no response is expected from the
target (unilateral authentication in SPKM-2) then the algorithms
offered by the initiator are the ones that may be used over the
context (if this is unacceptable to the target then a delete token
must be sent to the initiator so that the context is never
established).
Furthermore, in the first context establishment token the initiator
offers a set of possible K-ALGs, along with the key (or key half)
corresponding to the first algorithm in the set (its preferred
algorithm). If this K-ALG is unacceptable to the target then the
target must choose one of the other K-ALGs in the set and send this
choice along with the key (or key half) corresponding to this choice
in its response (otherwise a delete token must be sent so that the
context is never established). If necessary (that is, if the target
chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will
send its key half in a response to the target.
In future versions of SPKM, other algorithms may be specified for any
or all of I-ALG, C-ALG, and K-ALG.
3. TOKEN FORMATS
This section discusses protocol-visible characteristics of the SPKM;
it defines elements of protocol for interoperability and is
independent of language bindings per [RFC-1509].
The SPKM GSS-API mechanism will be identified by an Object Identifier
representing "SPKM-1" or "SPKM-2", having the value:
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)}
or
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)},
where SPKM-1 uses random numbers for replay detection during context
establishment and SPKM-2 uses timestamps (note that for both
mechanisms, sequence numbers are used to provide replay and out-of-
sequence detection during the context, if this has been requested by
the application).
Tokens transferred between GSS-API peers (for security context
management and per-message protection purposes) are defined.
3.1. Context Establishment Tokens
Three classes of tokens are defined in this section: "Initiator"
tokens, emitted by calls to gss_init_sec_context() and consumed by
calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
to gss_accept_sec_context() and consumed by calls to
gss_init_sec_context(); and "Error" tokens, potentially emitted by
calls to gss_init_sec_context() and gss_accept_sec_context(),
and potentially consumed by calls to gss_init_sec_context() and
gss_accept_sec_context().
Adams Document Expiration: 30 Sept. 1995 7
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "SPKM-1" or "SPKM-2"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
}
The above GSS-API framing shall be applied to all tokens emitted by
the SPKM GSS-API mechanism, including SPKM_REP_TI (the response from
the Target to the Initiator), SPKM_REP_IT (the response from the
Initiator to the Target), SPKM_ERROR, context-deletion, and
per-message tokens, not just to the initial token in a context
establishment sequence. While not required by RFC-1508, this enables
implementations to perform enhanced error-checking. Furthermore,
every innerContextToken will contain a token-id followed by a
context-id. See Section 6 for a discussion of these two fields and
their use in an SPKM support function.
The innerContextToken field of context establishment tokens for the
SPKM GSS-API mechanism will consist of a message (SPKM_REQ,
SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing a tok_id field
having the value 0100 (hex) for SPKM_REQ messages, 0200 (hex) for
SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT messages, and 0400
(hex) for SPKM_ERROR messages. All innerContextTokens are encoded
using Abstract Syntax Notation One Basic Encoding Rules (ASN.1 BER).
The SPKM context establishment tokens are defined according to
[X.509] Section 10. SPKM-1 (random numbers) uses Section 10.3, "Two-
way Authentication", when performing unilateral authentication of the
target to the initiator and uses Section 10.4, "Three-way Authentica-
tion", when mutual authentication is requested by the initiator.
SPKM-2 (timestamps) uses Section 10.2, "One-way Authentication", when
performing unilateral authentication of the initiator to the target
and uses Section 10.3, "Two-way Authentication", when mutual authen-
tication is requested by the initiator.
The implication of the above paragraph is that for SPKM-2 unilateral
authentication no negotiation of K-ALG can be done (the target either
accepts the K-ALG and key given by the initiator or disallows the
context). For SPKM-2 mutual or SPKM-1 unilateral authentication some
negotiation is possible, but the target can only choose among the
one-pass K-ALGs offered by the initiator (or disallow the context).
Furthermore, the initiator can request that the target generate and
transmit the context key. For SPKM-1 mutual authentication the
target can choose any one- or two-pass K-ALG offered by the initiator
and, again, can be requested to generate and transmit the key.
It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
mutual authentication. Although unilateral authentication is avail-
able for both mechanisms, its use is not generally recommended.
Adams Document Expiration: 30 Sept. 1995 8
3.1.1. Context Establishment Tokens - Initiator (first token)
In order to accomplish context establishment, it may be necessary
that both the initiator and the target have access to the other
party?s public-key certificate(s). In some environments the
initiator may choose to acquire all certificates and send the
relevant ones to the target in the first token. In other environ-
ments the initiator may request that the target send certificate data
in its response token, or each side may individually obtain the
certificate data it needs. In any case, however, the SPKM
implementation must have the ability to obtain certificates which
correspond to a supplied Name. The actual mechanism to be used to
achieve this is a local implementation matter and is therefore
outside the scope of this specification.
Relevant SPKM_REQ syntax is as follows (note that imports from other
documents are given in Appendix A):
SPKM_REQ ::= SEQUENCE {
requestToken [0] REQ_TOKEN
certif_data [1] CertificationData OPTIONAL
auth_data [2] AuthorizationData OPTIONAL
-- see [RFC-1510] for a discussion of auth-data
}
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath OPTIONAL
certificateRevocationList [1] CertificateList OPTIONAL
} -- at least one of the above shall be present
CertificationPath ::= SEQUENCE {
enc_Key_id [0] OCTET STRING OPTIONAL
-- identifier for user's public encryption key
userEncCertif [1] SingleCertificate OPTIONAL
-- certificate containing user's public encryption key
verif_Key_id [2] OCTET STRING OPTIONAL
-- identifier for user's public verification key
userVerifCertif [3] SingleCertificate OPTIONAL
-- certificate containing user's public verification key
-- (may have separate verification certificate to allow
-- different algs to be used for decryption and signing)
theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
-- certification path from target to source
} -- at least one of the above shall be present
SingleCertificate ::= CHOICE { -- only one for now
Certificate -- imported from [X.509] (1993)
}
Adams Document Expiration: 30 Sept. 1995 9
REQ_TOKEN ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0100 (hex)
context_id [1] Random_Integer
pvno[2] BIT STRING, -- protocol version number
timestamp [3] UTCTime -- may be NULL for mechanism SPKM-1
randSrc [4] Random_Integer,
targ_name [5] Name,
src_name [6] Name,
req_data [7] Context_Data,
validity [8] Validity OPTIONAL
-- validity interval for key (may be used in the
-- computation of security context lifetime)
key_estb_set [9] Key_Estb_Alg
-- specifies set of key establishment algorithms
key_estb_req [10] BIT STRING OPTIONAL
-- key estb. parameter corresponding to first K-ALG in set
-- (not used if initiator is unable or unwilling to
-- generate and securely transmit key material to target).
-- Established key must be sufficiently long to be used
-- with any of the offered confidentiality algorithms.
}
-- The protocol version number (pvno) parameter is a BIT STRING which
-- uses as many bits as necessary to specify all the SPKM 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. Note that for unilateral authentication
-- using SPKM-2, no response token is expected during context
-- establishment, so no protocol negotiation can take place. In this
-- case, the initiator must set exactly one bit of pvno.
-- The "validity" parameter above is the only way within SPKM 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).
Random_Integer ::= BIT STRING
-- Each SPKM 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.
-- Note that there are no cryptographic requirements on this random
-- number (i.e., it need not be unpredictable, it simply needs to be
-- fresh).
Context_Data ::= SEQUENCE {
channelId [0] ChannelId, -- channel bindings
seq_number [1] INTEGER OPTIONAL -- sequence number
options [2] Options
conf_alg [3] Conf_Alg -- confidentiality. alg.
intg_alg [4] Intg_Alg -- integrity algorithm
}
Adams Document Expiration: 30 Sept. 1995 10
ChannelId ::= OCTET STRING
Options ::= BIT STRING {
delegation_state (0),
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 targ's certif. data
}
Conf_Alg ::= SEQUENCE OF AlgorithmIdentifier -- for C-ALG
-- (see Section 5.2 for
-- discussion of QOP)
Intg_Alg ::= SEQUENCE OF AlgorithmIdentifier -- for I-ALG
-- (see Section 5.2 for
-- discussion of QOP)
Key_Estb_Alg ::= SEQUENCE OF AlgorithmIdentifier
-- to allow negotiation
-- of K-ALG
A context establishment sequence based on the SPKM will perform
unilateral authentication if the mutual_req bit is not set in the
application's call to gss_init_sec_context(). SPKM-2 accomplishes
this using only SPKM_REQ (thereby authenticating the initiator to the
target), while SPKM-1 accomplishes this using both SPKM_REQ and
SPKM_REP_TI (thereby authenticating the target to the initiator).
Applications requiring authentication of both peers (initiator as
well as target) should request mutual authentication, resulting in
"mutual_state" being set within SPKM_REQ Options. In response to
such a request, the context target will reply to the initiator with a
token containing either an SPKM_REP_TI or SPKM_ERROR / SPKM_DEL. If
mechanism SPKM-2 has been chosen, this completes the (timestamp-
based) mutual authentication context establishment exchange. If
mechanism SPKM-1 has been chosen and SPKM_REP_TI is sent, the
initiator will then reply to the target with either an SPKM_REP_IT or
SPKM_DEL, completing the (random-number-based) mutual authentication
context establishment exchange.
Other bits in the Options field of Context_Data are explained in
RFC-1508, with the exception of target_certif_data_required, which
the initiator sets to TRUE to request that the target return its
certification data in the SPKM_REP_TI token. For unilateral
authentication in SPKM-2 (in which no SPKM_REP_TI token is
constructed), this option bit is ignored by both initiator and
target.
Adams Document Expiration: 30 Sept. 1995 11
3.1.2. Context Establishment Tokens - Target
Relevant SPKM_REP_TI syntax is as follows:
SPKM_REP_TI ::= SEQUENCE {
responseToken [0] REP_TOKEN
certif_data [1] CertificationData OPTIONAL
-- included if target_certif_data_required option was
-- set to TRUE in SPKM_REQ
}
REP_TOKEN ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0200 (hex)
context_id [1] Random_Integer
pvno[2] BIT STRING OPTIONAL, -- prot. version number
timestamp [3] UTCTime -- may be NULL for
-- mechanism SPKM-1
randTarg [4] Random_Integer,
src_name [5] Name,
randSrc [6] Random_Integer,
rep_data [7] Context_Data,
key_estb_id [8] AlgorithmIdentifier OPTIONAL
-- used if target is changing key estb. algorithm
-- (must be a member of initiator?s key_estb_set)
key_estb_str [9] BIT STRING OPTIONAL
-- contains (1) the response to the initiator?s
-- 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 the
-- 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 be sufficiently long to be
-- used with any of the offered conf. algorithms.
}
-- 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 delete 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_TOKEN can be omitted.
Adams Document Expiration: 30 Sept. 1995 12
3.1.3. Context Establishment Tokens - Initiator (second token)
Relevant SPKM_REP_IT syntax is as follows:
SPKM_REP_IT ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0300 (hex)
context_id [1] Random_Integer
randTarg [2] Random_Integer,
targ_name [3] Name,
key_estb_rep [4] BIT STRING OPTIONAL
-- contains the response to target?s key_estb_str
-- (if target selected a 2-pass K-ALG)
}
3.1.4. Error Token
The syntax of SPKM_ERROR is as follows:
SPKM_ERROR ::= SIGNED SEQUENCE {
tok_id [0] INTEGER, -- shall contain 0400 (hex)
context_id [1] Random_Integer
}
The SPKM_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_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. The output token will
not be an SPKM_ERROR token but will instead be an SPKM_DEL token
which will be processed by the peer's gss_process_context_token().
If gss_init_sec_context() receives an error token (whether valid or
invalid), 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), it will regenerate SPKM_REP_TI as its
output token and return a major status code of GSS_S_CONTINUE_NEEDED.
Adams Document Expiration: 30 Sept. 1995 13
3.2. Per-Message and Context Deletion 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(); and context deletion tokens,
emitted by calls to gss_init_sec_context(), gss_accept_sec_context(),
or gss_delete_sec_context() and consumed by calls to
gss_process_context_token().
3.2.1. Per-message Tokens - Sign / MIC
Use of the gss_sign() / 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 [0] Mic_Header,
mic_body [1] Mic_Body
}
Mic_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0101 (hex)
context_id [1] Random_Integer
int_alg [2] AlgorithmIdentifier OPTIONAL,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
snd_seq [3] INTEGER OPTIONAL,
-- sequence number.
}
Mic_Body ::= SEQUENCE {
int_cksum [0] BIT STRING
-- Checksum over header and data,
-- calculated according to algorithm
-- specified in int_alg field.
}
Adams Document Expiration: 30 Sept. 1995 14
3.2.1.1. Checksum
Checksum calculation procedure (common to all algorithms -- note that
for SPKM 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 md5WithRSA algorithm, then
the checksum is formed by computing an MD5 [RFC-1321] hash over the
plaintext data (prepended by the header), and then computing an RSA
signature [PKCS1] on the 16-byte MD5 result. The signature is
computed using the RSA private key retrieved from the credentials
structure and the result (whose length is implied by the "modulus"
parameter in the private key) is stored in the int_cksum field.
If the int_alg specifies a keyed hashing algorithm (for example,
DES-MAC or md5-DES-CBC), then the key to be used is the established
context key. Again, the result (whose length is implied by int_alg)
is stored in the int_cksum field.
3.2.1.2. Sequence Number
It is assumed that the underlying transport layers (of whatever pro-
tocol stack is being used by the application) will provide adequate
communications reliability (that is, non-malicious loss, re-ordering,
etc., of data packets will be handled correctly). Therefore,
sequence numbers are used in SPKM purely for security, as opposed to
reliability, reasons (that is, to avoid malicious loss, replay, or
re-ordering of SPKM tokens) -- 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
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 by appending a one-byte direction-
indicator (Hex 00 - sender is the context initiator, Hex FF - sender
is the context acceptor) to the sequence number. After constructing
a gss_sign() or gss_seal() (gss_getMIC() or gss_wrap()) token, the
sender's sequence number is incremented by one.
3.2.1.3. Sequence Number Processing
The receiver of the token will verify the sequence number field by
comparing it with the expected sequence number. 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 or GSS_S_OLD_TOKEN is returned, whichever is
appropriate.
Adams Document Expiration: 30 Sept. 1995 15
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.
3.2.2. Per-message Tokens - Seal / Wrap
Use of the gss_seal() / 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_seal() / 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 key specified in 3.2.2.4 with one
of the agreed C-ALGs for this context).
The SPKM_WRAP token has the following format:
SPKM_WRAP ::= SEQUENCE {
wrap_header [0] Wrap_Header,
wrap_body [1] Wrap_Body
}
Wrap_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0201 (hex)
context_id [1] Random_Integer
int_alg [2] AlgorithmIdentifier OPTIONAL,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
conf_alg [4] 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 [5] INTEGER OPTIONAL,
-- sequence number.
}
Wrap_Body ::= SEQUENCE {
int_cksum [0] BIT STRING
-- Checksum of header and data,
-- calculated according to algorithm
-- specified in int_alg field.
data [1] BIT STRING
-- encrypted or plaintext data.
}
Conf_Alg ::= CHOICE {
AlgorithmIdentifier,
NULL
}
Adams Document Expiration: 30 Sept. 1995 16
3.2.2.1: Confounding
As in [KRB5], an 8-byte random confounder is prepended to the data to
compensate for the fact that an IV of zero is used for encryption.
The result is referred to as the "confounded" data field.
3.2.2.2. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the plaintext data field, logically prepended by
the bytes of the plaintext token header (wrap_header). As with
gss_sign() / 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
3.2.1.1.
If int_alg specifies md5-DES-CBC and conf_alg specifies anything
other than DES-CBC, then the checksum is computed according to
3.2.1.1 and the result is stored in int_cksum. However, if conf_alg
specifies DES-CBC then the encryption and the integrity is done
as follows. An MD5 [RFC-1321] hash is computed over the plaintext
data (prepended by the header). This 16-byte value is appended to
the concatenation of the "confounded" data and 1-8 padding bytes (the
padding is as specified in [KRB5] for DES-CBC). The result is
then CBC encrypted using the context key and placed in the "data"
field of 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 will return an error). Encryption and integrity are done in
a single pass using the context key as follows. The sum (modulo
2**64 - 1) of all plaintext data blocks (prepended by the header) is
computed. This 8-byte value is appended to the concatenation of the
"confounded" data and 1-8 padding bytes (the padding is as specified
in [KRB5] for DES-CBC). As above, the result is then CBC encrypted
and placed in the "data" field of 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.
3.2.2.3 Sequence Number
Sequence numbers are computed and processed for gss_wrap() exactly
as specified in 3.2.1.2 and 3.2.1.3.
3.2.2.4: Data Encryption
The following procedure is followed unless (a) conf_alg is NULL (no
encryption), or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC
(encryption as specified in 3.2.2.2), or (c) int_alg is sum64-DES-CBC
(encryption as specified in 3.2.2.2):
Adams Document Expiration: 30 Sept. 1995 17
The "confounded" data is padded and encrypted according to the
algorithm specified in the conf_alg field. The data is encrypted
using CBC with an IV of zero. The key used is derived from the
established context key by XOR-ing the context key with the hexadeci-
mal constant F0F0F0...F0 (this ensures that the key used for encryp-
tion and the key used for a separate, keyed integrity algorithm --
for example DES-MAC, but not sum64-DES-CBC -- are different).
3.2.3. Context deletion token
The token emitted by gss_delete_sec_context() is based on the format
for tokens emitted by gss_sign() / gss_getMIC().
The SPKM_DEL token has the following format:
SPKM_DEL ::= SEQUENCE {
del_header [0] Del_Header,
del_body [1] Del_Body
}
Del_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0301 (hex)
context_id [1] Random_Integer
int_alg [2] AlgorithmIdentifier OPTIONAL,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
snd_seq [4] INTEGER OPTIONAL,
-- sequence number.
}
Del_Body ::= SEQUENCE {
int_cksum [0] BIT STRING
-- Checksum of header, calculated
-- according to algorithm specified
-- in int_alg field.
}
The field snd_seq will be calculated as for tokens emitted by
gss_sign() / gss_getMIC(). The field int_cksum will be calculated as
for tokens emitted by gss_sign() / gss_getMIC(), except that the
user-data component of the checksum data will be a zero-length
string.
Adams Document Expiration: 30 Sept. 1995 18
If a valid delete token is received, then the SPKM implementation
will delete the context and gss_process_context_token() will return a
major status of GSS_S_COMPLETE and a minor status of
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).
4. NAME TYPES AND OBJECT IDENTIFIERS
No mandatory name forms have yet been defined for SPKM. This section
is for further study.
4.1. Optional Name Forms
This section discusses name forms which may optionally be supported
by implementations of the SPKM GSS-API mechanism. It is recognized
that OS-specific functions outside GSS-API are likely to exist in
order to perform translations among these forms, and that GSS-API
implementations supporting these forms may themselves be layered atop
such OS-specific functions. Inclusion of this support within GSS-API
implementations is intended as a convenience to applications.
4.1.1. User Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) user_name(1)}. The recommended symbolic name for this
type is "GSS_SPKM_NT_USER_NAME".
This name type is used to indicate a named user on a local system.
Its interpretation is OS-specific. This name form is constructed as:
username
4.1.2. Machine UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) machine_uid_name(2)}. The recommended symbolic name for
this type is "GSS_SPKM_NT_MACHINE_UID_NAME".
This name type is used to indicate a numeric user identifier
corresponding to a user on a local system. Its interpretation is
OS-specific. The gss_buffer_desc representing a name of this type
should contain a locally-significant uid_t, represented in host byte
order. The gss_import_name() operation resolves this uid into a
username, which is then treated as the User Name Form.
Adams Document Expiration: 30 Sept. 1995 19
4.1.3. String UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) string_uid_name(3)}. The recommended symbolic name for
this type is "GSS_SPKM_NT_STRING_UID_NAME".
This name type is used to indicate a string of digits representing
the numeric user identifier of a user on a local system. Its
interpretation is OS-specific. This name type is similar to the
Machine UID Form, except that the buffer contains a string
representing the uid_t.
5. PARAMETER DEFINITIONS
This section defines parameter values used by the SPKM GSS-API
mechanism. It defines interface elements in support of portability.
5.1. Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the SPKM GSS-API mechanism. Use of these
definitions will enable independent implementors to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of gss_display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation 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.
5.1.1. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET)
5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET)
GSS_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_S_G_UNAVAIL_QOP
/* "Unavailable quality of protection specified" */
5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF)
GSS_S_G_MEMORY_ALLOC
/* "Couldn't perform requested memory allocation" */
Adams Document Expiration: 30 Sept. 1995 20
5.1.2. SPKM-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_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" */
5.2. Quality of Protection Values
The Quality of Protection (QOP) parameter is used in the SPKM GSS-API
mechanism as input to gss_sign() and gss_seal() (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.
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.
Adams Document Expiration: 30 Sept. 1995 21
If the SPKM_REP_TI token is not used (unilateral authentication using
SPKM-2), then the "agreed" sets of Alg. IDs are simply taken to be
the initiator's sets (if this is unacceptable to the target then it
must return an error token so that the context is never established).
Note that, in the interest of interoperability, the initiator is not
required to offer every algorithm it supports; rather, it may offer
only the mandated/recommended SPKM algorithms since these are likely
to be supported by the target.
The QOP parameter for SPKM 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-
specified algorithm corresponding to that integer value (if this
algorithm is available over the established context). Note that use
of this field may hinder portability since a particular value may
specify one algorithm in one implementation of the mechanism and may
not be supported or may specify a completely different algorithm in
another implementation of the mechanism.
Finally, if both MA and IA are zero then TS is examined. A value of
zero for TS specifies the default algorithm for the established
context, which is defined to be the first algorithm on the
initiator's list of offered algorithms (confidentiality or integrity,
depending on which half of QOP is being examined) which is supported
over the context. A non-zero value for TS corresponds to a
particular algorithm qualifier and selects the first algorithm
supported over the context which satisfies that qualifier.
Adams Document Expiration: 30 Sept. 1995 22
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_REPUDIABLE
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
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. For example, all
implementations of the Kerberos V5 GSS mechanism must support
GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
(Note that these Kerberos-specified integrity QOP values do not
conflict with the QOP structure defined above.)
Adams Document Expiration: 30 Sept. 1995 23
- 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
triple-DES has been specified by a mechanism as algorithm 8, then
a receiver of a triple-DES-protected token must pass to its
application (QOP Confidentiality TS=1, IA=0, MA=8). In this way,
the application is free to read whatever part of the QOP it
understands (TS or IA/MA).
To aid in implementation and interoperability, the following
stipulation is made. The set of integrity Alg. IDs sent by the
initiator must contain at least one specifying an algorithm which
computes a digital signature supporting non-repudiation, and must
contain at least one specifying any other (repudiable) integrity
algorithm. The subset of integrity Alg. IDs returned by the target
must also contain at least one specifying an algorithm which computes
a digital signature supporting non-repudiation, and at least one
specifying a repudiable integrity algorithm.
The reason for this stipulation is to ensure that every SPKM
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).
Finally, in accordance with the MANDATORY and RECOMMENDED algorithms
given in Section 2, the following QOP values are specified for SPKM.
For the Confidentiality MA field:
0001 (1) = DES-CBC
For the Integrity MA field:
0001 (1) = md5WithRSA
0010 (2) = DES-MAC
6. SUPPORT FUNCTIONS
This section describes a mandatory support function for SPKM-
conformant implementations which may, in fact, be of value in all
GSS-API mechanisms. It makes use of the token_id and context_id
fields which are included in SPKM context-establishment, error,
context-deletion, and per-message tokens. The function is defined
in the following section.
Adams Document Expiration: 30 Sept. 1995 24
6.1. SPKM_Parse_token call
Inputs:
o input_token OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o mech_type OBJECT IDENTIFIER,
o token_type INTEGER,
o context_handle CONTEXT HANDLE,
Return major_status codes:
o GSS_S_COMPLETE indicates that the input_token could be parsed for
all relevant fields. The resulting values are stored in
mech_type, token_type and context_handle, respectively (with NULLs
in any parameters which are not relevant).
o GSS_S_DEFECTIVE_TOKEN indicates that either the token_id or the
context_id (if one was expected) could not be parsed. A non-NULL
return value in token_type indicates that the latter situation
occurred.
o GSS_S_NO_TYPE indicates that the token_id could be parsed, but it
did not correspond to any valid token_type.
(Note that this major status code has not been defined for GSS in
RFC-1508. Until such a definition is made (if ever), SPKM
implementations should instead return GSS_S_DEFECTIVE_TOKEN with
both token_type and context_handle set to NULL. This essentially
implies that an unrecognized token_id is considered to be
equivalent to a field which could not be parsed.)
o GSS_S_NO_CONTEXT indicates that the context_id could be parsed,
but it did not correspond to any valid context_handle.
o GSS_S_FAILURE indicates that the mechanism type could not be
parsed (for example, the token may be corrupted).
SPKM_Parse_token() is used to return to an application the mechanism
type, token type, and context handle which correspond to a given
input token. Since GSS-API tokens are meant to be opaque to the
calling application, this function allows the application to
determine information about the token without having to violate the
opaqueness intention of GSS. Of primary importance is the token
type, which the application can then use to decide which GSS function
to call in order to have the token processed.
Adams Document Expiration: 30 Sept. 1995 25
If all tokens are framed as suggested in RFC-1508, Appendix B
(specified both in the Kerberos V5 GSS mechanism [KRB5] and in this
document), then any mechanism implementation should be able to return
at least the mech_type parameter (the other parameters being NULL)
for any uncorrupted input token. If the mechanism implementation
whose SPKM_Parse_token() function is being called does recognize the
token, it can return token_type so that the application can
subsequently call the correct GSS function. Finally, if the
mechanism provides a context_id field in its tokens (as SPKM does),
then an implementation can map the context_id to a context_handle and
return this to the application. This is necessary for the situation
where an application has multiple contexts open simultaneously, all
using the same mechanism. When an incoming token arrives, the
application can use this function to determine not only which GSS
function to call, but also which context_handle to use for the call.
Note that this function is mandatory for SPKM-conformant
implementations, but it is optional for applications. That is, if
an application has only one context open and can guess which GSS
function to call (or is willing to put up with a few error codes),
then it need never call SPKM_Parse_token(). Furthermore, if this
function ever migrates up to the GSS-API level, then
SPKM_Parse_token() will be deprecated at that time in favour of
GSS_Parse_token(), or whatever the new name might be. Note finally
that no minor status return codes have been defined for this function
at this time.
6.2. The token_type Output Parameter
The following token types are defined:
GSS_INIT_TOKEN = 1
GSS_ACCEPT_TOKEN = 2
GSS_ERROR_TOKEN = 3
GSS_SIGN_TOKEN = GSS_GETMIC_TOKEN = 4
GSS_SEAL_TOKEN = GSS_WRAP_TOKEN = 5
GSS_DELETE_TOKEN = 6
All mechanisms will be able to perform the mapping from the token_id
which is included in every token to one of the above token types.
Applications should be able to decide, on the basis of token_type,
which GSS function to call (note that an error token may be input to
gss_init_sec_context(), gss_accept_sec_context(), or
gss_process_context_token, depending upon where the application is in
the context establishment process).
Adams Document Expiration: 30 Sept. 1995 26
6.3. The context_handle Output Parameter
The SPKM 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
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 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-2), 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 two peers). Such
assurance is not available to the target in the case of unilateral
authentication using SPKM-2, 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).
7. SECURITY CONSIDERATIONS
Security issues are discussed throughout this memo.
Adams Document Expiration: 30 Sept. 1995 27
8. REFERENCES
[Davi89]: D. W. Davies and W. L. Price, "Security for Computer
Networks", Second Edition, John Wiley and Sons, New York, 1989.
[FIPS-113]: National Bureau of Standards, Federal Information
Processing Standard 113, "Computer Data Authentication", May 1985.
[GSSv2]: J. Linn, "Generic Security Service Application Program
Interface Version 2", Internat Draft: draft-ietf-cat-gssv2-00.txt.
[Juen84]: R. R. Jueneman, C. H. Meyer and S. M. Matyas, ~Message
Authentication with Manipulation Detection Codes?, in Proceedings of
the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
Society Press, 1984, pp.33-54..
[KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
Internet Draft draft-ietf-cat-kerb5gss-01.
[PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security,
Inc., Nov. 1993.
[PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
Data Security, Inc., Nov. 1993.
[RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.
[RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC 1422.
[RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security
Service", RFC 1507.
[RFC-1508]: J. Linn, "Generic Security Service Application Program
Interface", RFC 1508.
[RFC-1509]: J. Wray, "Generic Security Service Application Program
Interface: C-bindings", RFC 1509.
[RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510.
[X.501]: ISO/IEC 9594-2, "Information Technology - Open Systems
Interconnection - The Directory: Models", CCITT/ITU Recommendation
X.501, 1993.
[X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication Framework",
CCITT/ITU Recommendation X.509, 1993.
[X9.44]: ANSI, "Public Key Cryptography Using Reversible
Algorithms for the Financial Services Industry: Transport of
Symmetric Algorithm Keys Using RSA", X9.44-1993.
Adams Document Expiration: 30 Sept. 1995 28
9. AUTHOR'S ADDRESS
Carlisle Adams
Bell-Northern Research
P.O.Box 3511, Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613.763.9008
E-mail: cadams@bnr.ca
Appendix: IMPORTS
A.1 ASN.1 encoding
The following definitions are taken from X.501 and X.509.
--CCITT Definitions:
joint-iso-ccitt OBJECT IDENTIFIER ::= {2}
ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
algorithm OBJECT IDENTIFIER ::= {ds 8}
encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}
hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2}
signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}
rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}
iso OBJECT IDENTIFIER ::= {1}
identified-organization OBJECT IDENTIFIER ::= {iso 3}
--1989 Open Systems Environment Implementors' Workshop (OIW)
--"Stable" Agreements
oiw OBJECT IDENTIFIER ::= {identified-organization 14}
dssig OBJECT IDENTIFIER ::= {oiw 7}
oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2}
oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3}
--PKCS #1 definition [PKCS1]
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1
}
Adams Document Expiration: 30 Sept. 1995 29
--PKCS #3 definition [PKCS3]
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
-- the parameter to be used with this algorithm is
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}
--X.501 definitions
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence
Name ::= CHOICE { --only one for now
DistinguishedName
}
--X.509 definitions (with proposed 1992 extensions presumed)
ENCRYPTED MACRO ::=
BEGIN
TYPE NOTATION ::= type(ToBeEnciphered)
VALUE NOTATION ::= value(VALUE BIT STRING)
END -- of ENCRYPTED
SIGNED MACRO ::=
BEGIN
TYPE NOTATION ::= type (ToBeSigned)
VALUE NOTATION ::= value (VALUE
SEQUENCE{
ToBeSigned,
AlgorithmIdentifier, --of the algorithm used to
--generate the signature
ENCRYPTED OCTET STRING --where the octet string is the
--result of the hashing of the
--value of "ToBeSigned"
}
)
END -- of SIGNED
Adams Document Expiration: 30 Sept. 1995 30
SIGNATURE MACRO ::=
BEGIN
TYPE NOTATION ::= type (OfSignature)
VALUE NOTATION ::= value (VALUE
SEQUENCE {
AlgorithmIdentifier, -- of the algorithm used to compute
ENCRYPTED OCTET STRING -- the signature where the octet
-- string is a function (e.g., a
-- compressed or hashed version)
-- of the value 'OfSignature',
-- which may include the
-- identifier of the algorithm
-- used to compute the signature
}
)
END -- of SIGNATURE
Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber [1] CertificateSerialNumber,
signature [2] AlgorithmIdentifier,
issuer [3] Name,
validity [4] Validity,
subject [5] Name,
subjectPublicKeyInfo [6] SubjectPublicKeyInfo,
issuerUID [7] IMPLICIT UID OPTIONAL, -- used in v2 only
subjectUID [8] IMPLICIT UID OPTIONAL -- used in v2 only
}
Version ::= INTEGER {v1(0), v2(1)}
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
NotBefore UTCTime,
NotAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
UID ::= BIT STRING
CertificatePair ::= SEQUENCE {
forward [0] SingleCertificate OPTIONAL,
reverse [1] SingleCertificate OPTIONAL
} -- at least one of the pair shall be present
Adams Document Expiration: 30 Sept. 1995 31
CertificateList ::= SIGNED SEQUENCE {
signature [0] AlgorithmIdentifier,
issuer [1] Name,
thisUpdate [2] UTCTime,
nextUpdate [3] UTCTime OPTIONAL,
revokedCertificates [4] SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime
} OPTIONAL
}
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0] INTEGER,
ad-data[1] OCTET STRING
}
-- ad-data This field contains authorization data to be
-- interpreted according to the value of the
-- corresponding ad-type field.
-- ad-type This field specifies the format for the ad-data
-- subfield. All negative values are reserved for
-- local use. Non-negative values are reserved for
-- registered use.
A.2 Encoding Rules
Whenever a structure is to be signed it must always be constructed
the same way. This is particularly important where a signed structure
has to be reconstructed by the recipient before the signature is
verified. The rules listed below are taken from X.509.
- the definite form of length encoding shall be used, encoded in
the minimum number of octets;
- for string types, the constructed form of encoding shall not
be used;
- if the value of a type is its default value, it shall be
absent;
- the components of a Set type shall be encoded in ascending
order of their tag values;
- the components of a Set-of type shall be encoded in ascending
order of their octet values;
- if the value of a Boolean type is true, the encoding shall
have its contents octet set to Hex 'FF';
- unused bits in the final octet of the encoding of a BitString
value, if there are any, shall be set to zero;
- the encoding of a Real type shall be such that bases 8, 10 and
16 shall not be used, and the binary scaling factor shall be
zero.
Adams Document Expiration: 30 Sept. 1995 32
| PAFTECH AB 2003-2026 | 2026-04-23 06:07:07 |