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):
The "confounded" data is padded and encrypted according to the
algorithm specified in the conf-alg field. The data is encrypted
using CBC with an IV of zero. The key used is the appropriate subkey
derived from the established context key using the subkey derivation
algorithm described in Section 2.4 (this ensures that the subkey used
for encryption and the subkey used for a separate, keyed integrity
algorithm -- for example DES-MAC, but not sum64-DES-CBC -- are
different).
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 Del-Header,
int-cksum BIT STRING
-- Checksum of header, calculated
-- according to algorithm specified
-- in int-alg field.
}
Del-Header ::= SEQUENCE {
tok-id INTEGER (769),
-- shall contain 0301 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
snd-seq [1] SeqNum OPTIONAL
-- sequence number field.
}
The field snd-seq will be calculated as for tokens emitted by
gss_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.
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.
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" */
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_NO_PVNO_IN_COMMON
/* "No protocol version number 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.
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.
The following TS values (i.e., algorithm qualifiers) are specified;
other values may be added in the future.
For the Confidentiality TS field:
00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK
For the Integrity TS field:
00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT
00010 (2) = SPKM_INT_ALG_REPUDIABLE
Clearly, qualifiers such as strong, medium, and weak are debatable
and likely to change with time, but for the purposes of this version
of the specification we define these terms as follows. A
confidentiality algorithm is "weak" if the effective key length of
the cipher is 40 bits or less; it is "medium-strength" if the
effective key length is strictly between 40 and 80 bits; and it is
"strong" if the effective key length is 80 bits or greater. (Note
that "effective key length" describes the computational effort
required to break a cipher using the best-known cryptanalytic attack
against that cipher.)
A five-bit TS field allows up to 31 qualifiers for each of
confidentiality and integrity (since "0" is reserved for "default").
This document specifies three for confidentiality and two for
integrity, leaving a lot of room for future specification.
Suggestions of qualifiers such as "fast", "medium-speed", and "slow"
have been made, but such terms are difficult to quantify (and in any
case are platform- and processor-dependent), and so have been left
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.)
- 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). Although an initiator who wishes to remain
anonymous will never actually use the non-repudiable digital
signature, this integrity service must be available over the context
so that the target can use it if desired.
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
information which is included in SPKM context-establishment, error,
context-deletion, and per-message tokens. The function is defined in
the following section.
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 it was expected) information 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 information 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 unrecognized token-id information is considered to be
equivalent to token-id information 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.
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 does no cryptographic processing to determine
the validity of tokens; it simply attempts to parse the mech_type,
token_type, and context-id fields of any token it is given. Thus, it
is conceivable, for example, that an arbitrary buffer of data might
start with random values which look like a valid mech_type and that
SPKM_Parse_token() would return incorrect information if given this
buffer. While conceivable, however, such a situation is unlikely.
The SPKM_Parse_token() 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 some 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 and function
specification 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 SPKM mechanisms shall be able to perform the mapping from the
token-id information which is included in every token (through the
tag values in SPKMInnerContextToken or through the tok-id field) to
one of the above token types. Applications should be able to decide,
on the basis of token_type, which GSS function to call (for example,
if the token is a GSS_INIT_TOKEN then the application will call
gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then
the application will call gss_unwrap()).
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 or different 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). The key-src-bind field in SPKM-REQ is required to be
present for the case of SPKM-2 unilateral authentication precisely to
assist the target in trusting the freshness of this token (and its
proposed context key).
7. Security Considerations
Security issues are discussed throughout this memo.
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]: Linn, J., "Generic Security Service Application Program
Interface Version 2", Work in Progress.
[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]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC1964, June 1996.
[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]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321.
[RFC-1422]: Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC1422.
[RFC-1423]: Balenson, D., "Privacy Enhancement for Internet
Elecronic Mail: Part III: Algorithms, Modes, and Identifiers",
RFC1423.
[RFC-1508]: Linn, J., "Generic Security Service Application Program
Interface", RFC1508.
[RFC-1509]: Wray, J., "Generic Security Service Application Program
Interface: C-bindings", RFC1509.
[RFC-1510]: Kohl J., and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC1510.
[9798]: ISO/IEC 9798-3, "Information technology - Security
Techniques - Entity authentication mechanisms - Part 3: Entitiy
authentication using a public key algorithm", ISO/IEC, 1993.
[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.
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
EMail: cadams@bnr.ca
Appendix A: ASN.1 Module Definition
SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Name
FROM InformationFramework {joint-iso-ccitt(2) ds(5) module(1)
informationFramework(1) 2}
Certificate, CertificateList, CertificatePair, AlgorithmIdentifier,
Validity
FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1)
authenticationFramework(7) 2} ;
-- types --
SPKM-REQ ::= SEQUENCE {
requestToken REQ-TOKEN,
certif-data [0] CertificationData OPTIONAL,
auth-data [1] AuthorizationData OPTIONAL
}
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath OPTIONAL,
certificateRevocationList [1] CertificateList OPTIONAL
} -- at least one of the above shall be present
CertificationPath ::= SEQUENCE {
userKeyId [0] OCTET STRING OPTIONAL,
userCertif [1] Certificate OPTIONAL,
verifKeyId [2] OCTET STRING OPTIONAL,
userVerifCertif [3] Certificate OPTIONAL,
theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
} -- Presence of [2] or [3] implies that [0] or [1] must also be
-- present. Presence of [4] implies that at least one of [0], [1],
-- [2], and [3] must also be present.
REQ-TOKEN ::= SEQUENCE {
req-contents Req-contents,
algId AlgorithmIdentifier,
req-integrity Integrity -- "token" is Req-contents
}
Integrity ::= BIT STRING
-- If corresponding algId specifies a signing algorithm,
-- "Integrity" holds the result of applying the signing procedure
-- specified in algId to the BER-encoded octet string which results
-- from applying the hashing procedure (also specified in algId) to
-- the DER-encoded octets of "token".
-- Alternatively, if corresponding algId specifies a MACing
-- algorithm, "Integrity" holds the result of applying the MACing
-- procedure specified in algId to the DER-encoded octets of
-- "token"
Req-contents ::= SEQUENCE {
tok-id INTEGER (256), -- shall contain 0100 (hex)
context-id Random-Integer,
pvno BIT STRING,
timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2
randSrc Random-Integer,
targ-name Name,
src-name [0] Name OPTIONAL,
req-data Context-Data,
validity [1] Validity OPTIONAL,
key-estb-set Key-Estb-Algs,
key-estb-req BIT STRING OPTIONAL,
key-src-bind OCTET STRING OPTIONAL
-- This field must be present for the case of SPKM-2
-- unilateral authen. if the K-ALG in use does not provide
-- such a binding (but is optional for all other cases).
-- The octet string holds the result of applying the
-- mandatory hashing procedure (in MANDATORY I-ALG;
-- see Section 2.1) as follows: MD5(src || context_key),
-- where "src" is the DER-encoded octets of src-name,
-- "context-key" is the symmetric key (i.e., the
-- unprotected version of what is transmitted in
-- key-estb-req), and "||" is the concatenation operation.
}
Random-Integer ::= BIT STRING
Context-Data ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seq-number INTEGER OPTIONAL,
options Options,
conf-alg Conf-Algs,
intg-alg Intg-Algs,
owf-alg OWF-Algs
}
ChannelId ::= OCTET STRING
Options ::= BIT STRING {
delegation-state (0),
mutual-state (1),
replay-det-state (2),
sequence-state (3),
conf-avail (4),
integ-avail (5),
target-certif-data-required (6)
}
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL
}
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
SPKM-REP-TI ::= SEQUENCE {
responseToken REP-TI-TOKEN,
certif-data CertificationData OPTIONAL
-- present if target-certif-data-required option was
} -- set to TRUE in SPKM-REQ
REP-TI-TOKEN ::= SEQUENCE {
rep-ti-contents Rep-ti-contents,
algId AlgorithmIdentifier,
rep-ti-integ Integrity -- "token" is Rep-ti-contents
}
Rep-ti-contents ::= SEQUENCE {
tok-id INTEGER (512), -- shall contain 0200 (hex)
context-id Random-Integer,
pvno [0] BIT STRING OPTIONAL,
timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2
randTarg Random-Integer,
src-name [1] Name OPTIONAL,
targ-name Name,
randSrc Random-Integer,
rep-data Context-Data,
validity [2] Validity OPTIONAL,
key-estb-id AlgorithmIdentifier OPTIONAL,
key-estb-str BIT STRING OPTIONAL
}
SPKM-REP-IT ::= SEQUENCE {
responseToken REP-IT-TOKEN,
algId AlgorithmIdentifier,
rep-it-integ Integrity -- "token" is REP-IT-TOKEN
}
REP-IT-TOKEN ::= SEQUENCE {
tok-id INTEGER (768), -- shall contain 0300 (hex)
context-id Random-Integer,
randSrc Random-Integer,
randTarg Random-Integer,
targ-name Name,
src-name Name OPTIONAL,
key-estb-rep BIT STRING OPTIONAL
}
SPKM-ERROR ::= SEQUENCE {
errorToken ERROR-TOKEN,
algId AlgorithmIdentifier,
integrity Integrity -- "token" is ERROR-TOKEN
}
ERROR-TOKEN ::= SEQUENCE {
tok-id INTEGER (1024), -- shall contain 0400 (hex)
context-id Random-Integer
}
SPKM-MIC ::= SEQUENCE {
mic-header Mic-Header,
int-cksum BIT STRING
}
Mic-Header ::= SEQUENCE {
tok-id INTEGER (257), -- shall contain 0101 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
SeqNum ::= SEQUENCE {
num INTEGER,
dir-ind BOOLEAN
}
SPKM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
Wrap-Header ::= SEQUENCE {
tok-id INTEGER (513), -- shall contain 0201 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
conf-alg [1] Conf-Alg OPTIONAL,
snd-seq [2] SeqNum OPTIONAL
}
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
data BIT STRING
}
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] NULL
}
SPKM-DEL ::= SEQUENCE {
del-header Del-Header,
int-cksum BIT STRING
}
Del-Header ::= SEQUENCE {
tok-id INTEGER (769), -- shall contain 0301 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
-- other types --
-- from [RFC-1508] --
MechType ::= OBJECT IDENTIFIER
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken SPKMInnerContextToken
} -- when thisMech is SPKM-1 or SPKM-2
SPKMInnerContextToken ::= CHOICE {
req [0] SPKM-REQ,
rep-ti [1] SPKM-REP-TI,
rep-it [2] SPKM-REP-IT,
error [3] SPKM-ERROR,
mic [4] SPKM-MIC,
wrap [5] SPKM-WRAP,
del [6] SPKM-DEL
}
-- from [RFC-1510] --
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type INTEGER,
ad-data OCTET STRING
}
-- object identifier assignments --
md5-DES-CBC OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
integrity(3) md5-DES-CBC(1)}
sum64-DES-CBC OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
integrity(3) sum64-DES-CBC(2)}
spkm-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) spkm(1) spkm-1(1)}
spkm-2 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) spkm(1) spkm-2(2)}
END
Appendix B: Imported Types
This appendix contains, for completeness, the relevant ASN.1 types
imported from InformationFramework (1993), AuthenticationFramework
(1993), and [PKCS3].
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
-- note that the 1993 InformationFramework module uses
-- different syntax for the above constructs
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence
Name ::= CHOICE { -- only one for now
rdnSequence RDNSequence
}
Certificate ::= SEQUENCE {
certContents CertContents,
algID AlgorithmIdentifier,
sig BIT STRING
} -- sig holds the result of applying the signing procedure
-- specified in algId to the BER-encoded octet string which
-- results from applying the hashing procedure (also specified in
-- algId) to the DER-encoded octets of CertContents
CertContents ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUID [1] IMPLICIT UID OPTIONAL, -- used in v2 only
subjectUID [2] IMPLICIT UID OPTIONAL -- used in v2 only
}
Version ::= INTEGER {v1(0), v2(1)}
CertificateSerialNumber ::= INTEGER
UID ::= BIT STRING
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL
} -- at least one of the pair shall be present
CertificateList ::= SEQUENCE {
certListContents CertListContents,
algId AlgorithmIdentifier,
sig BIT STRING
} -- sig holds the result of applying the signing procedure
-- specified in algId to the BER-encoded octet string which
-- results from applying the hashing procedure (also specified in
-- algId) to the DER-encoded octets of CertListContents
CertListContents ::= SEQUENCE {
signature AlgorithmIdentifier,
issuer Name,
thisUpdate UTCTime,
nextUpdate UTCTime OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime } OPTIONAL
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
} -- note that the 1993 AuthenticationFramework module uses
-- different syntax for this construct
--from [PKCS3] (the parameter to be used with dhKeyAgreement) --
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}