[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 RFC 2025
Internet Draft C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-01.txt October 30, 1994
The Simple Public-Key GSS-API Mechanism (SPKM)
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.
ABSTRACT
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using the Simple Public-Key Mechanism.
BACKGROUND
Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
well-established in many environments, it is important in some
applications to have a GSS-API mechanism which is based on a public-
key, rather than a symmetric-key, infrastructure. One such mechanism
was described as part of the Distributed Authentication Security
Service (DASS) in [RFC-1507]. However, the mechanism described in
this document has been proposed as an alternative to the DASS
mechanism for several reasons.
1) The SPKM is simpler than DASS, containing no non-essential
functionality.
Adams Document Expiration: 30 April 1995 1
2) The SPKM allows both unilateral and mutual authentication
to be accomplished without the use of secure timestamps,
whereas DASS requires timestamps for replay detection. This
enables environments which do not have access to secure time
to nevertheless have access to secure authentication.
3) The SPKM uses Algorithm Identifiers to specify various
algorithms to be used by the communicating peers. This allows
maximum flexibility for a variety of environments, for future
enhancements, and for alternative algorithms.
4) The SPKM allows the option of a true, asymmetric algorithm-
based, digital signature in the gss_sign() and gss_seal()
operations, whereas DASS uses an integrity checksum based on a
MAC computed with a symmetric algorithm (DES). For some
environments, the availability of true, non-repudiable digital
signatures is a necessity.
5) SPKM data formats and procedures are designed to be as similar
to those for the Kerberos mechanism as is practical. This is
done for ease of implementation in those environments where
Kerberos has already been implemented.
For the above reasons, it is felt that the SPKM will offer greater
flexibility and functionality than DASS, without undue complexity or
overhead.
KEY MANAGEMENT
The key management employed in SPKM is intended to be as compatible
as possible with both X.509 [X.509] and PEM [RFC-1422], since these
represent large communities of interest and show relative maturity in
standards.
ACKNOWLEDGMENTS
Much of the material in this document is based on the Kerberos
Version 5 GSS-API mechanism [KRB5], and is intended to be as
compatible with it as possible. This document also owes a great debt
to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
many fruitful discussions, to Kelvin Desplanque of Domus Software
for implementation-related clarifications, and to John Linn of
OpenVision Technologies for helpful comments.
Adams Document Expiration: 30 April 1995 2
1. OVERVIEW
The goal of the Generic Security Service Application Program
Interface (GSS-API) is stated in the abstract of [RFC-1508] as
follows:
"This Generic Security Service Application Program Interface (GSS-
API) definition provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments. This specification defines
GSS-API services and primitives at a level independent of
underlying mechanism and programming language environment, and is
to be complemented by other, related specifications:
- documents defining specific parameter bindings for particular
language environments;
- documents defining token formats, protocols, and procedures to
be implemented in order to realize GSS-API services atop
particular security mechanisms."
The SPKM is an instance of the latter type of document and is
therefore termed a "GSS-API Mechanism". This mechanism provides
authentication, key establishment, data integrity, and data
confidentiality in an on-line distributed application environment
using a public-key infrastructure. Because it conforms to the
interface defined by [RFC-1508], SPKM can be used as a drop-in
replacement by any application which makes use of security services
through GSS-API calls (for example, any application which already
uses the Kerberos GSS-API for security). The use of a public-key
infrastructure allows non-repudiable digital signatures to be
employed for message exchanges, and provides other benefits such as
scalability to large user populations.
The tokens defined in SPKM are intended to be used by application
programs according to the GSS API "operational paradigm" (see
[RFC-1508] for further details):
The operational paradigm in which GSS-API operates is as follows.
A typical GSS-API caller is itself a communications protocol [or
is an application program which uses a communications protocol],
calling on GSS-API in order to protect its communications with
authentication, integrity, and/or confidentiality security
services. A GSS-API caller accepts tokens provided to it by its
local GSS-API implementation [i.e., its GSS-API mechanism] and
transfers the tokens to a peer on a remote system; that peer
passes the received tokens to its local GSS-API implementation for
processing.
This document defines two separate GSS-API mechanisms, SPKM-1 and
SPKM-2, which are identical except that SPKM-2 requires the presence
of secure timestamps for the purpose of replay detection during
context establishment and SPKM-1 does not. This allows greater
flexibility for applications since secure timestamps cannot always
be guaranteed to be available in a given environment.
Adams Document Expiration: 30 April 1995 3
2. ALGORITHMS
A number of algorithm types are employed in SPKM. Each type, along
with its purpose and a set of specific examples, is described in this
section.
2.1 Integrity Algorithm (I-ALG):
Purpose:
This algorithm is used to ensure that a message has not been
altered in any way after being constructed by the legitimate
sender. Depending on the algorithm used, the application of
this algorithm may also provide authenticity and non-
repudiability for the message.
Examples:
md5WithRSA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 3
}
This algorithm provides data integrity and non-repudiation
by computing an RSA signature on the MD5 hash of that data.
Note that this is equivalent to md5WithRSAEncryption {1 2
840 113549 1 1 4}, which is defined in [PKCS1].
DES-MAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 10
}
This algorithm provides data integrity by computing a DES
MAC (as specified by [FIPS-113]) on that data.
md5-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) xx
}
This algorithm provides data integrity by encrypting, using
DES CBC, the MD5 hash of that data. This will typically be
faster in practice than computing a DES MAC if the input
data is not extremely short (e.g., a few bytes). Note that
the strength of this integrity mechanism is (at most) equal
to the strength of DES under a known-plaintext attack.
sum64-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) xx
}
Adams Document Expiration: 30 April 1995 4
This algorithm provides data integrity by encrypting, using
DES CBC, the concatenation of the data and the sum of all
the input data blocks (the sum computed using addition
modulo 2**64 - 1). Thus, in this algorithm, encryption is a
requirement for the integrity to be secure.
For comments regarding the security of this mechanism, see
[Juen84, Davi89].
2.2 Sequence Algorithm (S-ALG):
Purpose:
This symmetric algorithm is used to generate the encrypted
sequence number for a token. Because the input to the
integrity checksum (computed using an I-ALG) includes the
encrypted sequence number, an invalid message with a valid
sequence number, and a valid message with an invalid sequence
number will both be detected. (Note that here an invalid
sequence number is one which decrypts to a value that the
receiver was not expecting and an invalid message is one
which causes the integrity check to fail.)
Example:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV as a parameter
}
2.3 Confidentiality Algorithm (C-ALG):
Purpose:
This symmetric algorithm is used to generate the encrypted
data for gss_seal().
Example:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV as a parameter
}
Adams Document Expiration: 30 April 1995 5
2.4 Key Establishment Algorithm (K-ALG):
Purpose:
This algorithm is used to establish a symmetric key for use
by both the initiator and the target over the established
context. The keys used for S-ALG, C-ALG, and any keyed
I-ALGs (for example, DES-MAC) are derived from this context
key. As will be seen in Section 3.1, key establishment is
done within the X.509 authentication exchange and so the
resulting symmetric key is authenticated.
Example:
id-rsa-key-transport OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 22 -- imported from [X9.44]
}
In this algorithm, the context key is generated by the
initiator, encrypted with the RSA public key of the target,
and sent to the target. The target need not respond to the
initiator for the key to be established.
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
In this algorithm, the context key is generated jointly by
the initiator and the target using the Diffie-Hellman key
establishment algorithm. The target must therefore respond
to the initiator for the key to be established (so this
K-ALG cannot be used with unilateral authentication in
SPKM-2 (see Section 3.1)).
During context establishment in SPKM, the initiator offers a set of
possible symmetric encryption algorithms and a set of possible
integrity algorithms to the target. The symmetric algorithms
selected by the target become ones that may be used for S-ALG and
C-ALG over the established context. The integrity algorithms
selected by the target become ones that may be used for I-ALG over
the established context. Note that the order of the selected
integrity algorithms defines the values of the Quality of Protection
(QOP) parameter used in the gss_sign() and gss_seal() calls -- see
Section 5.2 for further details. Note also that if no response is
expected from the target (unilateral authentication in SPKM-2) then
the algorithms offered by the initiator are the ones that may be used
over the context (if this is unacceptable to the target then an error
message must be sent to the initiator so that the context is never
established).
Adams Document Expiration: 30 April 1995 6
Furthermore, in the first context establishment token the initiator
offers a set of possible K-ALGs, along with the key (or key half)
corresponding to the first algorithm in the set (its preferred
algorithm). If this K-ALG is unacceptable to the target it must
choose one of the other K-ALGs in the set and send this choice along
with the key (or key half) corresponding to this choice in its
response (otherwise an error token must be sent so that the context
is never established). If necessary (that is, if the target chooses
a 2-pass K-ALG such as dhKeyAgreement), the initiator will send its
key half in a response to the target.
In future versions of SPKM, other algorithms may be specified for any
or all of I-ALG, S-ALG, C-ALG, and K-ALG.
3. TOKEN FORMATS
This section discusses protocol-visible characteristics of the GSS-
API mechanism to be implemented atop the SPKM; it defines elements of
protocol for interoperability and is independent of language bindings
per [RFC-1509].
The SPKM GSS-API mechanism will be identified by an Object Identifier
representing "SPKM-1" or "SPKM-2", having the value:
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)}
or
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)},
where SPKM-1 uses random numbers for replay detection during context
establishment and SPKM-2 uses timestamps.
Tokens transferred between GSS-API peers (for security context
management and per-message protection purposes) are defined.
3.1. Context Establishment Tokens
Three classes of tokens are defined in this section: "Initiator"
tokens, emitted by calls to gss_init_sec_context() and consumed by
calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
to gss_accept_sec_context() and consumed by calls to
gss_init_sec_context(); and "Error" tokens, potentially emitted by
calls to gss_init_sec_context(), gss_accept_sec_context(),
gss_delete_sec_context(), gss_process_context_token(), gss_verify(),
and gss_unseal() and consumed by calls to
gss_process_context_token().
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
Adams Document Expiration: 30 April 1995 7
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "SPKM-1" or "SPKM-2"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
}
The innerContextToken of the initial context token will consist of an
SPKM_REQ message containing a token-id (TOK_ID) field which shall
contain the value 0100 (hex).
The above GSS-API framing shall be applied to all tokens emitted by
the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT,
SPKM_ERROR, context-deletion, and per-message tokens, not just to
the initial token in a context establishment sequence. While not
required by RFC-1508, this enables implementations to perform
enhanced error-checking. The innerContextToken field of context
establishment tokens for the SPKM GSS-API mechanism will consist of a
message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing
a TOK_ID field having the value 0100 (hex) for SPKM_REQ messages,
0200 (hex) for SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT
messages, and 0400 (hex) for SPKM_ERROR messages. All
innerContextTokens are encoded using Abstract Syntax Notation One
Basic Encoding Rules (ASN.1 BER).
The SPKM context establishment tokens are defined according to
[X.509] Section 10. SPKM-1 (random numbers) uses Section 10.3, "Two-
way Authentication", when performing unilateral authentication of the
target to the initiator and uses Section 10.4, "Three-way Authentica-
tion", when mutual authentication is requested by the initiator.
SPKM-2 (timestamps) uses Section 10.2, "One-way Authentication", when
performing unilateral authentication of the initiator to the target
and uses Section 10.3, "Two-way Authentication", when mutual authen-
tication is requested by the initiator.
The implication of the above paragraph is that for SPKM-2 unilateral
authentication no negotiation of K-ALG can be done (the target either
accepts the K-ALG given by the initiator or disallows the context).
For SPKM-2 mutual or SPKM-1 unilateral authentication some negotia-
tion is possible, but the target can only choose among the one-pass
K-ALGs offered by the initiator (or disallow the context). For
SPKM-1 mutual authentication the target can choose any one- or two-
pass K-ALG offered by the initiator.
It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
mutual authentication. Although unilateral authentication is avail-
able for both mechanisms, its use is not generally recommended.
Adams Document Expiration: 30 April 1995 8
3.1.1. Context Establishment Tokens - Initiator (first token)
In order to accomplish context establishment, it is necessary that
both the initiator and the target have access to the other party?s
encryption and verfication certificate(s). In some environments the
initiator may choose to acquire all certificates and send the
relevant ones to the target in the first token. In other environ-
ments each side may individually obtain the certificate data it
needs. In either case, however, the SPKM implementation must have
the ability to obtain certificates which correspond to a supplied
Name. The actual mechanism to be used to achieve this is a local
implementation matter and is therefore outside the scope of this
specification.
Relevant SPKM_REQ syntax is as follows (note that imports from other
documents are given in Appendix A):
SPKM-REQ ::= SEQUENCE {
requestToken [0] REQ_TOKEN
certif_data [1] CertificationData OPTIONAL
auth_data [2] AuthorizationData OPTIONAL
-- see [RFC-1510] for a discussion of auth-data
}
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath
certificateRevocationList [1] CertificateList OPTIONAL
}
CertificationPath ::= SEQUENCE {
userEncCertif [0] SingleCertificate
userVerifCertif [1] SingleCertificate OPTIONAL
-- may send separate verification certificate
-- to allow different algorithms to be used for
-- decryption and signing
theCACertificates [2] SEQUENCE OF CertificatePair OPTIONAL
} -- certif. path from target to source
SingleCertificate ::= CHOICE { -- only one for now
Certificate -- imported from [X.509]
} -- (1993)
Adams Document Expiration: 30 April 1995 9
REQ_TOKEN ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0100 (hex)
timestamp [1] UTCTime -- may be NULL for mechanism SPKM-1
randSrc [2] Random_Integer,
targ_name [3] Name,
src_name [4] Name,
req_data [5] Context_Data,
validity [6] Validity OPTIONAL
-- validity interval for key (may be used in the
-- computation of security context lifetime)
key_estb_set [7] Key_Estb_Alg
-- specifies set of key establishment algorithms
key_estb_req [8] BIT STRING
-- key estb. request corresponding to first K-ALG in set
}
Random_Integer ::= BIT STRING
Context_Data ::= SEQUENCE {
channelId [0] ChannelId, -- channel bindings
seq_number [1] INTEGER OPTIONAL -- sequence number
options [2] Options
symm_alg [3] Symm_Alg -- symmetric enc. alg.
intg_alg [4] Intg_Alg -- integrity algorithm
}
ChannelId ::= OCTET STRING
Options ::= BIT STRING {
delegation_state (0),
mutual_state (1),
replay_det_state (2),
sequence_state (3),
conf_avail (4),
integ_avail (5)
}
Symm_Alg ::= SEQUENCE OF AlgorithmIdentifier -- for S-ALG, C-ALG
-- (first id. in agreed
-- set is default alg.
-- for context)
Intg_Alg ::= SEQUENCE OF AlgorithmIdentifier -- order of agreed seq.
-- is constrained by
-- semantics of QOP
-- parameter (see 5.2)
Key_Estb_Alg ::= SEQUENCE OF AlgorithmIdentifier
-- to allow negotiation
-- of K-ALG
Adams Document Expiration: 30 April 1995 10
A context establishment sequence based on the SPKM will perform uni-
lateral authentication if the mutual_req bit is not set in the
application's call to gss_init_sec_context(). SPKM-2 accomplishes
this using only SPKM_REQ (thereby authenticating the initiator to the
target), while SPKM-1 accomplishes this using both SPKM_REQ and
SPKM_REP_TI (thereby authenticating the target to the initiator).
Applications requiring authentication of both peers (initiator as
well as target) should request mutual authentication, resulting in
"mutual_state" being set within SPKM_REQ Options. In response to
such a request, the context target will reply to the initiator with a
token containing either an SPKM_REP_TI or SPKM_ERROR. If mechanism
SPKM-2 has been chosen, this completes the (timestamp-based) mutual
authentication context establishment exchange. If mechanism SPKM-1
has been chosen and SPKM_REP_TI is sent, the initiator will then
reply to the target with either an SPKM_REP_IT or SPKM_ERROR,
completing the (random-number-based) mutual authentication context
establishment exchange.
3.1.2. Context Establishment Tokens - Target
Relevant SPKM_REP_TI syntax is as follows:
SPKM_REP_TI ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0200 (hex)
timestamp [1] UTCTime -- may be NULL for
-- mechanism SPKM-1
randTarg [2] Random_Integer,
src_name [3] Name,
randSrc [4] Random_Integer,
rep_data [5] Context_Data,
key_estb_id [6] AlgorithmIdentifier OPTIONAL
-- used if target is changing key estb. algorithm
-- (must be a member of initiator?s key_estb_set)
key_estb_str [7] BIT STRING OPTIONAL
-- contains either the response to initiator?s
-- key_estb_req (if init. used a 2-pass K-ALG) or
-- the key_estb_req corresponding to K-ALG supplied
-- in above key_estb_id
}
3.1.3. Context Establishment Tokens - Initiator (second token)
Relevant SPKM_REP_IT syntax is as follows:
SPKM_REP_IT ::= SIGNED SEQUENCE {
tok_id [0] INTEGER -- shall contain 0300 (hex)
randTarg [1] Random_Integer,
targ_name [2] Name,
key_estb_rep [3] BIT STRING OPTIONAL
-- contains the response to target?s key_estb_str
-- (if target selected a 2-pass K-ALG)
}
Adams Document Expiration: 30 April 1995 11
3.1.4. Error Token
The syntax of SPKM_ERROR is as follows:
SPKM_ERROR ::= SIGNED SEQUENCE {
tok_id [0] INTEGER, -- shall contain 0400 (hex)
pvno[1] INTEGER, -- protocol version number
error-code[2] INTEGER,
guilty-seq[3] OCTET STRING OPTIONAL,
-- encrypted sequence number of the
-- token which caused this error
-- (empty if seq. nums not used)
e-text[4] PrintableString OPTIONAL,
e-data[5] OCTET STRING OPTIONAL
}
Values to be transferred in the error-code field of a SPKM_ERROR
message are defined in Section 5 of this specification.
3.2. Per-Message and Context Deletion Tokens
Three classes of tokens are defined in this section: "Sign" tokens,
emitted by calls to gss_sign() and consumed by calls to gss_verify();
"Seal" tokens, emitted by calls to gss_seal() and consumed by calls
to gss_unseal(); and context deletion tokens, emitted by calls to
gss_delete_sec_context() and consumed by calls to
gss_process_context_token().
3.2.1. Per-message Tokens - Sign
Use of the gss_sign() call yields a token, separate from the user
data being protected, which can be used to verify the integrity of
that data as received. The token and the data are sent separately
by the sending application and it is the receiving application's
responsibility to associate the received data with the received
token.
The SPKM_SIGN token has the following format:
SPKM_SIGN ::= SEQUENCE {
sign_header [0] Sign_Header,
sign_body [1] Sign_Body
}
Adams Document Expiration: 30 April 1995 12
Sign_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0101 (hex)
int_alg [1] AlgorithmIdentifier,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- NULL = default id.
seq_alg [2] AlgorithmIdentifier,
-- Encryption alg. to compute sequence
-- (must be one of the agreed symmetric
-- algorithms for this context).
-- NULL = default id.
snd_seq [3] OCTET STRING,
-- Encrypted sequence number.
}
Sign_Body ::= SEQUENCE {
int_cksum [0] OCTET STRING
-- Checksum of header and data,
-- calculated according to algorithm
-- specified in int_alg field.
}
3.2.1.1. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the data field, logically prepended by the bytes
of the plaintext token header (sign_header). The result binds the
data to the entire plaintext header, so as to minimize the possibil-
ity of malicious splicing.
For example, if the int_alg specifies the md5WithRSA algorithm, then
the checksum is formed by computing an MD5 [RFC-1321] hash over the
plaintext data (prepended by the header), and then computing an RSA
signature [PKCS1] on the 16-byte MD5 result. The signature is
computed using the RSA private key retrieved from the credentials
structure and the result (whose length is implied by the "modulus"
parameter in the private key) is stored in the int_cksum field.
If the int_alg specifies a keyed hashing algorithm (for example,
DES-MAC or md5-DES-CBC), then the key to be used is the established
context key. Again, the result (whose length is implied by int_alg)
is stored in the int_cksum field.
Adams Document Expiration: 30 April 1995 13
3.2.1.2. Sequence Number
It is assumed that the underlying transport layers (of whatever pro-
tocol stack is being used by the application) will provide adequate
communications reliability (that is, non-malicious loss, re-ordering,
etc., of data packets will be handled correctly). Therefore, enc-
rypted sequence numbers are used in SPKM purely for security, as
opposed to reliability, reasons (that is, to avoid malicious loss,
replay, or re-ordering of SPKM tokens) -- note that sequence numbers
are used so that there is no requirement for secure timestamps in the
message tokens. The initiator's initial sequence number for the
current context may be explicitly given in the Context_Data field of
SPKM_REQ and the target's initial sequence number may be explicitly
given in the Context_Data field of SPKM_REP_TI; if either of these is
not given then the default value of 00 is to be used.
Sequence number field: The plaintext sequence number field is
formed from the sender's four-byte sequence number as follows. If
the four bytes of the sender's sequence number are named s0, s1, s2
and s3 (from least to most significant), the plaintext sequence
number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
di), where 'di' is the direction-indicator (Hex 00 - sender is the
context initiator, Hex FF - sender is the context acceptor).
The field is then CBC encrypted using the symmetric algorithm
specified in seq_alg, IV', and the context key. (IV' is computed as
the ECB decryption of the IV specified in seq_alg, using the context
key and the symmetric algorithm specified in seq_alg. The reason for
having seq_alg convey an encrypted IV is to avoid revealing a known
plaintext/ciphertext pair in the token.) The resulting encrypted
sequence number is placed in snd_seq. After sending a gss_sign() or
gss_seal() token, the sender's sequence number is incremented by one.
3.2.1.3. Sequence Number Processing
The receiver of the token will decrypt the sequence number field
using the context key and compare it with the expected sequence
number. The repetition of the (effectively 1-bit) direction
indicator within the sequence number field provides redundancy so
that the receiver may verify that the decryption succeeded.
Since the encrypted sequence number is used as part of the input to
the integrity checksum, attempts to splice a checksum and sequence
number from different messages will be detected. The direction
indicator will detect packets that have been maliciously reflected.
3.2.2. Per-message Tokens - Seal
Use of the gss_seal() call yields a token which encapsulates the in-
put user data (optionally encrypted) along with associated integrity
check quantities. The token emitted by gss_seal() consists of an
integrity header followed by a body portion that contains either the
plaintext data (if conf_alg = FFFF) or encrypted data (using the key
specified in 3.2.2.4 with one of the agreed C-ALGs for this context).
Adams Document Expiration: 30 April 1995 14
The SPKM_SEAL token has the following format:
SPKM_SEAL ::= SEQUENCE {
seal_header [0] Seal_Header,
seal_body [1] Seal_Body
}
Seal_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0201 (hex)
int_alg [1] AlgorithmIdentifier,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- NULL = default id.
seq_alg [2] AlgorithmIdentifier,
-- Encryption alg. to compute sequence
-- (must be one of the agreed symmetric
-- algorithms for this context).
-- NULL = default id.
conf_alg [3] AlgorithmIdentifier,
-- Confidentiality algorithm indicator
-- (must be 'FFFF' or one of the agreed
-- symmetric algorithms for this
-- context).
-- NULL = default id , 'FFFF' = none.
snd_seq [4] OCTET STRING,
-- Encrypted sequence number.
}
Seal_Body ::= SEQUENCE {
int_cksum [0] OCTET STRING
-- Checksum of header and data,
-- calculated according to algorithm
-- specified in int_alg field.
data [1] OCTET STRING
-- encrypted or plaintext data.
}
3.2.2.1: Confounding
As in [KRB5], an 8-byte random confounder is prepended to the data to
compensate for the fact that an IV of zero is used for encryption.
The result is referred to as the "confounded" data field.
3.2.2.2. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the plaintext data field, logically prepended by
the bytes of the plaintext token header (seal_header). As with
gss_sign(), the result binds the data to the entire plaintext header,
so as to minimize the possibility of malicious splicing.
Adams Document Expiration: 30 April 1995 15
The examples for md5WithRSA and DES-MAC are exactly as specified in
3.2.1.1.
If int_alg specifies md5-DES-CBC and conf_alg specifies anything
other than DES-CBC, then the checksum is computed according to
3.2.1.1 and the result is stored in int_alg. However, if conf_alg
specifies DES-CBC then the encryption and the integrity can be done
as follows. An MD5 [RFC-1321] hash is computed over the plaintext
data (prepended by the header). This 16-byte value is appended to
the concatenation of the "confounded" data and 1-8 padding bytes (the
padding is as specified in [KRB5] for DES-CBC). The result is
then CBC encrypted using the context key and placed in the "data"
field of Seal_Body. The final two blocks of ciphertext (i.e., the
encrypted MD5 hash) are also placed in the int_cksum field of
Seal_Body as the integrity checksum.
If int_alg specifies sum64-DES-CBC then conf_alg must specify DES-CBC
(i.e., confidentiality must be requested by the calling application
or SPKM will return an error). Encryption and integrity are done in
a single pass using the context key as follows. The sum (modulo
2**64 - 1) of all plaintext data blocks (prepended by the header) is
computed. This 8-byte value is appended to the concatenation of the
"confounded" data and 1-8 padding bytes (the padding is as specified
in [KRB5] for DES-CBC). As above, the result is then CBC encrypted
and placed in the "data" field of Seal_Body. The final block of
ciphertext (i.e., the encrypted sum) is also placed in the int_cksum
field of Seal_Body as the integrity checksum.
3.2.2.3 Sequence Number
Encrypted sequence numbers are computed and processed for gss_seal()
exactly as specified in 3.2.1.2 and 3.2.1.3.
3.2.2.4: Data Encryption
The following procedure is followed unless (a) conf_alg is Hex FFFF,
or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC, or (c) int_alg
is sum64-DES-CBC:
The "confounded" data is padded and encrypted according to the
algorithm specified in the conf_alg field. The data is encrypted
using CBC with an IV of zero. The key used is derived from the
established context key by XOR-ing the context key with the hexadeci-
mal constant F0F0F0...F0 (this ensures that the key used for encryp-
tion and the key used for a separate, keyed integrity algorithm --
for example DES-MAC, but not sum64-DES-CBC -- are different).
3.2.3. Context deletion token
The token emitted by gss_delete_sec_context() is based on the packet
format for tokens emitted by gss_sign().
Adams Document Expiration: 30 April 1995 16
The SPKM_DEL token has the following format:
SPKM_DEL ::= SEQUENCE {
del_header [0] Del_Header,
del_body [1] Del_Body
}
Del_Header ::= SEQUENCE {
tok_id [0] INTEGER
-- shall contain 0301 (hex)
int_alg [1] AlgorithmIdentifier,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- NULL = default id.
seq_alg [2] AlgorithmIdentifier,
-- Encryption alg. to compute sequence
-- (must be one of the agreed symmetric
-- algorithms for this context).
-- NULL = default id.
snd_seq [3] OCTET STRING, -- Encrypted sequence number.
}
Del_Body ::= SEQUENCE {
int_cksum [0] OCTET STRING
-- Checksum of header, calculated
-- according to algorithm specified
-- in int_alg field.
}
snd_seq will be calculated as for tokens emitted by gss_sign(). The
int_cksum will be calculated as for tokens emitted by gss_sign(),
except that the user-data component of the checksum data will be a
zero-length string.
4. NAME TYPES AND OBJECT IDENTIFIERS
No name types have yet been defined for SPKM. This section is for
further study.
5. PARAMETER DEFINITIONS
This section defines parameter values used by the SPKM GSS-API
mechanism. It defines interface elements in support of portability.
Adams Document Expiration: 30 April 1995 17
5.1. Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the SPKM GSS-API mechanism. Use of these
definitions will enable independent implementors to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of gss_display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation should make available, through include files or other
means, a facility to translate these symbolic names into the concrete
values which a particular GSS-API implementation uses to represent
the minor_status values specified in this section. It is recognized
that this list may grow over time, and that the need for additional
minor_status codes specific to particular implementations may arise.
5.1.1. Non-SPKM-specific codes
GSS_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_S_G_UNAVAIL_QOP
/* "Unavailable quality of protection specified" */
5.1.2. SPKM-specific-codes
GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
/* "Unknown integrity algorithm type in token" */
GSS_SPKM_S_SG_BAD_SYMM_ALG_TYPE
/* "Unknown symmetric algorithm type in token" */
GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
/* "Unknown key establishment algorithm type in token" */
GSS_SPKM_S_SG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
GSS_SPKM_S_SG_BAD_INT_ALG_SET
/* "No integrity algorithm in common from offered set" */
GSS_SPKM_S_SG_BAD_SYMM_ALG_SET
/* "No symmetric algorithm in common from offered set" */
GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET
/* "No key establishment algorithm in common from offered set" */
GSS_SPKM_S_SG_INVALID_TOKEN_DATA
/* "Data is improperly formatted: cannot encode into token" */
GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT
/* "Received token is improperly formatted: cannot decode" */
Adams Document Expiration: 30 April 1995 18
5.2. Quality of Protection Values
Quality of Protection (QOP) values are defined for the SPKM GSS-API
mechanism, and are used as input to gss_sign() and gss_seal() to
select among alternate integrity-checking algorithms. Once a set of
algorithms has been agreed upon by the context initiator and target,
the QOP parameter simply selects from this ordered set.
More specifically, the SPKM_REQ token may send a sequence of "n" Alg.
IDs specifying integrity-checking algorithms supported by the
initiator. The target may support only a subset m (m <= n) of these,
and so will return the sequence of "m" Alg. IDs which it supports in
the SPKM_REP_TI token. The first Alg. ID is therefore the default
algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through
QOP = m-1, respectively. Any QOP value greater than or equal to m is
equated to m-1 and is therefore mapped to the last Alg. ID in the
agreed set.
To aid in implementation and interoperability, the following
stipulations are made. The set of n Alg. IDs sent by the initiator
must contain one specifying an algorithm which computes a true
digital signature in the first position, and must contain one
specifying any other (non-signature) integrity algorithm in the
second position. The set of m Alg. IDs returned by the target must
also contain one specifying an algorithm which computes a true
digital signature in the first position, and one specifying a (non-
signature) integrity algorithm in the second position.
Note that if the SPKM_REP_TI token is not used (unilateral authen-
tication using SPKM-2), then m=n and the "agreed" set of Alg. IDs is
simply taken to be the initiator's set.
The reason for these stipulations is to allow the QOP parameter to
convey the semantics of the desired integrity service without forcing
it to specify the actual algorithms to be used. The result is that
the application is always able to choose, in a completely general and
portable way, an integrity service which provides non-repudiation
semantics (by passing QOP = Hex 00), and one which does not provide
non-repudiation semantics (by passing QOP = Hex 01). Note that an
application which is aware of its own underlying environment and/or
is aware of the underlying environment of its peer is not unduly
constrained by the above stipulations because any other number or
kind of algorithms may be agreed upon during context establishment,
making other QOP values perfectly valid and meaningful over that
context and between those peers.
6. SECURITY CONSIDERATIONS
Security issues are discussed throughout this memo.
Adams Document Expiration: 30 April 1995 19
7. REFERENCES
[Davi89]: D. W. Davies and W. L. Price, "Security for Computer
Networks", Second Edition, John Wiley and Sons, New York, 1989.
[FIPS-113]: National Bureau of Standards, Federal Information
Processing Standard 113, "Computer Data Authentication", May 1985.
[Juen84]: R. R. Jueneman, C. H. Meyer and S. M. Matyas, ~Message
Authentication with Manipulation Detection Codes?, in Proceedings of
the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
Society Press, 1984, pp.33-54..
[KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
Internet Draft draft-ietf-cat-kerb5gss-01.
[PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security,
Inc., Nov. 1993.
[PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
Data Security, Inc., Nov. 1993.
[RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.
[RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC 1422.
[RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security
Service", RFC 1507.
[RFC-1508]: J. Linn, "Generic Security Service Application Program
Interface", RFC 1508.
[RFC-1509]: J. Wray, "Generic Security Service Application Program
Interface: C-bindings", RFC 1509.
[RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510.
[X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication Framework", CCITT
Recommendation X.509, 1993.
[X9.44]: ANSI, "Public Key Cryptography Using Reversible
Algorithms for the Financial Services Industry: Transport of
Symmetric Algorithm Keys Using RSA", X9.44-1993.
8. AUTHOR'S ADDRESS
Carlisle Adams
Bell-Northern Research, Ltd.
P.O.Box 3511, Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613.763.9008
E-mail: cadams@bnr.ca
Adams Document Expiration: 30 April 1995 20
Appendix: IMPORTS
A.1 ASN.1 encoding
The following definitions are taken from X.501 and X.509.
--CCITT Definitions:
joint-iso-ccitt OBJECT IDENTIFIER ::= {2}
ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
algorithm OBJECT IDENTIFIER ::= {ds 8}
encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}
hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2}
signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}
rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}
iso OBJECT IDENTIFIER ::= {1}
identified-organization OBJECT IDENTIFIER ::= {iso 3}
--1989 OSI Implementors Workshop "Stable" Agreements
oiw OBJECT IDENTIFIER ::= {identified-organization 14}
dssig OBJECT IDENTIFIER ::= {oiw 7}
oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2}
oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3}
--PKCS #1 definition [PKCS1]
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1
}
--PKCS #3 definition [PKCS3]
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
-- the parameter to be used with this algorithm is
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}
Adams Document Expiration: 30 April 1995 21
--X.501 definitions
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
Name ::= CHOICE { --only one for now
RDNSequence
}
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
--X.509 definitions (with proposed 1992 extensions presumed)
ENCRYPTED MACRO ::=
BEGIN
TYPE NOTATION ::= type(ToBeEnciphered)
VALUE NOTATION ::= value(VALUE BIT STRING)
END -- of ENCRYPTED
SIGNED MACRO ::=
BEGIN
TYPE NOTATION ::= type (ToBeSigned)
VALUE NOTATION ::= value (VALUE
SEQUENCE{
ToBeSigned,
AlgorithmIdentifier, --of the algorithm used to
--generate the signature
ENCRYPTED OCTET STRING --where the octet string is the
--result of the hashing of the
--value of "ToBeSigned"
}
)
END -- of SIGNED
SIGNATURE MACRO ::=
BEGIN
TYPE NOTATION ::= type (OfSignature)
VALUE NOTATION ::= value (VALUE
SEQUENCE {
AlgorithmIdentifier, --of the algorithm used to compute
ENCRYPTED OCTET STRING -- the signature where the octet
-- string is a function (e.g., a
-- compressed or hashed version)
-- of the value 'OfSignature',
-- which may include the
-- identifier of the algorithm
-- used to compute the signature
}
)
END -- of SIGNATURE
Adams Document Expiration: 30 April 1995 22
Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber [1] CertificateSerialNumber,
signature [2] AlgorithmIdentifier,
issuer [3] Name,
validity [4] Validity,
subject [5] Name,
subjectPublicKeyInfo [6] SubjectPublicKeyInfo,
issuerUID [7] IMPLICIT UID OPTIONAL, -- used in v2 only
subjectUID [8] IMPLICIT UID OPTIONAL -- used in v2 only
}
Version ::= INTEGER {v1(0), v2(1)}
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
NotBefore UTCTime,
NotAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
UID ::= BIT STRING
CertificatePair ::= SEQUENCE {
forward [0] SingleCertificate OPTIONAL,
reverse [1] SingleCertificate OPTIONAL
} -- at least one of the pair shall be present
CertificateList ::= SIGNED SEQUENCE {
signature [0] AlgorithmIdentifier,
issuer [1] Name,
thisUpdate [2] UTCTime,
nextUpdate [3] UTCTime OPTIONAL,
revokedCertificates [4] SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime
} OPTIONAL
}
Adams Document Expiration: 30 April 1995 23
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0] INTEGER,
ad-data[1] OCTET STRING
}
-- ad-data This field contains authorization data to be
-- interpreted according to the value of the
-- corresponding ad-type field.
-- ad-type This field specifies the format for the ad-data
-- subfield. All negative values are reserved for
-- local use. Non-negative values are reserved for
-- registered use.
A.2 Encoding Rules
Whenever a structure is to be signed it must always be constructed
the same way. This is particularly important where a signed structure
has to be reconstructed by the recipient before the signature is
verified. The rules listed below are taken from X.509.
- the definite form of length encoding shall be used, encoded in
the minimum number of octets;
- for string types, the constructed form of encoding shall not
be used;
- if the value of a type is its default value, it shall be
absent;
- the components of a Set type shall be encoded in ascending
order of their tag values;
- the components of a Set-of type shall be encoded in ascending
order of their octet values;
- if the value of a Boolean type is true, the encoding shall
have its contents octet set to Hex 'FF';
- unused bits in the final octet of the encoding of a BitString
value, if there are any, shall be set to zero;
- the encoding of a Real type shall be such that bases 8, 10 and
16 shall not be used, and the binary scaling factor shall be
zero.
Adams Document Expiration: 30 April 1995 24
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/