RFC2025 日本語訳
2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October 1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Adams Request for Comments: 2025 Bell-Northern Research Category: Standards Track October 1996
Network Working Group C. Adams Request for Comments: 2025 Bell-Northern Research Category: Standards Track October 1996
The Simple Public-Key GSS-API Mechanism (SPKM)
The Simple Public-Key GSS-API Mechanism (SPKM)
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
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.
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
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. The mechanism described in this document has been proposed to meet this need and to provide the following features.
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. The mechanism described in this document has been proposed to meet this need and to provide the following features.
1) The SPKM allows both unilateral and mutual authentication
to be accomplished without the use of secure timestamps. This
enables environments which do not have access to secure time
to nevertheless have access to secure authentication.
1) The SPKM allows both unilateral and mutual authentication to be accomplished without the use of secure timestamps. This enables environments which do not have access to secure time to nevertheless have access to secure authentication.
2) 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.
2) 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.
3) 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]), rather than an integrity checksum based on a MAC
computed with a symmetric algorithm (e.g., DES). For some
environments, the availability of true digital signatures
supporting non-repudiation is a necessity.
3) 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]), rather than an integrity checksum based on a MAC computed with a symmetric algorithm (e.g., DES). For some environments, the availability of true digital signatures supporting non-repudiation is a necessity.
Adams Standards Track [Page 1] RFC 2025 SPKM October 1996
Adams Standards Track [Page 1] RFC 2025 SPKM October 1996
4) SPKM data formats and procedures are designed to be as similar
to those of the Kerberos mechanism as is practical. This is
done for ease of implementation in those environments where
Kerberos has already been implemented.
4) SPKM data formats and procedures are designed to be as similar to those of 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 flexibility and functionality, without undue complexity or overhead.
For the above reasons, it is felt that the SPKM will offer flexibility and functionality, without undue complexity or overhead.
Key Management
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.
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
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 for implementation- related clarifications, to John Linn of OpenVision Technologies for helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.
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 for implementation- related clarifications, to John Linn of OpenVision Technologies for helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.
1. Overview
1. Overview
The goal of the Generic Security Service Application Program Interface (GSS-API) is stated in the abstract of [RFC-1508] as follows:
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:
"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 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."
- documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms."
Adams Standards Track [Page 2] RFC 2025 SPKM October 1996
Adams Standards Track [Page 2] RFC 2025 SPKM October 1996
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 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 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.
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, whose primary difference is 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.
This document defines two separate GSS-API mechanisms, SPKM-1 and SPKM-2, whose primary difference is 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 Standards Track [Page 3] RFC 2025 SPKM October 1996
Adams Standards Track [Page 3] RFC 2025 SPKM October 1996
2. Algorithms
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).
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):
2.1 Integrity Algorithm (I-ALG):
Purpose:
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.
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:
Examples:
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 4 -- imported from [PKCS1]
}
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 -- imported from [PKCS1] }
This algorithm (MANDATORY) provides data integrity and
authenticity and supports non-repudiation by computing an
RSA signature on the MD5 hash of that data. This is
essentially equivalent to md5WithRSA {1 3 14 3 2 3},
which is defined by OIW (the Open Systems Environment
Implementors' Workshop).
This algorithm (MANDATORY) provides data integrity and authenticity and supports non-repudiation by computing an RSA signature on the MD5 hash of that data. This is essentially equivalent to md5WithRSA {1 3 14 3 2 3}, which is defined by OIW (the Open Systems Environment Implementors' Workshop).
Note that since this is the only integrity/authenticity
algorithm specified to be mandatory at this time, for
interoperability reasons it is also stipulated that
md5WithRSA be the algorithm used to sign all context
establishment tokens which are signed rather than MACed --
see Section 3.1.1 for details. In future versions of this
document, alternate or additional algorithms may be
specified to be mandatory and so this stipulation on the
Note that since this is the only integrity/authenticity algorithm specified to be mandatory at this time, for interoperability reasons it is also stipulated that md5WithRSA be the algorithm used to sign all context establishment tokens which are signed rather than MACed -- see Section 3.1.1 for details. In future versions of this document, alternate or additional algorithms may be specified to be mandatory and so this stipulation on the
Adams Standards Track [Page 4] RFC 2025 SPKM October 1996
Adams Standards Track [Page 4] RFC 2025 SPKM October 1996
context establishment tokens may be removed.
context establishment tokens may be removed.
DES-MAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 10 -- carries length in bits of the MAC as
} -- an INTEGER parameter, constrained to
-- multiples of eight from 16 to 64
DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10 -- carries length in bits of the MAC as } -- an INTEGER parameter, constrained to -- multiples of eight from 16 to 64
This algorithm (RECOMMENDED) provides integrity by computing
a DES MAC (as specified by [FIPS-113]) on that data.
This algorithm (RECOMMENDED) provides integrity by computing a DES MAC (as specified by [FIPS-113]) on that data.
md5-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) integrity(3) md5-DES-CBC(1)
}
md5-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) md5-DES-CBC(1) }
This algorithm provides data integrity by encrypting, using
DES CBC, the "confounded" MD5 hash of that data (see Section
3.2.2.1 for the definition and purpose of confounding).
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 without the confounder the strength
of this integrity mechanism is (at most) equal to the
strength of DES under a known-plaintext attack.
This algorithm provides data integrity by encrypting, using DES CBC, the "confounded" MD5 hash of that data (see Section 3.2.2.1 for the definition and purpose of confounding). 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 without the confounder the strength of this integrity mechanism is (at most) equal to the strength of DES under a known-plaintext attack.
sum64-DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) integrity(3) sum64-DES-CBC(2)
}
sum64-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) sum64-DES-CBC(2) }
This algorithm provides data integrity by encrypting, using
DES CBC, the concatenation of the confounded data and the
sum of all the input data blocks (the sum computed using
addition modulo 2**64 - 1). Thus, in this algorithm,
encryption is a requirement for the integrity to be secure.
This algorithm provides data integrity by encrypting, using DES CBC, the concatenation of the confounded data and the sum of all the input data blocks (the sum computed using addition modulo 2**64 - 1). Thus, in this algorithm, encryption is a requirement for the integrity to be secure.
For comments regarding the security of this integrity
algorithm, see [Juen84, Davi89].
For comments regarding the security of this integrity algorithm, see [Juen84, Davi89].
Adams Standards Track [Page 5] RFC 2025 SPKM October 1996
Adams Standards Track [Page 5] RFC 2025 SPKM October 1996
2.2 Confidentiality Algorithm (C-ALG):
2.2 Confidentiality Algorithm (C-ALG):
Purpose:
Purpose:
This symmetric algorithm is used to generate the encrypted
data for gss_seal() / gss_wrap().
This symmetric algorithm is used to generate the encrypted data for gss_seal() / gss_wrap().
Example:
Example:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV (OCTET STRING) as a parameter;
} -- this (optional) parameter is unused in
-- SPKM due to the use of confounding
DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV (OCTET STRING) as a parameter; } -- this (optional) parameter is unused in -- SPKM due to the use of confounding
This algorithm is RECOMMENDED.
This algorithm is RECOMMENDED.
2.3 Key Establishment Algorithm (K-ALG):
2.3 Key Establishment Algorithm (K-ALG):
Purpose:
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.
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.
Examples:
Examples:
RSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1 -- imported from [PKCS1] and [RFC-1423]
}
RSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 -- imported from [PKCS1] and [RFC-1423] }
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.
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.
id-rsa-key-transport OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 22 -- imported from [X9.44]
}
id-rsa-key-transport OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 22 -- imported from [X9.44] }
Similar to RSAEncryption, but source authenticating info.
is also encrypted with the target's RSA public key.
Similar to RSAEncryption, but source authenticating info. is also encrypted with the target's RSA public key.
Adams Standards Track [Page 6] RFC 2025 SPKM October 1996
Adams Standards Track [Page 6] RFC 2025 SPKM October 1996
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
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)).
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)).
2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:
2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:
Purpose:
Purpose:
Having established a context key using the negotiated K-ALG,
both initiator and target must be able to derive a set of
subkeys for the various C-ALGs and keyed I-ALGs supported over
the context. Let the (ordered) list of agreed C-ALGs be
numbered consecutively, so that the first algorithm (the
"default") is numbered "0", the next is numbered "1", and so
on. Let the numbering for the (ordered) list of agreed I-ALGs
be identical. Finally, let the context key be a binary string
of arbitrary length "M", subject to the following constraint:
L <= M <= U (where the lower limit "L" is the bit length of
the longest key needed by any agreed C-ALG or keyed I-ALG, and
the upper limit "U" is the largest bit size which will fit
within the K-ALG parameters).
Having established a context key using the negotiated K-ALG, both initiator and target must be able to derive a set of subkeys for the various C-ALGs and keyed I-ALGs supported over the context. Let the (ordered) list of agreed C-ALGs be numbered consecutively, so that the first algorithm (the "default") is numbered "0", the next is numbered "1", and so on. Let the numbering for the (ordered) list of agreed I-ALGs be identical. Finally, let the context key be a binary string of arbitrary length "M", subject to the following constraint: L <= M <= U (where the lower limit "L" is the bit length of the longest key needed by any agreed C-ALG or keyed I-ALG, and the upper limit "U" is the largest bit size which will fit within the K-ALG parameters).
For example, if DES and two-key-triple-DES are the negotiated
confidentiality algorithms and DES-MAC is the negotiated keyed
integrity algorithm (note that digital signatures do not use a
context key), then the context key must be at least 112 bits
long. If 512-bit RSAEncryption is the K-ALG in use then the
originator can randomly generate a context key of any greater
length up to 424 bits (the longest allowable RSA input
specified in [PKCS-1]) -- the target can determine the length
which was chosen by removing the padding bytes during the RSA
decryption operation. On the other hand, if dhKeyAgreement is
the K-ALG in use then the context key is the result of the
Diffie-Hellman computation (with the exception of the high-
order byte, which is discarded for security reasons), so that
its length is that of the Diffie-Hellman modulus, p, minus 8
bits.
For example, if DES and two-key-triple-DES are the negotiated confidentiality algorithms and DES-MAC is the negotiated keyed integrity algorithm (note that digital signatures do not use a context key), then the context key must be at least 112 bits long. If 512-bit RSAEncryption is the K-ALG in use then the originator can randomly generate a context key of any greater length up to 424 bits (the longest allowable RSA input specified in [PKCS-1]) -- the target can determine the length which was chosen by removing the padding bytes during the RSA decryption operation. On the other hand, if dhKeyAgreement is the K-ALG in use then the context key is the result of the Diffie-Hellman computation (with the exception of the high- order byte, which is discarded for security reasons), so that its length is that of the Diffie-Hellman modulus, p, minus 8 bits.
Adams Standards Track [Page 7] RFC 2025 SPKM October 1996
Adams Standards Track [Page 7] RFC 2025 SPKM October 1996
The derivation algorithm for a k-bit subkey is specified as
follows:
The derivation algorithm for a k-bit subkey is specified as follows:
rightmost_k_bits (OWF(context_key || x || n || s || context_key))
rightmost_k_bits (OWF(context_key || x || n || s || context_key))
where
where
- "x" is the ASCII character "C" (0x43) if the subkey is
for a confidentiality algorithm or the ASCII character "I"
(0x49) if the subkey is for a keyed integrity algorithm;
- "n" is the number of the algorithm in the appropriate agreed
list for the context (the ASCII character "0" (0x30), "1"
(0x31), and so on);
- "s" is the "stage" of processing -- always the ASCII
character "0" (0x30), unless "k" is greater than the output
size of OWF, in which case the OWF is computed repeatedly
with increasing ASCII values of "stage" (each OWF output
being concatenated to the end of previous OWF outputs),
until "k" bits have been generated;
- "||" is the concatenation operation; and
- "OWF" is any appropriate One-Way Function.
- "x" is the ASCII character "C" (0x43) if the subkey is for a confidentiality algorithm or the ASCII character "I" (0x49) if the subkey is for a keyed integrity algorithm; - "n" is the number of the algorithm in the appropriate agreed list for the context (the ASCII character "0" (0x30), "1" (0x31), and so on); - "s" is the "stage" of processing -- always the ASCII character "0" (0x30), unless "k" is greater than the output size of OWF, in which case the OWF is computed repeatedly with increasing ASCII values of "stage" (each OWF output being concatenated to the end of previous OWF outputs), until "k" bits have been generated; - "||" is the concatenation operation; and - "OWF" is any appropriate One-Way Function.
Examples:
Examples:
MD5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 5
}
MD5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }
This algorithm is MANDATORY.
This algorithm is MANDATORY.
SHA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 18
}
SHA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 }
It is recognized that existing hash functions may not satisfy
all required properties of OWFs. This is the reason for
allowing negotiation of the O-ALG OWF during the context
establishment process (see Section 2.5), since in this way
future improvements in OWF design can easily be accommodated.
For example, in some environments a preferred OWF technique
might be an encryption algorithm which encrypts the input
specified above using the context_key as the encryption key.
It is recognized that existing hash functions may not satisfy all required properties of OWFs. This is the reason for allowing negotiation of the O-ALG OWF during the context establishment process (see Section 2.5), since in this way future improvements in OWF design can easily be accommodated. For example, in some environments a preferred OWF technique might be an encryption algorithm which encrypts the input specified above using the context_key as the encryption key.
Adams Standards Track [Page 8] RFC 2025 SPKM October 1996
Adams Standards Track [Page 8] RFC 2025 SPKM October 1996
2.5 Negotiation:
2.5 Negotiation:
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.
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.
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).
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.
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.
Finally, in the first context establishment token the initiator offers a set of possible O-ALGs (only a single O-ALG if no response is expected). The (single) O-ALG chosen by the target becomes the subkey derivation algorithm OWF to be used over the context.
Finally, in the first context establishment token the initiator offers a set of possible O-ALGs (only a single O-ALG if no response is expected). The (single) O-ALG chosen by the target becomes the subkey derivation algorithm OWF to be used over the context.
In future versions of SPKM, other algorithms may be specified for any or all of I-ALG, C-ALG, K-ALG, and O-ALG.
In future versions of SPKM, other algorithms may be specified for any or all of I-ALG, C-ALG, K-ALG, and O-ALG.
Adams Standards Track [Page 9] RFC 2025 SPKM October 1996
Adams Standards Track [Page 9] RFC 2025 SPKM October 1996
3. Token Formats
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].
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 {spkm spkm-1(1)}
or {spkm spkm-2(2)}, where spkm has the value {iso(1) identified-
organization(3) dod(6) internet(1) security(5) mechanisms(5)
spkm(1)}. 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).
The SPKM GSS-API mechanism will be identified by an Object Identifier representing "SPKM-1" or "SPKM-2", having the value {spkm spkm-1(1)} or {spkm spkm-2(2)}, where spkm has the value {iso(1) identified- organization(3) dod(6) internet(1) security(5) mechanisms(5) spkm(1)}. 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.
Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined.
3.1. Context Establishment Tokens
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() or gss_accept_sec_context(), and potentially consumed by calls to gss_init_sec_context() or gss_accept_sec_context().
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() or gss_accept_sec_context(), and potentially consumed by calls to gss_init_sec_context() or gss_accept_sec_context().
Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows:
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
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
Adams Standards Track [Page 10] RFC 2025 SPKM October 1996
Adams Standards Track [Page 10] RFC 2025 SPKM October 1996
When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as follows:
When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as follows:
SPKMInnerContextToken ::= CHOICE {
req [0] SPKM-REQ,
rep-ti [1] SPKM-REP-TI,
rep-it [2] SPKM-REP-IT,
error [3] SPKM-ERROR,
mic [4] SPKM-MIC,
wrap [5] SPKM-WRAP,
del [6] SPKM-DEL
}
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 }
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 exchange. While not required by RFC-1508, this enables
implementations to perform enhanced error-checking. The tag values
provided in SPKMInnerContextToken ("[0]" through "[6]") specify a
token-id for each token; similar information is contained in each
token's tok-id field. While seemingly redundant, the tag value and
tok-id actually perform different tasks: the tag ensures that
InitialContextToken can be properly decoded; tok-id ensures, among
other things, that data associated with the per-message tokens is
cryptographically linked to the intended token type. Every
innerContextToken also includes a context-id field; see Section 6 for
a discussion of both token-id and context-id information and their
use in an SPKM support function).
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 exchange. While not required by RFC-1508, this enables implementations to perform enhanced error-checking. The tag values provided in SPKMInnerContextToken ("[0]" through "[6]") specify a token-id for each token; similar information is contained in each token's tok-id field. While seemingly redundant, the tag value and tok-id actually perform different tasks: the tag ensures that InitialContextToken can be properly decoded; tok-id ensures, among other things, that data associated with the per-message tokens is cryptographically linked to the intended token type. Every innerContextToken also includes a context-id field; see Section 6 for a discussion of both token-id and context-id information and their use in an SPKM support function).
The innerContextToken field of context establishment tokens for the SPKM GSS-API mechanism will contain one of the following messages: SPKM-REQ; SPKM-REP-TI; SPKM-REP-IT; and SPKM-ERROR. Furthermore, all innerContextTokens are encoded using ASN.1 BER (constrained, in the interests of parsing simplicity, to the DER subset defined in [X.509], clause 8.7).
SPKM GSS-APIメカニズムのための文脈設立象徴のinnerContextToken分野は以下のメッセージの1つを含むでしょう: SPKM-REQ。 SPKMレップTI。 SPKMレップIT。 そして、SPKM-誤り。 その上、すべてのinnerContextTokensが、ASN.1BER(簡単さを分析することのために、[X.509]、8.7番目の節で定義されたDER部分集合に抑制される)を使用することでコード化されます。
The SPKM context establishment tokens are defined according to [X.509] Section 10 and are compatible with [9798]. 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 Authentication", 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 authentication is requested by the initiator.
SPKM文脈設立象徴は、[X.509]セクション10に従って定義されて、[9798]と互換性があります。 SPKM-1(乱数)はセクション10.3、目標の一方的な認証を創始者に実行するときの「両用認証」、および用途セクション10.4、「3者間の認証」を使用します、互いの認証が創始者によって要求されているとき。 SPKM-2(タイムスタンプ)はセクション10.2、創始者の一方的な認証を目標に実行するときの「片道認証」、および用途セクション10.3、「両用認証」を使用します、互いの認証が創始者によって要求されているとき。
Adams Standards Track [Page 11] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[11ページ]。
The implication of the previous paragraph is that for SPKM-2 unilateral authentication no negotiation of K-ALG can be done (the target either accepts the K-ALG and context 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). Alternatively, 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 context key.
前のパラグラフの含意はSPKM-2の一方的な認証において、K-ALGの交渉が全くできないという(目標は、創始者によって与えられたK-ALGと文脈キーを受け入れるか、または文脈を禁じます)ことです。 SPKM-2の互いの、または、SPKM-1一方的な認証に、何らかの交渉が可能ですが、目標はK-ALGsが創始者で提供した1パスの中で選ばれることができるだけです(文脈を禁じてください)。 あるいはまた、創始者は、目標が文脈キーを発生して、送るよう要求できます。 SPKM-1の互いの認証において、目標は、創始者によって提供されたどんな1かツー・パスK-ALGも選ぶことができて、再び文脈キーを発生して、送るよう要求できます。
It is envisioned that typical use of SPKM-1 or SPKM-2 will involve mutual authentication. Although unilateral authentication is available for both mechanisms, its use is not generally recommended.
そんなに典型的に思い描かれて、SPKM-1かSPKM-2の使用が互いの認証にかかわるということです。 一方的な認証は両方のメカニズムに利用可能ですが、一般に、使用は推薦されません。
3.1.1. Context Establishment Tokens - Initiator (first token)
3.1.1. 文脈設立象徴--創始者(最初の象徴)
In order to accomplish context establishment, it may be necessary that both the initiator and the target have access to the other partys 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 environments 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.
文脈設立を実行するために、創始者と目標の両方が他のpartys公開カギ証明書に近づく手段を持っているのが必要であるかもしれません。 いくつかの環境で、創始者は、最初の象徴の目標にすべての証明書を入手して、関連ものを送るのを選ぶかもしれません。 他の環境で、創始者が、目標が応答象徴で証明書データを送るよう要求するかもしれませんか、またはそれぞれの側は個別にそれが必要とする証明書データを得るかもしれません。 どのような場合でも、しかしながら、SPKM実現には、供給されたNameに一致している証明書を入手する能力がなければなりません。 これを達成するのに使用されるべき実際のメカニズムは、ローカルの実現問題であり、したがって、この仕様の範囲の外にあります。
Relevant SPKM-REQ syntax is as follows (note that imports from other documents are given in Appendix A):
関連SPKM-REQ構文は以下の通りです(他のドキュメントからの輸入がAppendix Aで与えられていることに注意してください):
SPKM-REQ ::= SEQUENCE {
requestToken REQ-TOKEN,
certif-data [0] CertificationData OPTIONAL,
auth-data [1] AuthorizationData OPTIONAL
-- see [RFC-1510] for a discussion of auth-data
}
SPKM-REQ:、:= 系列requestToken REQ-TOKEN、certif-データ[0]CertificationData OPTIONAL、auth-データ[1]AuthorizationData OPTIONAL--auth-データの議論に関して[RFC-1510]を見てください。
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath OPTIONAL,
certificateRevocationList [1] CertificateList OPTIONAL
} -- at least one of the above shall be present
CertificationData:、:= SEQUENCE、certificationPath[0]CertificationPath OPTIONAL、certificateRevocationList[1]CertificateList OPTIONAL--、少なくとも上の1つは存在するでしょう。
Adams Standards Track [Page 12] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[12ページ]。
CertificationPath ::= SEQUENCE {
userKeyId [0] OCTET STRING OPTIONAL,
-- identifier for user's public key
userCertif [1] Certificate OPTIONAL,
-- certificate containing user's public key
verifKeyId [2] OCTET STRING OPTIONAL,
-- identifier for user's public verification key
userVerifCertif [3] Certificate OPTIONAL,
-- certificate containing user's public verification key
theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
} -- certification path from target to source
CertificationPath:、:= SEQUENCE、ユーザの公共の検証の主要なtheCACertificates[4]SEQUENCE OF CertificatePair OPTIONALを含むverifKeyId[2]OCTET STRING OPTIONAL(ユーザの公共の検証の主要なuserVerifCertif[3]証明書OPTIONALのための識別子)が証明するユーザの公開鍵を含むOCTET STRING OPTIONAL(ユーザの公開鍵userCertif[1]証明書OPTIONALのための識別子)が証明するuserKeyId[0]--、目標からソースまでの証明経路
Having separate verification fields allows different key pairs (possibly corresponding to different algorithms) to be used for encryption/decryption and signing/verification. Presence of [0] or [1] and absence of [2] and [3] implies that the same key pair is to be used for enc/dec and verif/signing (note that this practice is not typically recommended). Presence of [2] or [3] implies that a separate key pair is to be used for verif/signing, and so [0] or [1] must also be present. Presence of [4] implies that at least one of [0], [1], [2], and [3] must also be present.
別々の検証分野を持っているのは、異なった主要な組(ことによると異なったアルゴリズムに対応する)が暗号化/復号化と調印/検証に使用されるのを許容します。 同じ主要な組は、enc/DEC社とverifに使用されるつもりであるか、または[0]か[1]の存在と[2]と[3]の不在はサインすることになっているつもりです(この習慣が通常推薦されないことに注意してください)。 [2]か[3]の存在は、また、別々の主要な組がverifに使用されることになっているか、またはサインすることになっているので[0]か[1]も存在していなければならないのを含意します。 [4]の存在は[0]についてそんなに少なくとも1つを含意します、また、[1]、[2]、および[3]も存在していなければなりません。
REQ-TOKEN ::= SEQUENCE {
req-contents Req-contents,
algId AlgorithmIdentifier,
req-integrity Integrity -- "token" is Req-contents
}
REQ-象徴:、:= 系列req-コンテンツReq-コンテンツ、algId AlgorithmIdentifier、req-保全Integrity--、「象徴」はReq-コンテンツです。
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" (note that for MAC, algId must be one of the integrity
-- algorithms offered by the initiator with the appropriate subkey
-- derived from the context key (see Section 2.4) used as the key
-- input)
保全:、:= BIT STRING--、algIdが論じ尽くす手順(また、中では、algIdを指定する)を適用するのからの「保全」が調印手順を適用するという結果を保持するというalgIdで結果として生じるBERによってコード化された八重奏ストリングに指定された調印アルゴリズムを指定する対応--「象徴」のDERによってコード化された八重奏。 -- あるいはまた、対応するalgIdがMACingを指定するなら(アルゴリズム、「保全」はMACingを適用するという結果を保持します)手順がalgIdでDERによってコード化された八重奏に指定した、--、「象徴」(MACに関して、algIdがキーとして使用される文脈キー(セクション2.4を見る)から得られた保全(適切なサブキーで創始者によって提供されたアルゴリズム)の1つであるに違いないことに注意してください--入力)
It is envisioned that typical use of the Integrity field for each of REQ-TOKEN, REP-TI-TOKEN, and REP-IT-TOKEN will be a true digital signature, providing unilateral or mutual authentication along with replay protection, as required. However, there are situations in which the MAC choice will be appropriate. One example is the case in which the initiator wishes to remain anonymous (so that the first, or
それはIntegrity分野のそれぞれのREQ-TOKENの思い描かれたそんなに典型的な使用です、REP-TI-TOKEN、そして、REP IT TOKENが本当のデジタル署名になるでしょう、必要に応じて反復操作による保護に伴う一方的であるか互いの認証を提供して。 しかしながら、MAC選択が適切になる状況があります。 または1つの例が創始者が匿名を希望する場合である、(1番目。
Adams Standards Track [Page 13] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[13ページ]。
first and third, token(s) will be MACed and the second token will be signed). Another example is the case in which a previously authenticated, established, and cached context is being re- established at some later time (here all exchanged tokens will be MACed).
象徴があるMACedと秒がサインされていたなら(s)がそうする1番目と3番目、象徴) 別の例は以前に、認証されて、確立して、キャッシュされた関係が何らかの後の時間に再確立される予定である場合(ここで、すべての交換された象徴がMACedになる)です。
The primary advantage of the MAC choice is that it reduces processing overhead for cases in which either authentication is not required (e.g., anonymity) or authentication is established by some other means (e.g., ability to form the correct MAC on a "fresh" token in context re-establishment).
MAC選択の第一の利点は認証が必要でない(例えば、匿名)、またはある他の手段(例えば、文脈再建で「新鮮な」象徴に正しいMACを形成する能力)で認証が確立される場合のために処理のオーバーヘッドを減らすということです。
Req-contents ::= SEQUENCE {
tok-id INTEGER (256), -- shall contain 0100(hex)
context-id Random-Integer, -- see Section 6.3
pvno BIT STRING, -- protocol version number
timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2
randSrc Random-Integer,
targ-name Name,
src-name [0] Name OPTIONAL,
-- must be supplied unless originator is "anonymous"
req-data Context-Data,
validity [1] Validity OPTIONAL,
-- validity interval for key (may be used in the
-- computation of security context lifetime)
key-estb-set Key-Estb-Algs,
-- specifies set of key establishment algorithms
key-estb-req 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 satisfy the key length constraints
-- specified in Section 2.4.
key-src-bind OCTET STRING OPTIONAL
-- Used to bind the source name to the symmetric key.
-- 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 MD5 (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.
}
Req-コンテンツ:、:= 系列tok-イドINTEGER(256)--0100年の(十六進法)文脈イドRandom-整数を含むでしょう--キーのためにセクション6.3 pvno BIT STRING--Nameが、0Name OPTIONAL--創始者が「匿名」のreq-データContext-データでないなら供給しなければならないとsrcにSPKM-2 randSrc Random-整数にちなんで命名するようにtargに命名して、正当性が1Validity OPTIONALであることが義務的なプロトコルバージョン数のタイムスタンプUTCTime OPTIONAL--正当性間隔を見てください、(使用されるかもしれない、--セキュリティ文脈生涯の計算) 主要なestbセットKey-Estb-Algs; 主要な設立アルゴリズムキー-estb-req BIT STRING OPTIONAL主要なestb(セットで最初に、K-ALGに対応するパラメタ)のセットが指定する、(創始者が不本意であるなら使用されない、--、狙う主要な材料を発生して、しっかりと伝えてください); 使用中のK-ALGが満たさないなら、確立したキーは--セクション2.4主要なsrcひものOCTET STRING OPTIONALで指定されて、ソース名を対称鍵に縛るのに使用されたというキー長規制この分野はSPKM-2に関するケースのために存在していなければなりません--(一方的なauthen)を満たさなければなりません。 以下の通り、: 「srcである」ところのMD5(src| | 文脈_キー)はそうです。そして、「提供してください--そのような結合(しかし、他のすべてのケースにおいて、任意である)--八重奏ストリングが適用するという結果を保持する、--、義務的な論じ尽くす手順MD5、(MANDATORY I-ALGで;、--、セクション2.1を見てください)、src-名前のDERによってコード化された八重奏--「文脈キー」が対称鍵(すなわち、--伝えられるものに関する保護のないバージョン--主要なestb-req)である、」 | | 」 連結演算はそうですか?
Adams Standards Track [Page 14] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[14ページ]。
-- 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 version -- of REQ-TOKEN must correspond to the highest bit set in 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).
-- プロトコルバージョン番号(pvno)パラメタは創始者(1プロトコルあたり1ビット--バージョン)で--すべてのSPKMプロトコルを指定するのに必要な多くのビットとしての用途--バージョンが支持したBIT STRINGです。 このドキュメントによって指定されたプロトコルはバージョン0です。 -- したがって、このバージョンが支持されるなら、pvnoのビット0は設定されます。 -- 同様に、バージョン1(将来定義されるなら)が設定されるなら、ビット1は設定されます--支持されていて、とてもオンです。 一方的な認証によってそれに注意してください--SPKM-2を使用して、応答象徴が全く文脈--設立の間、予想されないので、議定書交渉は全く行われることができません。 中、これ--ケース、創始者はちょうどpvnoの1ビットを設定しなければなりません。 バージョン--REQ-TOKEN必須では、pvnoに設定される中で最も高いビットに対応してください。 -- SPKMの唯一の道中に上がある「正当性」パラメタ--伝える創始者は目標への文脈生涯を望んでいました。 -- 以来に、創始者と目標がそうしたのを保証できません--連動している時間、「正当性」で指定された時間の長さがそうである、--、決定的であるとして取ってください(これで与えられた実際の時勢よりむしろ--、パラメタ)
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. -- There are no cryptographic requirements on this random number -- (i.e., it need not be unpredictable, it simply needs to be fresh).
-- それぞれのSPKM実現は「新鮮」を発生させるのに原因となります--文脈設立の目的のための乱数 それはそうです。--以前に使用されていない(高い確率で)もの。 -- この乱数に関するどんな暗号の要件もありません。--(すなわち、予測できません、新鮮であることが単に必要であるということである必要はありません。)
Context-Data ::= SEQUENCE {
channelId ChannelId OPTIONAL, -- channel bindings
seq-number INTEGER OPTIONAL, -- sequence number
options Options,
conf-alg Conf-Algs, -- confidentiality. algs.
intg-alg Intg-Algs, -- integrity algorithm
owf-alg OWF-Algs -- for subkey derivation
}
文脈データ:、:= 系列channelId ChannelId OPTIONAL--チャンネル結合seq-数のINTEGER OPTIONAL--一連番号オプションOptions、サブキー派生のためのconf-alg Conf-Algs--秘密性algs. intg-alg Intg-Algs--保全アルゴリズムowf-alg OWF-Algs
ChannelId ::= OCTET STRING
ChannelId:、:= 八重奏ストリング
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
}
オプション:、:= ビット列(0)、互いの州の(1)、再生det州の(2)--再生detに使用されると代表団で述べてください。文脈系列状態の間、(3)(文脈conf-利益(4)、integ-利益(5)、データが必要とした目標certif(6)の間の配列のために、使用される)は要求targのcertifに. データを使用しました。
Adams Standards Track [Page 15] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[15ページ]。
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL
-- used when conf. is not available over context
} -- for C-ALG (see Section 5.2 for discussion of QOP)
Conf-Algs:、:= CHOICE、algs[0]SEQUENCE OF AlgorithmIdentifier、ヌル[1]NULL--confであるときに、使用される、文脈の上で利用可能でない、C-ALG(QOPの議論に関してセクション5.2を見ます)
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
-- for I-ALG (see Section 5.2 for discussion of QOP)
Intg-Algs:、:= I-ALGのためのAlgorithmIdentifierの系列(QOPの議論に関してセクション5.2を見ます)
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
-- Contains exactly one algorithm in REQ-TOKEN for SPKM-2
-- unilateral, and contains at least one algorithm otherwise.
-- Always contains exactly one algorithm in REP-TOKEN.
OWF-Algs:、:= SEQUENCE OF AlgorithmIdentifier--SPKM-2のためのREQ-TOKENにまさに1つのアルゴリズムを含んでいます--、一方的である、そうでなければ、少なくとも1つのアルゴリズムを含んでいます。 -- REP-TOKENにいつもまさに1つのアルゴリズムを含んでいます。
Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
-- to allow negotiation of K-ALG
主要なEstb-Algs:、:= SEQUENCE OF AlgorithmIdentifier--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).
互いのreqビットがgss_イニット_秒_文脈()へのアプリケーションの呼び出しで設定されないと、SPKMに基づく文脈設立系列は一方的な認証を実行するでしょう。 SPKM-REQだけを使用することで(その結果、目標に創始者を認証します)SPKM-2はこれを達成します、SPKM-REQとSPKM-REP-TIの両方を使用することで(その結果、創始者に目標を認証します)SPKM-1はこれを達成しますが。
Applications requiring authentication of both peers (initiator as well as target) must request mutual authentication, resulting in "mutual-state" being set within SPKM-REQ Options. In response to such a request, the context target will reply to the initiator with an SPKM-REP-TI token. If 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 an SPKM-REP-IT token, completing the (random-number-based) mutual authentication context establishment exchange.
両方の同輩(目標と同様に創始者)の認証を必要とするアプリケーションは互いの認証を要求しなければなりません、SPKM-REQ Optionsの中に設定される「互いの状態」をもたらして。 そのような要求に対応して、文脈目標はSPKM-REP-TI象徴で創始者に答えるでしょう。 メカニズムSPKM-2が選ばれたなら、これは(タイムスタンプベース)の互いの認証文脈設立交換を終了します。 メカニズムSPKM-1を選んで、SPKM-REP-TIを送ると、創始者はSPKM-REP-IT象徴で目標に答えるでしょう、(無作為の数のベース)の互いの認証文脈設立交換を終了して。
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.
Context-データのOptions分野の他のビットはRFC-1508で説明されます、データが必要とした目標certifを除いて。(創始者はTRUEに目標がSPKM-REP-TI象徴で証明データを返すよう要求するようにcertifを設定します)。 SPKM-2(SPKM-REP-TI象徴は全くそこで組み立てられない)での一方的な認証において、このオプションビットは創始者と目標の両方によって無視されます。
Adams Standards Track [Page 16] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[16ページ]。
3.1.2. Context Establishment Tokens - Target
3.1.2. 文脈設立象徴--目標
SPKM-REP-TI ::= SEQUENCE {
responseToken REP-TI-TOKEN,
certif-data CertificationData OPTIONAL
-- included if target-certif-data-required option was
-- set to TRUE in SPKM-REQ
}
SPKMレップTI:、:= 系列responseToken REP-TI-TOKEN(certif-データCertificationData OPTIONAL(目標certifデータが必要なオプションが含まれていたなら、含まれている))はSPKM-REQにTRUEにセットしました。
REP-TI-TOKEN ::= SEQUENCE {
rep-ti-contents Rep-ti-contents,
algId AlgorithmIdentifier,
rep-ti-integ Integrity -- "token" is Rep-ti-contents
}
レップTI象徴:、:= 系列レップtiコンテンツRep-ti-コンテンツ、algId AlgorithmIdentifier、レップ-ti-integ Integrity--、「象徴」はRep-ti-コンテンツです。
Rep-ti-contents ::= SEQUENCE {
tok-id INTEGER (512), -- shall contain 0200 (hex)
context-id Random-Integer, -- see Section 6.3
pvno [0] BIT STRING OPTIONAL, -- prot. version number
timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2
randTarg Random-Integer,
src-name [1] Name OPTIONAL,
-- must contain whatever value was supplied in REQ-TOKEN
targ-name Name,
randSrc Random-Integer,
rep-data Context-Data,
validity [2] Validity OPTIONAL,
-- validity interval for key (used if the target can only
-- support a shorter context lifetime than was offered in
-- REQ-TOKEN)
key-estb-id AlgorithmIdentifier OPTIONAL,
-- used if target is changing key estb. algorithm (must be
-- a member of initiators key-estb-set)
key-estb-str BIT STRING OPTIONAL
-- contains (1) the response to the initiators
-- key-estb-req (if init. used a 2-pass K-ALG), or (2) the
-- key-estb-req corresponding to the K-ALG supplied in
-- above key-estb-id, or (3) the key-estb-req corresponding
-- to the first K-ALG supplied in initiator's key-estb-id,
-- if initiator's (OPTIONAL) key-estb-req was not used
-- (target's key-estb-str must be present in this case).
-- Established key must satisfy the key length constraints
-- specified in Section 2.4.
}
レップtiコンテンツ:、:= 系列tok-イドINTEGER(512)--0200年の(十六進法)文脈イドRandom-整数を含むでしょう--SPKM-2 randTarg Random-整数に義務的なセクション6.3pvno0BIT STRING OPTIONAL(protバージョン数のタイムスタンプUTCTime OPTIONAL)、src-名前1Name OPTIONALを見てください; いかなる値も供給されたコネがName、randSrc Random-整数、レップデータContext-データ、正当性を2Validity OPTIONALとREQ-TOKEN targ命名するということであったとしても、含まなければなりません--、主要な(缶専用--目標であるなら使用されて、中に提供したより短い文脈生涯を支持してください--REQ-TOKEN)という主要なestbイドAlgorithmIdentifier OPTIONALのための正当性間隔; 目標が主要なestbアルゴリズムを変えることであるなら使用される、((1) 創始者への主要なestb-req(イニット中古のa2パスのK-ALGであるなら)の応答、(2) --中に供給されたK-ALGに対応する主要なestb-req--上の主要なestbイド、または(3) 主要なestb-req文通を創始者の(OPTIONAL)がkeするなら創始者の主要なestbイドで供給された最初のK-ALGに含まなければなりません(創始者重要estbセット) 主要なestb-str BIT STRING OPTIONALのメンバー)。y-estb-reqは使用されませんでした。--(目標の主要なestb-strはこの場合存在していなければなりません) . --確立したキーはキー長規制を満たさなければなりません--セクション2.4では、指定されます。
Adams Standards Track [Page 17] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[17ページ]。
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. Finally, if the initiator and target do have one or more versions in common but the version of the REQ-TOKEN received is not supported by the target, a REP-TOKEN must be sent with a desired version bit set in pvno (and dummy values used for all subsequent token fields). The initiator can then respond with a new REQ-TOKEN of the proper version (essentially starting context establishment anew).
プロトコルバージョン番号(pvno)パラメタは創始者によって提供されたただ一つのSPKMプロトコルバージョンを指定するのに必要なだけのビットを使用するBIT STRINGです(目標(プロトコルバージョンあたり1ビット)によって支持されます)。 すなわち、目標はちょうどpvnoの1ビットを設定します。 文脈が決してそうでない返されたそうが確立していて、創始者によって提供されたバージョンのいずれも支持されないなら、目標、aは象徴必須を削除します。 創始者のpvnoが1ビットだけを設定させて、目標がたまたまこのプロトコルバージョンを支持するなら、文脈の上でこのバージョンを使用します、そして、REP- TOKENのpvnoパラメタを省略できます。 最終的に、創始者と目標が1つ以上のバージョンが共通ですが、目標で受け取られたREQ-TOKENのバージョンを支持しないなら、pvnoに設定された必要なバージョンビットでREP-TOKENを送らなければなりません(ダミーの値はすべてのその後の象徴に分野を使用しました)。 次に、創始者が適切なバージョンの新しいREQ-TOKENと共に応じることができる、(本質的には始めの文脈設立、新たに)
3.1.3. Context Establishment Tokens - Initiator (second token)
3.1.3. 文脈設立象徴--創始者(2番目の象徴)
Relevant SPKM-REP-IT syntax is as follows:
関連SPKM-REP-IT構文は以下の通りです:
SPKM-REP-IT ::= SEQUENCE {
responseToken REP-IT-TOKEN,
algId AlgorithmIdentifier,
rep-it-integ Integrity -- "token" is REP-IT-TOKEN
}
SPKMレップIT:、:= 系列responseToken REP IT TOKEN、algId AlgorithmIdentifier、レップ、それ、integ Integrity、--「象徴」が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, -- the targ-name specified in REP-TI
src-name Name OPTIONAL,
-- must contain whatever value was supplied in REQ-TOKEN
key-estb-rep BIT STRING OPTIONAL
-- contains the response to targets key-estb-str
-- (if target selected a 2-pass K-ALG)
}
レップIT象徴:、:= 系列tok-イドINTEGER(768)--0300年の(十六進法)文脈イドRandom-整数を含む、randSrc Random-整数、randTarg Random-整数はNameをtarg命名します(目標が2パスのK-ALGを選択したなら)--REQ-TOKEN主要なestbレップBIT STRING OPTIONALでREP-TI src-名前Name OPTIONALで指定されたtarg-名前--どんな値も含まなければならないのを供給しました(estb-strである状態で主要な目標への応答を含んでいます)。
3.1.4. Error Token
3.1.4. 誤り象徴
The syntax of SPKM-ERROR is as follows:
SPKM-ERRORの構文は以下の通りです:
SPKM-ERROR ::= SEQUENCE {
error-token ERROR-TOKEN,
algId AlgorithmIdentifier,
integrity Integrity -- "token" is ERROR-TOKEN
SPKM-誤り:、:= SEQUENCE、誤り象徴ERROR-TOKEN、algId AlgorithmIdentifier、保全Integrity--、「象徴」はERROR-TOKENです。
Adams Standards Track [Page 18] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[18ページ]。
}
}
ERROR-TOKRN ::= SEQUENCE {
tok-id INTEGER (1024), -- shall contain 0400 (hex)
context-id Random-Integer
}
誤り-TOKRN:、:= 系列tok-イドINTEGER(1024)--0400年の(十六進法)文脈イドRandom-整数を含むでしょう。
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().
SPKM-ERROR象徴は文脈設立の過程だけの間使用されます。 SPKM-REQかSPKM-REP-TIであるなら象徴を間違って受け取ります、受信機能。(gss_イニット_秒_文脈()かgss_のどちらかが_())が同輩(同輩がまだ文脈設立の過程にあるなら)に送るためにSPKM-ERROR象徴を発生させる秒_文脈を受け入れて、CONTINUE_が必要としたGSS_S_を返すでしょう。 他方では、文脈設立応答が全く同輩から予想されないと(すなわち、同輩は文脈設立を終了しました)、機能は_GSS_SPKM_S SG_CONTEXT_ESTB_ABORTの小さい方の状態に伴う適切な主要なステータスコード(例えば、GSS_S_BAD_SIG)を返すでしょう、そして、すべての文脈関連している情報が削除されるでしょう。 出力象徴は、SPKM-ERROR象徴ではありませんが、代わりにSPKM-DEL同輩のgss_過程_文脈_象徴()によって処理される象徴になるでしょう。
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.)
gss_イニット_秒_文脈()が誤り象徴を受けると(有効であるか、または無効であることにかかわらず)、それは、出力象徴としてSPKM-REQを作り直して、CONTINUE_が必要としたGSS_S_の主要なステータスコードを返すでしょう。 (SPKM-REP-IT象徴を予想しているとき同輩のgss_が_秒_文脈()を受け入れるならSPKM-REQ象徴を受ける注意、それはSPKM-REQを無視して、_GSS_S CONTINUE_の主要な状態が必要である状態でゼロ・レングス出力象徴を返すでしょう。)
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.
gss_が受け入れるなら同様に、_秒_文脈()が誤り象徴を受けて(有効であるか、または無効であることにかかわらず)、それは、出力象徴としてSPKM-REP-TIを作り直して、CONTINUE_が必要としたGSS_S_の主要なステータスコードを返すでしょう。
md5WithRsa is currently stipulated for the signing of context establishment tokens. Discrepancies involving modulus bitlength can be resolved through judicious use of the SPKM-ERROR token. The context initiator signs REQ-TOKEN using the strongest RSA it supports (e.g., 1024 bits). If the target is unable to verify signatures of this length, it sends SPKM-ERROR signed with the strongest RSA that it supports (e.g. 512).
md5WithRsaは現在、文脈設立象徴の調印のために規定されています。 SPKM-ERROR象徴の賢明な使用で係数bitlengthにかかわる食い違いは決議できます。 支持する中で最も強いRSA(例えば、1024ビット)を使用することで文脈創始者はREQ-TOKENにサインします。 目標がこの長さの署名について確かめることができないなら、それは支持する中で最も強いRSA(例えば、512)を契約されたSPKM-ERRORを送ります。
At the completion of this exchange, both sides know what RSA bitlength the other supports, since the size of the signature is equal to the size of the modulus. Further exchanges can be made (using successively smaller supported bitlengths) until either an agreement is reached or context establishment is aborted because no agreement is possible.
この交換の完成のときに、両側は、もう片方がどんなRSA bitlengthを支持するかを知っています、署名のサイズが係数のサイズと等しいので。 合意に達しているか、またはどんな協定も可能でないので文脈設立が中止されるまでさらなる交換をすることができます(相次ぎより小さい支持されたbitlengthsを使用します)。
Adams Standards Track [Page 19] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[19ページ]。
3.2. Per-Message and Context Deletion Tokens
3.2. メッセージと文脈削除象徴
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つのクラスの象徴はこのセクションで定義されます: 呼び出しでgss_getMIC()に放たれていて、呼び出しでgss_verifyMIC()に消費された"MIC"象徴。 _象徴を「包装し」て、呼び出しでgss_包装()に放たれていて、呼び出しでgssに消費されて、()を開けてください。 そして、gss_イニット_秒_文脈()への呼び出しで放たれた文脈削除象徴であり、gss_は_秒_文脈()、またはgss_過程_文脈_象徴()に_秒_文脈()を削除して、呼び出しで消費されたgss_を受け入れます。
3.2.1. Per-message Tokens - Sign / MIC
3.2.1. 1メッセージあたりの象徴--サイン/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.
gss_サイン()/gss_getMIC()呼び出しの使用は象徴をもたらします、保護される利用者データから、別々です。(受け取るようにそのデータの保全について確かめるのに利用者データを使用できます)。 別々に送付アプリケーションで象徴とデータを送るかもしれません、そして、容認された象徴に受信データを関連づけるのは、受信アプリケーションの責任です。
The SPKM-MIC token has the following format:
SPKM-MIC象徴には、以下の形式があります:
SPKM-MIC ::= SEQUENCE {
mic-header Mic-Header,
int-cksum BIT STRING
-- Checksum over header and data,
-- calculated according to algorithm
-- specified in int-alg field.
}
SPKM-ミック:、:= 系列アルゴリズムによると、mic-ヘッダーミック-ヘッダー(int-cksum BIT STRING(ヘッダーとデータの上のチェックサム))は計算しました--int-alg分野では、指定されています。
Mic-Header ::= SEQUENCE {
tok-id INTEGER (257),
-- shall contain 0101 (hex)
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
snd-seq [1] SeqNum OPTIONAL -- sequence number field.
}
ミック-ヘッダー:、:= 系列tok-イドINTEGER(257)--、0101年の(十六進法)文脈イドRandom-整数を含んでください、int-alg[0]AlgorithmIdentifier OPTIONAL--保全アルゴリズムインディケータ(必須--同意された保全の1つになってください--この文脈のためのアルゴリズム)--現在の=デフォルトイドどんなsnd-seq[1]SeqNum OPTIONALもさばかないでください--一連番号分野であるだろう。
SeqNum ::= SEQUENCE {
num INTEGER, -- the sequence number itself
dir-ind BOOLEAN -- a direction indicator
}
SeqNum:、:= 系列num INTEGER--、一連番号、それ自体でdir-indブール--、指示インディケータ
Adams Standards Track [Page 20] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[20ページ]。
3.2.1.1. Checksum
3.2.1.1. チェックサム
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.
そして、チェックサム計算手順、(すべてのアルゴリズムへのコモン--SPKMに関して、「チェックサム」という用語がまた、デジタル署名を含んでいることに注意してください、論じ尽くす、MACs)、: チェックサムは、データ・フィールドに関して計算されて、平文象徴ヘッダー(micヘッダー)のバイトによって論理的にprependedされています。 結果は、悪意がある継ぐことの可能性を最小にするために全体の平文ヘッダーにデータを縛ります。
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.
例えば、int-algがmd5WithRSAアルゴリズムを指定するなら、チェックサムは、平文データ(ヘッダーで、prependedした)に関してMD5[RFC-1321]細切れ肉料理を計算して、次に、16バイトのMD5結果でRSA署名[PKCS1]を計算することによって、形成されます。 署名は信任状から検索されたRSA秘密鍵を使用することで計算されて、構造と結果(長さは秘密鍵における「係数」パラメタによって含意される)がint-cksum分野に格納されるということです。
If the int-alg specifies a keyed hashing algorithm (for example, DES-MAC or md5-DES-CBC), then the key to be used is the appropriate subkey derived from the context key (see Section 2.4). Again, the result (whose length is implied by int-alg) is stored in the int- cksum field.
If the int-alg specifies a keyed hashing algorithm (for example, DES-MAC or md5-DES-CBC), then the key to be used is the appropriate subkey derived from the context key (see Section 2.4). Again, the result (whose length is implied by int-alg) is stored in the int- cksum field.
3.2.1.2. Sequence Number
3.2.1.2. Sequence Number
It is assumed that the underlying transport layers (of whatever protocol stack is being used by the application) will provide adequate communications reliability (that is, non-malicious loss, re-ordering, etc., of data packets will be handled correctly). Therefore, sequence numbers are used in SPKM 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.
It is assumed that the underlying transport layers (of whatever protocol stack is being used by the application) will provide adequate communications reliability (that is, non-malicious loss, re-ordering, etc., of data packets will be handled correctly). Therefore, sequence numbers are used in SPKM 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 and a Boolean direction-indicator (FALSE - sender is the context initiator, TRUE - sender is the context acceptor). After constructing a gss_sign/getMIC() or gss_seal/wrap() token, the sender's seq. number is incremented by 1.
Sequence number field: The sequence number field is formed from the sender's four-byte sequence number and a Boolean direction-indicator (FALSE - sender is the context initiator, TRUE - sender is the context acceptor). After constructing a gss_sign/getMIC() or gss_seal/wrap() token, the sender's seq. number is incremented by 1.
Adams Standards Track [Page 21] RFC 2025 SPKM October 1996
Adams Standards Track [Page 21] RFC 2025 SPKM October 1996
3.2.1.3. Sequence Number Processing
3.2.1.3. Sequence Number Processing
The receiver of the token will verify the sequence number field by comparing the sequence number with the expected sequence number and the direction indicator with the expected direction indicator. If the sequence number in the token is higher than the expected number, then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is returned. If the token sequence number is lower than the expected number, then the expected sequence number is not adjusted and GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is returned, whichever is appropriate. If the direction indicator is wrong, then the expected sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned.
The receiver of the token will verify the sequence number field by comparing the sequence number with the expected sequence number and the direction indicator with the expected direction indicator. If the sequence number in the token is higher than the expected number, then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is returned. If the token sequence number is lower than the expected number, then the expected sequence number is not adjusted and GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is returned, whichever is appropriate. If the direction indicator is wrong, then the expected sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned.
Since the sequence number is used as part of the input to the integrity checksum, sequence numbers need not be encrypted, and attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect tokens which have been maliciously reflected.
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
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 appropriate subkey specified in Section 2.4 for one of the agreed C-ALGs for this context).
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 appropriate subkey specified in Section 2.4 for one of the agreed C-ALGs for this context).
The SPKM-WRAP token has the following format:
The SPKM-WRAP token has the following format:
SPKM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
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,
-- Integrity algorithm indicator (must
-- be one of the agreed integrity
-- algorithms for this context).
-- field not present = default id.
Wrap-Header ::= SEQUENCE { tok-id INTEGER (513), -- shall contain 0201 (hex) context-id Random-Integer, int-alg [0] AlgorithmIdentifier OPTIONAL, -- Integrity algorithm indicator (must -- be one of the agreed integrity -- algorithms for this context). -- field not present = default id.
Adams Standards Track [Page 22] RFC 2025 SPKM October 1996
Adams Standards Track [Page 22] RFC 2025 SPKM October 1996
conf-alg [1] Conf-Alg OPTIONAL,
-- Confidentiality algorithm indicator
-- (must be NULL or one of the agreed
-- confidentiality algorithms for this
-- context).
-- field not present = default id.
-- NULL = none (no conf. applied).
snd-seq [2] SeqNum OPTIONAL
-- sequence number field.
}
conf-alg [1] Conf-Alg OPTIONAL, -- Confidentiality algorithm indicator -- (must be NULL or one of the agreed -- confidentiality algorithms for this -- context). -- field not present = default id. -- NULL = none (no conf. applied). snd-seq [2] SeqNum OPTIONAL -- sequence number field. }
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
-- Checksum of header and data,
-- calculated according to algorithm
-- specified in int-alg field.
data BIT STRING
-- encrypted or plaintext data.
}
Wrap-Body ::= SEQUENCE { int-cksum BIT STRING, -- Checksum of header and data, -- calculated according to algorithm -- specified in int-alg field. data BIT STRING -- encrypted or plaintext data. }
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] NULL
}
Conf-Alg ::= CHOICE { algId [0] AlgorithmIdentifier, null [1] NULL }
3.2.2.1: Confounding
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.
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
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.
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.
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
If int-alg specifies md5-DES-CBC and conf-alg specifies anything other than DES-CBC, then the checksum is computed according to
Adams Standards Track [Page 23] RFC 2025 SPKM October 1996
Adams Standards Track [Page 23] RFC 2025 SPKM October 1996
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 are 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 DES-CBC subkey (see Section 2.4) and placed in the "data" field of Wrap-Body. The final two blocks of ciphertext (i.e., the encrypted MD5 hash) are also placed in the int-cksum field of Wrap-Body as the integrity checksum.
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 are 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 DES-CBC subkey (see Section 2.4) and placed in the "data" field of Wrap-Body. The final two blocks of ciphertext (i.e., the encrypted MD5 hash) are also placed in the int-cksum field of Wrap-Body as the integrity checksum.
If int-alg specifies sum64-DES-CBC then conf-alg must specify DES-CBC (i.e., confidentiality must be requested by the calling application or SPKM will return an error). Encryption and integrity are done in a single pass using the DES-CBC subkey as follows. The sum (modulo 2**64 - 1) of all plaintext data blocks (prepended by the header) is computed. This 8-byte value is appended to the concatenation of the "confounded" data and 1-8 padding bytes (the padding is as specified in [KRB5] for DES-CBC). As above, the result is then CBC encrypted and placed in the "data" field of Wrap-Body. The final block of ciphertext (i.e., the encrypted sum) is also placed in the int-cksum field of Wrap-Body as the integrity checksum.
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 DES-CBC subkey as follows. The sum (modulo 2**64 - 1) of all plaintext data blocks (prepended by the header) is computed. This 8-byte value is appended to the concatenation of the "confounded" data and 1-8 padding bytes (the padding is as specified in [KRB5] for DES-CBC). As above, the result is then CBC encrypted and placed in the "data" field of Wrap-Body. The final block of ciphertext (i.e., the encrypted sum) is also placed in the int-cksum field of Wrap-Body as the integrity checksum.
3.2.2.3 Sequence Number
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.
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
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 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).
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
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 token emitted by gss_delete_sec_context() is based on the format for tokens emitted by gss_sign() / gss_getMIC().
Adams Standards Track [Page 24] RFC 2025 SPKM October 1996
Adams Standards Track [Page 24] RFC 2025 SPKM October 1996
The SPKM-DEL token has the following format:
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.
}
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.
}
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.
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).
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
4. Name Types and Object Identifiers
No mandatory name forms have yet been defined for SPKM. This section is for further study.
No mandatory name forms have yet been defined for SPKM. This section is for further study.
Adams Standards Track [Page 25] RFC 2025 SPKM October 1996
Adams Standards Track [Page 25] RFC 2025 SPKM October 1996
4.1. Optional Name Forms
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.
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
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 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:
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
username
4.1.2. Machine UID Form
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 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.
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
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 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.
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.
Adams Standards Track [Page 26] RFC 2025 SPKM October 1996
Adams Standards Track [Page 26] RFC 2025 SPKM October 1996
5. Parameter Definitions
5. Parameter Definitions
This section defines parameter values used by the SPKM GSS-API mechanism. It defines interface elements in support of portability.
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
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.
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. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET)
5.1.1.1. GSS-Related codes (Minor Status Code bit 30 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" */
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)
5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF)
GSS_S_G_MEMORY_ALLOC
/* "Couldn't perform requested memory allocation" */
GSS_S_G_MEMORY_ALLOC /* "Couldn't perform requested memory allocation" */
5.1.2. SPKM-specific-codes (Minor Status Code MSB, bit 31, OFF)
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
GSS_SPKM_S_SG_CONTEXT_ESTABLISHED /* "Context is already fully established" */ GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
Adams Standards Track [Page 27] RFC 2025 SPKM October 1996
Adams Standards Track [Page 27] RFC 2025 SPKM October 1996
/* "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" */
/* "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
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.
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
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
Adams Standards Track [Page 28] RFC 2025 SPKM October 1996
Adams Standards Track [Page 28] RFC 2025 SPKM October 1996
the mechanism specification. If this algorithm is supported over this context then it is used; otherwise, GSS_S_FAILURE and an appropriate minor status code are returned.
the 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.
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:
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) | ------------------------------------|-----------------------------------
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
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);
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);
U is a 3-bit Unspecified field (available for future use/expansion);
IA is a 4-bit field enumerating Implementation-specific
Algorithms; and
IA is a 4-bit field enumerating Implementation-specific Algorithms; and
MA is a 4-bit field enumerating Mechanism-defined Algorithms.
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.
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
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
Adams Standards Track [Page 29] RFC 2025 SPKM October 1996
Adams Standards Track [Page 29] RFC 2025 SPKM October 1996
not be supported or may specify a completely different algorithm in another implementation of the mechanism.
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.
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.
The following TS values (i.e., algorithm qualifiers) are specified; other values may be added in the future.
For the Confidentiality TS field:
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
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:
For the Integrity TS field:
00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT
00010 (2) = SPKM_INT_ALG_REPUDIABLE
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.)
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.
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.
Adams Standards Track [Page 30] RFC 2025 SPKM October 1996
Adams Standards Track [Page 30] RFC 2025 SPKM October 1996
Use of the QOP structure as defined above is ultimately meant to be as follows.
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.
- 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
- 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).
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.)
(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).
すべての関連分野があるQOPパラメタが設定したアプリケーションと呼ぶのに象徴の受信機は通過して戻らなければなりません。 例えば、三重のDESがアルゴリズム8としてメカニズムによって指定されたなら、三重のDESが保護している象徴の受信機はアプリケーションに通過しなければなりません(QOP Confidentiality TS=1、アイオワは0、MA=8と等しいです)。 このように、QOPのどんな部分も理解していても(TSかアイオワ/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.
実現における援助と相互運用性に、以下の約款をします。 保全Algのセット。 創始者によって送られたIDは、非拒否を支持するデジタル署名を計算するアルゴリズムを指定しながら少なくとも1つを含まなければならなくて、いかなる他の(repudiable)保全アルゴリズムも指定しながら、少なくとも1つを含まなければなりません。 保全Algの部分集合。 また、目標によって返されたIDは、repudiable保全アルゴリズムを指定する非拒否、および少なくとも1つを支持しながらデジタル署名を計算するアルゴリズムを指定しながら、少なくとも1つを含まなければなりません。
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
この約款の理由はあらゆるSPKM実現が非拒否を支持する保全サービスと非拒否を支持しないものを提供するのを保証することです。 または、基本的なアルゴリズムに関する知識のないアプリケーションが通ることによって1かもう片方を選ぶことができる、(QOP Integrity TS=1、アイオワはMA=0と等しいです)(QOP
Adams Standards Track [Page 31] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[31ページ]。
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.
保全tはMA2、アイオワ==0)と等しいです。 匿名を希望する創始者は実際に非repudiableデジタル署名を決して使用しないでしょうが、この保全サービスは、望まれているなら目標がそれを使用できるくらい文脈の上で利用可能でなければなりません。
Finally, in accordance with the MANDATORY and RECOMMENDED algorithms given in Section 2, the following QOP values are specified for SPKM.
最終的に、セクション2で与えられたMANDATORYとRECOMMENDEDアルゴリズムによると、以下のQOP値はSPKMに指定されます。
For the Confidentiality MA field:
Confidentiality MA分野に:
0001 (1) = DES-CBC
0001(1)はデス-CBCと等しいです。
For the Integrity MA field:
Integrity MA分野に:
0001 (1) = md5WithRSA
0010 (2) = DES-MAC
0001(1)=md5WithRSA0010(2)はDES-MACと等しいです。
6. Support Functions
6. 支援機能
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.
このセクションは事実上、すべてのGSS-APIメカニズムの価値があるかもしれないSPKM- conformant実現のために義務的なサポート機能について説明します。それは象徴イド、SPKM文脈設立に含まれている文脈イド情報、誤り、文脈削除、および1メッセージあたりの象徴を利用します。 機能は以下のセクションで定義されます。
6.1. SPKM_Parse_token call
6.1. SPKM_Parse_象徴呼び出し
Inputs:
入力:
o input_token OCTET STRING
o 入力_象徴OCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o mech_type OBJECT IDENTIFIER,
o mech_タイプOBJECT IDENTIFIER
o token_type INTEGER,
o 象徴_タイプINTEGER
o context_handle CONTEXT HANDLE,
o 文脈_ハンドルCONTEXT HANDLE
Adams Standards Track [Page 32] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[32ページ]。
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_COMPLETEは、すべての関連分野に入力_象徴を分析できたのを示します。 結果として起こる値は_タイプ、象徴_タイプ、および文脈_がそれぞれ(どんな関連していないパラメタのNULLsと共にも)扱うmechに格納されます。
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_DEFECTIVE_TOKENは、象徴イドか文脈イド(それが予想されたなら)情報のどちらかを分析できなかったのを示します。 象徴_タイプによる非NULLリターン価値は、後者の状況が起こったのを示します。
o GSS_S_NO_TYPE indicates that the token-id information could be
parsed, but it did not correspond to any valid token_type.
o GSS_S_いいえ_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.)
この主要なステータスコードがRFC-1508のGSSのために定義されていないことに注意してください。SPKM実現は代わりにそのような定義をするまで(かつてなら)_象徴_タイプと文脈_ハンドルセットの両方があるGSS_S DEFECTIVE_TOKENをNULLに返すべきです。(これは、認識されていない象徴イド情報が分析できなかった象徴イド情報に相当させていると考えられるのを本質的には含意します。)
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_いいえ_CONTEXTは、文脈イドを分析できましたが、それがどんな有効な文脈_ハンドルにも対応しなかったのを示します。
o GSS_S_FAILURE indicates that the mechanism type could not be
parsed (for example, the token may be corrupted).
o GSS_S_FAILUREは、メカニズムタイプを分析できなかったのを示します(例えば、象徴は崩壊するかもしれません)。
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.
SPKM_Parse_象徴()は、メカニズムタイプ、象徴タイプ、および文脈が扱うアプリケーションに戻るのに使用されます(与えられた入力象徴に対応しています)。 GSS-API象徴が呼ぶアプリケーションに不伝導性であることが意味されるので、この機能で、GSSの不透明意志に違反する必要はなくて、アプリケーションは象徴の情報を決定できます。 第一の重要性は象徴タイプ(次に、アプリケーションは象徴を処理させるためにどのGSS機能を呼んだらよいかを決めるのに使用できる)です。
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
すべての象徴がRFC-1508、Appendix Bに示されるように縁どられるなら(ケルベロスV5 GSSメカニズム[KRB5]に本書では指定されます)、どんなメカニズム実現もどんな腐敗していない入力象徴のための少なくともmech_型引数(NULLである他のパラメタ)も返すことができるべきです。 SPKM_Parse_象徴()機能が呼ばれるのが象徴を認識して、アプリケーションが次に呼ぶことができるように象徴_タイプを返すことができるということであるメカニズム実現であるなら、正しいGSSは機能します。 最終的に、メカニズムが象徴の文脈イド野原を供給するなら(SPKMがそうするように)、実現は、文脈_ハンドルに文脈イドを写像して、これをアプリケーションに返すことができます。 これが状況に必要です。
Adams Standards Track [Page 33] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[33ページ]。
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.
アプリケーションには複数の文脈があるところでは、同じメカニズムをすべて使用して、同時に、開いてください。 入って来る象徴が届くとき、アプリケーションは、どのGSS機能を呼ぶかだけではなく、呼び出しにどの文脈_ハンドルを使用もしたらよいかを決定するのにこの機能を使用できます。 この機能が象徴の正当性を決定するためにどんな暗号の処理もしないことに注意してください。 それは、それが与えられているどんな象徴のmech_タイプ、象徴_タイプ、および文脈イド分野も分析するのを単に試みます。 したがって、例えば、データの任意のバッファが有効なmech_タイプに似ている無作為の値から始まるかもしれなくて、このバッファを与えるならSPKM_Parse_象徴()が不正確な情報を返すだろうというのが想像できます。 想像できますが、しかしながら、そのような状況はありそうもないです。
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.
SPKM_Parse_象徴()機能はSPKM-conformant実現に義務的ですが、アプリケーションに、それは任意です。 すなわち、アプリケーションが、1つの文脈だけの戸外を持って、どのGSS機能を呼んだらよいかを推測できるなら(または、いくつかのエラーコードを我慢することを望んでいます)、それは決してどんな呼び出しSPKM_Parse_象徴()もそうしてはいけません。 その上、この機能がGSS-APIレベルまで移動すると、SPKM_Parse_象徴()はその時、GSS_Parse_象徴()、または新しい名前と機能仕様がことなら何でもであるかもしれないかを支持して非難されるでしょう。 どんな小さい方の状態復帰コードもこのときこの機能のために定義されていないことに最終的に注意してください。
6.2. The token_type Output Parameter
6.2. 象徴_タイプ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
1GSS GSS_イニット_象徴=_が__象徴=GSS_GETMIC_象徴=4GSS_シール_象徴=GSS_包装_象徴=5GSS_が_象徴=6を削除するという象徴=2GSS_誤り_象徴=3GSS_サインを受け入れます。
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()).
すべてのSPKMメカニズムがあらゆる象徴(SPKMInnerContextTokenのタグ値を通した、または、tok-イド分野を通る)に上の象徴タイプのひとりに含まれている象徴イド情報からのマッピングを実行できるでしょう。 アプリケーションは、象徴_タイプに基づいてどのGSS機能を呼んだらよいかを決めることができるべきです。(例えば、アプリケーションは、象徴がGSS_INIT_TOKENであるなら_が受け入れるgssを_秒_文脈()と呼んで、アプリケーションは、象徴がGSS_WRAP_TOKENであるなら_が開けるgssを())と呼ぶでしょう。
6.3. The context_handle Output Parameter
6.3. 文脈_ハンドル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
あらゆる象徴に含まれている文脈イド値と文脈_ハンドルの間のマッピングであることを支持して、その結果、個々の象徴を関連づける、SPKMメカニズム実現が原因となるそれ
Adams Standards Track [Page 34] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[34ページ]。
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.
適切な関係。 明確に、文脈_ハンドルの値は、局所的に決定するかもしれなくて、事実上、ローカルシステムに関する極秘データを含んでいるメモリに関連しているかもしれません、そして、一般に、したがって、文脈イドが実際に計算された文脈_ハンドルと等しいセットであることを持っているのが働かないでしょう。 逆に、一般に、文脈_ハンドルが実際に計算された文脈イドと等しいセットであることを持っているのが働かないでしょう、文脈イド(両端のすべての文脈の上の)のユニークさが、創始者と目標の両方が計算にかかわるのを必要とするかもしれなくてgss_イニット_秒_文脈()への準備ラッパで文脈_ハンドルをアプリケーションに返さなければならない、さもなければ、gss_が_秒_文脈()を受け入れるので。 その結果、別々に_が扱う文脈と文脈イドを計算しなければなりません、そして、メカニズム実現は計算するに違いありません。遅くとも文脈設立の完成で1〜もう片方まで写像できます。
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.
文脈設立の間の文脈イドの計算は以下の通り実行されます。 それぞれのSPKM実現は「新鮮な」乱数を発生させるのに原因となります。 すなわち、以前に使用されていない(高い確率で)もの。 この乱数に関するどんな暗号の要件もないことに注意してください(すなわち、それが予測できなければならない、それは単に新鮮である必要があります)。 創始者はSPKM- REQ象徴の文脈イド分野の目標に乱数を通過します。 一層の文脈設立象徴を全く予想しないなら(SPKM-2での一方的な認証のように)、文脈イドになるようにこの値を取ります(これが目標に容認できないなら、誤り象徴は発生しなければなりません)。 さもなければ、目標は、創始者の乱数の終わりまで乱数を発生させて、それを連結します。 この連結された値は、次に、文脈イドになるように取られて、SPKM-REP-TIとその文脈の上のすべてのその後の象徴で使用されます。
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).
両方の同輩に文脈イドに貢献させるのが、各同輩に新しさを保証して、したがって、文脈の間の反射攻撃を排除します(2人の同輩の間の古い背景からの象徴が陰湿に同じであるか異なった同輩の間の新しい関係に注がれるところ)。 そのような保証はSPKM-2を使用することで一方的な認証の場合における目標に利用可能ではありません、単に計算された文脈イドの新しさに貢献していないので(それは、代わりに、創始者の乱数の新しさを信じなければならないか、または文脈を拒絶しなければなりません)。 SPKM-REQの主要なsrcひもの分野が、まさにSPKM-2の一方的な認証に関するケースがこの象徴(そして、提案された文脈キー)の新しさを信じるのに目標を助けるように存在しているのに必要です。
7. Security Considerations
7. セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Adams Standards Track [Page 35] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[35ページ]。
8. References
8. 参照
[Davi89]: D. W. Davies and W. L. Price, "Security for Computer Networks", Second Edition, John Wiley and Sons, New York, 1989.
[Davi89]: D。 W。 デイヴィースとW.L.価格と「コンピュータネットワークのためのセキュリティ」と第2版とジョン・ワイリーと息子、ニューヨーク、1989
[FIPS-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985.
[FIPS-113]: 連邦情報処理基準113、「コンピュータのデータ認証」という規格基準局は1985がそうするかもしれません。
[GSSv2]: Linn, J., "Generic Security Service Application Program Interface Version 2", Work in Progress.
[GSSv2]: リン、J.、「一般的なセキュリティー・サービス適用業務プログラム・インタフェースバージョン2インチ、進行中で働いてください。」
[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.
[Juen84]: R。 R。 SecurityとPrivacyの上の1983IEEE SymposiumのProceedings、IEEEコンピュータSociety Press、1984、pp.33-54のJuenemanとC.H.マイヤーとS.M.マーチャーシュ、Manipulation Detection CodesとMessage Authentication。
[KRB5]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[KRB5]: リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security, Inc., Nov. 1993.
[PKCS1]: RSA暗号化規格、バージョン1.5、RSA Data Security Inc.、1993年11月。
[PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA Data Security, Inc., Nov. 1993.
[PKCS3]: ディフィー-ヘルマン主要な協定規格、バージョン1.4、RSA Data Security Inc.、1993年11月。
[RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321.
[RFC-1321]: 最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[RFC-1422]: Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422.
[RFC-1422]: ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422。
[RFC-1423]: Balenson, D., "Privacy Enhancement for Internet Elecronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423.
[RFC-1423]: Balenson、D.、「インターネットElecronicのためのプライバシー増進は以下を郵送します」。 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508.
[RFC-1508]: リン、J.、「一般的なセキュリティー・サービス適用業務プログラム・インタフェース」、RFC1508。
[RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509.
[RFC-1509]: レイ、J.、「一般的なセキュリティは適用業務プログラム・インタフェースを調整します」。 「C-結合」、RFC1509。
[RFC-1510]: Kohl J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510.
[RFC-1510]: コールJ.、およびC.ヌーマン、「ケルベロスネットワーク認証サービス(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.
[9798]: ISO/IEC9798-3、「情報技術--セキュリティTechniques--実体認証機構--3を分けてください」 「公開鍵アルゴリズムを使用するEntitiy認証」、ISO/IEC、1993。
Adams Standards Track [Page 36] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[36ページ]。
[X.501]: ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993.
[X.501]: ISO/IEC9594-2、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 CCITT/ITU推薦X.501、1993年の「モデル。」
[X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993.
[X.509]: ISO/IEC9594-8、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「認証枠組み」、CCITT/ITU推薦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.
[X9.44]: ANSI、「財政的にリバーシブルのアルゴリズムを使用する公開鍵暗号が産業にサービスを提供します」。 「RSAを使用する左右対称のアルゴリズムキーの輸送」、X9.44-1993。
9. Author's Address
9. 作者のアドレス
Carlisle Adams Bell-Northern Research P.O.Box 3511, Station C Ottawa, Ontario, CANADA K1Y 4H7
カーライルアダムスベル-北研究私書箱3511、オタワ、Cオンタリオ、駅のカナダK1Y 4H7
Phone: +1 613.763.9008 EMail: cadams@bnr.ca
以下に電話をしてください。 +1 613.763 .9008 メール: cadams@bnr.ca
Adams Standards Track [Page 37] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[37ページ]。
Appendix A: ASN.1 Module Definition
付録A: ASN.1モジュール定義
SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}
SpkmGssTokensiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(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}
InformationFrameworkからの名前共同iso-ccitt(2) ds(5)モジュール(1)informationFramework(1)2
Certificate, CertificateList, CertificatePair, AlgorithmIdentifier,
Validity
FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1)
authenticationFramework(7) 2} ;
証明書、CertificateList、CertificatePair、AlgorithmIdentifier、Validity FROM AuthenticationFramework共同iso-ccitt(2) ds(5)モジュール(1)authenticationFramework(7)2。
-- types --
-- タイプします--
SPKM-REQ ::= SEQUENCE {
requestToken REQ-TOKEN,
certif-data [0] CertificationData OPTIONAL,
auth-data [1] AuthorizationData OPTIONAL
}
SPKM-REQ:、:= 系列requestToken REQ-TOKEN、certif-データ[0]CertificationData OPTIONAL、auth-データ[1]AuthorizationData OPTIONAL
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath OPTIONAL,
certificateRevocationList [1] CertificateList OPTIONAL
} -- at least one of the above shall be present
CertificationData:、:= SEQUENCE、certificationPath[0]CertificationPath OPTIONAL、certificateRevocationList[1]CertificateList OPTIONAL--、少なくとも上の1つは存在するでしょう。
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
CertificationPath:、:= SEQUENCE、userKeyId[0]OCTET STRING OPTIONAL、userCertif[1]はOPTIONALを証明します、verifKeyId[2]OCTET STRING OPTIONAL、userVerifCertif[3]証明書OPTIONAL、theCACertificates[4]SEQUENCE OF CertificatePair OPTIONAL--[2]か[3]の存在は、また、[0]か[1]があるに違いないのを含意します。
Adams Standards Track [Page 38] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[38ページ]。
-- present. Presence of [4] implies that at least one of [0], [1],
-- [2], and [3] must also be present.
-- 存在。 [4]の存在は[0]、[1]についてそんなに少なくとも1つを含意します--また、[2]、および[3]も存在していなければなりません。
REQ-TOKEN ::= SEQUENCE {
req-contents Req-contents,
algId AlgorithmIdentifier,
req-integrity Integrity -- "token" is Req-contents
}
REQ-象徴:、:= 系列req-コンテンツReq-コンテンツ、algId AlgorithmIdentifier、req-保全Integrity--、「象徴」はReq-コンテンツです。
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"
保全:、:= BIT STRING--、algIdが論じ尽くす手順(また、中では、algIdを指定する)を適用するのからの「保全」が調印手順を適用するという結果を保持するというalgIdで結果として生じるBERによってコード化された八重奏ストリングに指定された調印アルゴリズムを指定する対応--「象徴」のDERによってコード化された八重奏。 -- あるいはまた、対応するalgIdがMACingを指定するなら(アルゴリズム、「保全」はMACingを適用するという結果を保持します)手順がalgIdでDERによってコード化された八重奏に指定した、--、「象徴」
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.
}
Req-コンテンツ:、:= 系列{ tok-イドINTEGER(256)--使用中のK-ALGが提供しないと、0100年の(十六進法)文脈イドRandom-整数、pvno BIT STRING、SPKM-2 randSrc Random-整数にちなんで、Name、src-名前0Name OPTIONAL、req-データContext-データ、正当性を1Validity OPTIONALとtarg命名してください、主要なestbセットKey-Estb-Algs、主要なestb-req BIT STRING OPTIONAL、主要なsrcひものOCTET STRING OPTIONAL--この分野はSPKM-2に関するケースのために存在していなければなりません--一方的なauthenが義務的なタイムスタンプUTCTime OPTIONALを含むでしょう; 以下の通り、: 「srcである」ところのMD5(src| | 文脈_キー)はそうです。そして、「そのような結合(しかし、他のすべてのケースにおいて、任意である)、--、八重奏ストリングが適用するという結果を保持する--、義務的な論じ尽くす手順、(MANDATORY I-ALGで;、--、セクション2.1を見てください)、src-名前のDERによってコード化された八重奏--「文脈キー」が対称鍵(すなわち、--伝えられるものに関する保護のないバージョン--主要なestb-req)である、」 | | 」 連結演算はそうですか?; }
Random-Integer ::= BIT STRING
無作為の整数:、:= ビット列
Adams Standards Track [Page 39] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[39ページ]。
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 ChannelId OPTIONAL、seq-数のINTEGER OPTIONAL、オプションOptions、conf-alg Conf-Algs、intg-alg Intg-Algs、owf-alg OWF-Algs
ChannelId ::= OCTET STRING
ChannelId:、:= 八重奏ストリング
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)
}
オプション:、:= ビット列代表団州の(0)、互いの州の(1)、再生det州の(2)、系列州の(3)、conf-利益(4)、integ-利益(5)、データが必要とした目標certif(6)
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL
}
Conf-Algs:、:= 選択algs[0]SEQUENCE OF AlgorithmIdentifier、ヌル[1]NULL
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
Intg-Algs:、:= AlgorithmIdentifierの系列
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
OWF-Algs:、:= AlgorithmIdentifierの系列
Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
主要なEstb-Algs:、:= 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
SPKMレップTI:、:= SEQUENCE、responseToken REP-TI-TOKEN、現在の、しかし、目標certifデータが必要なcertif-データCertificationData OPTIONALオプションはそうでした--TRUEに、SPKM-REQでは、セットします。
REP-TI-TOKEN ::= SEQUENCE {
rep-ti-contents Rep-ti-contents,
algId AlgorithmIdentifier,
rep-ti-integ Integrity -- "token" is Rep-ti-contents
}
レップTI象徴:、:= 系列レップtiコンテンツRep-ti-コンテンツ、algId AlgorithmIdentifier、レップ-ti-integ Integrity--、「象徴」はRep-ti-コンテンツです。
Rep-ti-contents ::= SEQUENCE {
tok-id INTEGER (512), -- shall contain 0200 (hex)
context-id Random-Integer,
レップtiコンテンツ:、:= SEQUENCE、tok-イドINTEGER(512)--0200年の(十六進法)文脈イドRandom-整数を含むでしょう。
Adams Standards Track [Page 40] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[40ページ]。
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
}
pvno[0]BIT STRING OPTIONAL、タイムスタンプUTCTime OPTIONAL--SPKM-2 randTarg Random-整数に義務的です、名前OPTIONALと[1]をsrc命名してください、targ-名前Name、randSrc Random-整数、レップデータContext-データ、正当性[2]正当性OPTIONAL、主要なestbイドAlgorithmIdentifier OPTIONAL、主要なestb-str BIT STRING OPTIONAL
SPKM-REP-IT ::= SEQUENCE {
responseToken REP-IT-TOKEN,
algId AlgorithmIdentifier,
rep-it-integ Integrity -- "token" is REP-IT-TOKEN
}
SPKMレップIT:、:= 系列responseToken REP IT TOKEN、algId AlgorithmIdentifier、レップ、それ、integ Integrity、--「象徴」が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
}
レップIT象徴:、:= 系列tok-イドINTEGER(768)--0300年の(十六進法)文脈イドRandom-整数を含む、randSrc Random-整数、randTarg Random-整数はNameをtarg命名します、src-名前Name OPTIONAL、主要なestbレップBIT STRING OPTIONAL
SPKM-ERROR ::= SEQUENCE {
errorToken ERROR-TOKEN,
algId AlgorithmIdentifier,
integrity Integrity -- "token" is ERROR-TOKEN
}
SPKM-誤り:、:= 系列errorToken ERROR-TOKEN、algId AlgorithmIdentifier、保全Integrity--、「象徴」はERROR-TOKENです。
ERROR-TOKEN ::= SEQUENCE {
tok-id INTEGER (1024), -- shall contain 0400 (hex)
context-id Random-Integer
}
誤り象徴:、:= 系列tok-イドINTEGER(1024)--0400年の(十六進法)文脈イドRandom-整数を含むでしょう。
SPKM-MIC ::= SEQUENCE {
mic-header Mic-Header,
int-cksum BIT STRING
}
SPKM-ミック:、:= 系列mic-ヘッダーミック-ヘッダー、int-cksum BIT STRING
Mic-Header ::= SEQUENCE {
tok-id INTEGER (257), -- shall contain 0101 (hex)
context-id Random-Integer,
ミック-ヘッダー:、:= SEQUENCE、tok-イドINTEGER(257)--0101年の(十六進法)文脈イドRandom-整数を含むでしょう。
Adams Standards Track [Page 41] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[41ページ]。
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
int-alg[0]AlgorithmIdentifier OPTIONAL、snd-seq[1]SeqNum OPTIONAL
SeqNum ::= SEQUENCE {
num INTEGER,
dir-ind BOOLEAN
}
SeqNum:、:= 系列num INTEGERで、dir-indブールです。
SPKM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
以下をSPKM包装してください:= 系列包装ヘッダーWrap-ヘッダー、包装ボディーWrap-ボディー
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
}
包装ヘッダー:、:= 系列tok-イドINTEGER(513)--0201年の(十六進法)文脈イドRandom-整数、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
}
以下を包装して具体化させてください:= 系列int-cksum BIT STRING、データBIT STRING
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] NULL
}
Conf-Alg:、:= 選択algId[0]AlgorithmIdentifier、ヌル[1]NULL
SPKM-DEL ::= SEQUENCE {
del-header Del-Header,
int-cksum BIT STRING
}
SPKM-デル:、:= 系列del-ヘッダーデル-ヘッダー、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
}
デル-ヘッダー:、:= 系列tok-イドINTEGER(769)--0301年の(十六進法)文脈イドRandom-整数、int-alg[0]AlgorithmIdentifier OPTIONAL、snd-seq[1]SeqNum OPTIONALを含むでしょう。
-- other types --
-- 他のタイプ--
Adams Standards Track [Page 42] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[42ページ]。
-- from [RFC-1508] --
-- [RFC-1508]から--
MechType ::= OBJECT IDENTIFIER
MechType:、:= 物の識別子
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken SPKMInnerContextToken
} -- when thisMech is SPKM-1 or SPKM-2
InitialContextToken:、:= [APPLICATION0]IMPLICIT SEQUENCE、thisMech MechType、innerContextToken SPKMInnerContextToken、thisMechはSPKM-1か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
}
SPKMInnerContextToken:、:= 選択req[0]SPKM-REQ、レップ-ti[1]SPKM-REP-TI、レップ、-、それ、[2] SPKM-REP-IT、誤り[3]SPKM-ERROR(mic[4]SPKM-MIC)は[5] SPKM-WRAPを包装します、del[6]SPKM-DEL
-- from [RFC-1510] --
-- [RFC-1510]から--
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type INTEGER,
ad-data OCTET STRING
}
AuthorizationData:、:= 系列の系列広告タイプINTEGER、広告データ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)}
md5デスCBC物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)保全(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)}
sum64デスCBC物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)保全(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-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(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)}
spkm-2 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)spkm(1) spkm-2(2)
END
終わり
Adams Standards Track [Page 43] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[43ページ]。
Appendix B: Imported Types
付録B: 輸入されたタイプ
This appendix contains, for completeness, the relevant ASN.1 types imported from InformationFramework (1993), AuthenticationFramework (1993), and [PKCS3].
この付録は完全性のためにInformationFramework(1993)、AuthenticationFramework(1993)、および[PKCS3]から輸入された関連ASN.1タイプを含んでいます。
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
}
AttributeType:、:= 識別子AttributeValueは反対します:、:= どんなAttributeValueAssertionも:、:= AttributeType、AttributeValueを配列してください、RelativeDistinguishedName:、:= SET OF AttributeValueAssertion--1993年のInformationFrameworkモジュールが使用する注意--上記の異なった構文はRDNSequenceを組み立てます:、:= RelativeDistinguishedName DistinguishedNameの系列:、:= RDNSequenceは以下を命名します:= 選択--、当分間の1だけ、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
以下を証明してください:= SEQUENCE、certContents CertContents、algID AlgorithmIdentifier、sig BIT STRING--sigするのは論じ尽くす手順(また、指定されたコネ--algId)をCertContentsのDERによってコード化された八重奏に適用する中で指定されて、BERによってコード化された八重奏へのalgIdがどれを結ぶかという調印手順が生じる適用の結果を保持します。
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
}
CertContents:、:= 系列バージョン[0]バージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUID[1]IMPLICIT UID OPTIONAL--v2だけでは、subjectUID[2]IMPLICIT UID OPTIONAL--v2だけで使用されるのを使用します。
Version ::= INTEGER {v1(0), v2(1)}
CertificateSerialNumber ::= INTEGER
UID ::= BIT STRING
バージョン:、:= INTEGER、v1(0)、v2(1)、CertificateSerialNumber:、:= 整数UID:、:= ビット列
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
正当性:、:= 系列notBefore UTCTime、notAfter UTCTime
Adams Standards Track [Page 44] RFC 2025 SPKM October 1996
アダムスStandardsはSPKM1996年10月にRFC2025を追跡します[44ページ]。
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL
} -- at least one of the pair shall be present
CertificatePair:、:= SEQUENCEは[0]証明書OPTIONAL、逆[1]証明書OPTIONALを進めます--少なくとも組のひとりは存在するでしょう。
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
CertificateList:、:= SEQUENCE、certListContents CertListContents、algId AlgorithmIdentifier、sig BIT STRING--sigするのは論じ尽くす手順(また、指定されたコネ--algId)をCertListContentsのDERによってコード化された八重奏に適用する中で指定されて、BERによってコード化された八重奏へのalgIdがどれを結ぶかという調印手順が生じる適用の結果を保持します。
CertListContents ::= SEQUENCE {
signature AlgorithmIdentifier,
issuer Name,
thisUpdate UTCTime,
nextUpdate UTCTime OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime } OPTIONAL
}
CertListContents:、:= 系列署名AlgorithmIdentifier、発行人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
AlgorithmIdentifier:、:= SEQUENCE、アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL--1993年のAuthenticationFrameworkモジュールが使用する注意--この構造物のための異なった構文
--from [PKCS3] (the parameter to be used with dhKeyAgreement) --
--[PKCS3](dhKeyAgreementと共に使用されるべきパラメタ)から--
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}
DHParameter:、:= 系列主要なINTEGER--pベースINTEGER--g privateValueLength INTEGER OPTIONAL
Adams Standards Track [Page 45]
アダムス標準化過程[45ページ]
一覧
スポンサーリンク
