One document matched: draft-ietf-cat-spkmgss-00.txt
Internet Draft C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-00.txt June 20, 1994
The Simple Public-Key GSS-API Mechanism (SPKM)
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.
ABSTRACT
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using the Simple Public-Key Mechanism.
BACKGROUND
Although the Kerberos Version 5 GSS-API mechanism is becoming well-
established in many environments, it is important in some
applications to have a GSS-API mechanism which is based on a public-
key, rather than a symmetric-key, infrastructure. One such mechanism
was described as part of the Distributed Authentication Security
Service (DASS) in [RFC-1507]. However, the mechanism described in
this document has been proposed as an alternative to the DASS
mechanism for several reasons.
1) The SPKM is simpler than DASS, containing no non-essential
functionality.
2) The SPKM allows three-way mutual authentication, whereas DASS
uses two-way mutual authentication; this enables environments
which do not have access to secure timestamps to nevertheless
have access to secure mutual authentication.
Adams Document Expiration: 31 December 1994 1
3) The SPKM uses Object Identifiers to specify various algorithms
to be used by the communicating peers. This allows maximum
flexibility for a variety of environments, for future
enhancements, and for alternative algorithms.
4) The SPKM allows the option of a true, asymmetric algorithm-
based, digital signature in the gss_sign() and gss_seal()
operations, whereas DASS uses an integrity checksum based on a
MAC computed with a symmetric algorithm (DES). For some
environments, the availability of true, non-repudiable digital
signatures is a necessity.
5) SPKM data formats and procedures are designed to be as similar
to those for the Kerberos mechanism as is practical. This is
done for ease of implementation in those environments where
Kerberos has already been implemented.
For the above reasons, it is felt that the SPKM will offer greater
flexibility and functionality than DASS, without undue complexity or
overhead.
KEY MANAGEMENT
The key management employed in SPKM is intended to be as compatible
as possible with both X.509 [X.509] and PEM [RFC-1422], since these
represent large communities of interest and show relative maturity in
standards.
ACKNOWLEDGMENTS
Much of the material in this document is based on the Kerberos
Version 5 GSS-API mechanism [KRB5], and is intended to be as
compatible with it as possible. This document also owes a great debt
to Warwick Ford of Bell-Northern Research for many fruitful
discussions and to John Linn of OpenVision Technologies for helpful
comments.
Adams Document Expiration: 31 December 1994 2
1. OVERVIEW
The SPKM is a mechanism for authentication, key establishment, data
integrity, and data confidentiality in an on-line distributed
application environment using a public-key infrastructure. This
mechanism conforms to the interface defined by the Generic Security
Service Application Program Interface [RFC-1508] and can therefore 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, among other things, non-repudiable
digital signatures to be employed for message exchanges.
Note that this document defines two separate mechanisms, SPKM-1 and
SPKM-2, which are identical except that SPKM-2 requires the presence
of secure timestamps for the purpose of replay detection during
context establishment and SPKM-1 does not. This allows greater
flexibility for applications since secure timestamps can not always
be guaranteed to be available in a given environment.
2. ALGORITHMS
A number of algorithm types are employed in SPKM. Each type, along
with its purpose and a set of specific examples, is described in this
section.
2.1 Integrity Algorithm (INT_ALG):
Purpose:
This algorithm is used to ensure that a message has not been
altered in any way after being constructed by the legitimate
sender. Depending on the algorithm used, the application of
this algorithm may also provide authenticity and non-
repudiability for the message.
Examples:
md5WithRSA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 3
}
This algorithm provides data integrity and non-repudiation
by computing an RSA signature on the MD5 hash of that data.
Note that this is equivalent to md5WithRSAEncryption {1 2
840 113549 1 1 4}, which is defined in [PKCS].
Adams Document Expiration: 31 December 1994 3
DES-MAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 10
}
This algorithm provides data integrity by computing a DES
MAC (as specified by [FIPS-113]) on that data.
DES-CBC OBJECT IDENTIFIER ::= { -- used only for gss_seal()
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV as a parameter
}
This algorithm provides data integrity by encrypting that
data using DES-CBC mode. At the receiving end, if the
decrypted data is correctly padded AND the decrypted
sequence number is correct, then the data was not altered.
2.2 Sequence Algorithm (SEQ_ALG):
Purpose:
This symmetric algorithm is used to construct the encrypted
sequence number for a token. Because it makes use of both
the (plaintext) sequence number and the integrity checksum,
an invalid message with a valid sequence number, and a valid
message with an invalid sequence number will both be
detected.
Examples:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV as a parameter
}
2.3 Confidentiality Algorithm (CONF_ALG):
Purpose:
This symmetric algorithm is used to generate the encrypted
data for gss_seal().
Examples:
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 7 -- carries IV as a parameter
}
Adams Document Expiration: 31 December 1994 4
2.4 Key Establishment Algorithm (KEY_ESTB_ALG):
Purpose:
This algorithm is used to establish a symmetric key for use
by both the initiator and the target over the established
context. This context key may be used as the encryption /
decryption key for either or both of SEQ_ALG and CONF_ALG.
Examples:
id-rsa-key-transport OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 22 -- imported from [X9.44]
}
In this algorithm, the context key is generated by the
initiator, encrypted with the RSA public key of the target,
and sent to the target. The target need not respond to the
initiator for the key to be established.
During context establishment in SPKM, the initiator offers a set of
possible symmetric encryption algorithms and a set of possible
integrity algorithms to the target. The symmetric algorithms
selected by the target become ones that may be used for SEQ_ALG and
CONF_ALG over the established context. The integrity algorithms
selected by the target become ones that may be used for INT_ALG over
the established context. Note that the order of the selected
integrity algorithms defines the values of the Quality of Protection
(QOP) parameter used in the gss_sign() and gss_seal() calls -- see
Section 5.2 for further details.
In future versions of SPKM, other algorithms may be specified for any
or all of INT_ALG, SEQ_ALG, CONF_ALG, and KEY_ESTB_ALG.
Adams Document Expiration: 31 December 1994 5
3. TOKEN FORMATS
This section discusses protocol-visible characteristics of the GSS-
API mechanism to be implemented atop the SPKM; it defines elements of
protocol for interoperability and is independent of language bindings
per [RFC-1509].
The SPKM GSS-API mechanism will be identified by an Object Identifier
representing "SPKM-1" or "SPKM-2", having the value:
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)}
or
{iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)},
where SPKM-1 uses 3-way mutual authentication for context
establishment and SPKM-2 uses 2-way mutual authentication for context
establishment.
Tokens transferred between GSS-API peers (for security context
management and per-message protection purposes) are defined.
3.1. Context Establishment Tokens
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "SPKM-1" or "SPKM-2"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
}
The innerContextToken of the initial context token will consist of an
SPKM_REQ message, preceded by a two-byte token-id (TOK_ID) field,
which shall contain the value 01 00.
The above GSS-API framing shall be applied to all tokens emitted by
the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT,
SPKM_ERROR, context-deletion, and per-message tokens, not just to the
initial token in a context establishment sequence. While not
required by RFC-1508, this enables implementations to perform
enhanced error-checking. The innerContextToken field of context
establishment tokens for the SPKM GSS-API mechanism will contain a
message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR), preceded
by a 2-byte TOK_ID field containing 01 00 for SPKM_REQ messages, 02
00 for SPKM_REP_TI messages, 03 00 for SPKM_REP_IT messages, and 04
00 for SPKM_ERROR messages.
The SPKM context establishment tokens are defined according to
[X.509] Section 10. SPKM-1 uses Section 10.4, "Three-way Authenti-
cation", and SPKM-2 uses Section 10.3, "Two-way Authentication" when
mutual authentication is requested by the initiator.
Adams Document Expiration: 31 December 1994 6
Relevant SPKM_REQ syntax is as follows (note that imports from other
documents are given in Appendix A):
SPKM-REQ ::= [APPLICATION xx] SEQUENCE {
certif_data [0] CertificationData OPTIONAL
requestToken [1] REQ_TOKEN
}
CertificationData ::= SEQUENCE {
certificationPath [0] CertificationPath
certificateRevocationList [1] CertificateList OPTIONAL
}
CertificationPath ::= SEQUENCE {
userCertificate [0] SingleCertificate
theCACertificates [1] SEQUENCE OF CertificatePair OPTIONAL
} -- certif. path from target to source
SingleCertificate ::= CHOICE { -- only one for now
Certificate -- imported from [X.509]
} -- (1993)
REQ_TOKEN ::= SIGNED SEQUENCE {
timestamp [0] UTCTime -- may be NULL for
-- mechanism SPKM-1
randSrc [1] Random_Integer,
targ_name [2] INTERNAL NAME,
req_data [3] Context_Data,
key_estb_id [4] OBJECT IDENTIFIER -- specifies key
-- estb. mechanism
key_estb_req [5] BIT STRING -- key estb. request
}
Random_Integer ::= BIT STRING
Context_Data ::= SEQUENCE {
channelId [0] ChannelId, -- channel bindings
seq_number [1] INTEGER OPTIONAL -- sequence number
options [2] Options
symm_alg [3] Symm_Alg -- symmetric enc. alg.
intg_alg [4] Intg_Alg -- integrity algorithm
}
Adams Document Expiration: 31 December 1994 7
ChannelId ::= OCTET STRING
Options ::= BIT STRING {
delegation_state (0),
mutual_state (1),
replay_det_state (2),
sequence_state (3),
conf_avail (4),
integ_avail (5)
}
Symm_Alg ::= SEQUENCE OF OBJECT IDENTIFIER -- for SEQ_ALG, CONF_ALG
Intg_Alg ::= SEQUENCE OF OBJECT IDENTIFIER -- order of agreed
-- sequence determines
-- meaning of QOP
-- parameter
A context establishment sequence based on the SPKM will perform one-
way authentication (without confirmation or any return token from
target to initiator in response to the initiator's SPKM_REQ) if the
mutual_req bit is not set in the application's call to
gss_init_sec_context(). Applications requiring authentication of
both peers (initiator as well as target) should request mutual
authentication, resulting in "mutual_state" being set within SPKM_REQ
Options. In response to such a request, the context target will
reply to the initiator with a token containing either an SPKM_REP_TI
or SPKM_ERROR. If mechanism SPKM-2 has been chosen, this completes
the 2-way mutual authentication context establishment exchange. If
mechanism SPKM-1 has been chosen and SPKM_REP_TI is sent, the
initiator will then reply to the target with either an SPKM_REP_IT or
SPKM_ERROR, completing the 3-way mutual context establishment
exchange.
Relevant SPKM_REP_TI syntax is as follows:
SPKM_REP_TI ::= SIGNED SEQUENCE {
timestamp [0] UTCTime -- may be NULL for
-- mechanism SPKM-1
randTarg [1] Random_Integer,
src_name [2] INTERNAL NAME,
randSrc [3] Random_Integer,
rep_data [4] Context_Data,
key_estb_rep [5] BIT STRING OPTIONAL -- key estb. response
}
Adams Document Expiration: 31 December 1994 8
Relevant SPKM_REP_IT syntax is as follows:
SPKM_REP_IT ::= SIGNED SEQUENCE {
randTarg [0] Random_Integer,
targ_name [1] INTERNAL NAME
}
The syntax of SPKM_ERROR is as follows:
SPKM_ERROR ::= [APPLICATION xx] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
error-code[2] INTEGER,
name[3] INTERNAL NAME,
e-text[4] GeneralString OPTIONAL,
e-data[5] OCTET STRING OPTIONAL
}
Values to be transferred in the error-code field of a SPKM_ERROR
message are defined in Section 5 of this specification.
Adams Document Expiration: 31 December 1994 9
3.2. Per-Message and Context Deletion Tokens
Three classes of tokens are defined in this section: "Sign" tokens,
emitted by calls to gss_sign() and consumed by calls to gss_verify(),
"Seal" tokens, emitted by calls to gss_seal() and consumed by calls
to gss_unseal(), and context deletion tokens, emitted by calls to
gss_delete_sec_context() and consumed by calls to
gss_process_context_token().
3.2.1. Per-message Tokens - Sign
Use of the gss_sign() call yields a token, separate from the user
data being protected, which can be used to verify the integrity of
that data as received. The token has the following format:
# of Bytes Name Description
2 TOK_ID Identification field.
Tokens emitted by gss_sign() contain
the hex value 01 01 in this field.
variable INT_ALG Integrity algorithm indicator (must
be one of the agreed integrity
algorithms for this context).
OBJECT IDENTIFIER
variable SEQ_ALG Encryption alg. to compute sequence
(must be one of the agreed symmetric
algorithms for this context).
OBJECT IDENTIFIER
2 filler Contains ff ff.
2 INT_LEN Contains bitlength of checksum.
8 SND_SEQ Sequence number field.
variable INT_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in INT_ALG field.
GSS-API tokens must be encapsulated within the higher-level protocol
by the application; no embedded length field is necessary.
3.2.1.1. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the data field, logically prepended by the first
8 bytes of the plaintext packet header. The result binds the data to
the packet type and integrity algorithm identifier fields.
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, and then computing an RSA signature on the 16-byte
MD5 result. The signature is computed using the RSA private key
retrieved from the credentials structure. The result (of bitlength
INT_LEN) is stored in the INT_CKSUM field. Note that for gss_sign(),
INT_ALG cannot specify a symmetric encryption algorithm.
Adams Document Expiration: 31 December 1994 10
3.2.1.2. Sequence Number
Sequence number field: The 8 byte plaintext sequence number field is
formed from the sender's four-byte sequence number as follows. If
the four bytes of the sender's sequence number are named s0, s1, s2
and s3 (from least to most significant), the plaintext sequence
number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
di), where 'di' is the direction-indicator (Hex 0 - sender is the
context initiator, Hex FF - sender is the context acceptor).
The field is then CBC encrypted using the symmetric algorithm
specified in SEQ_ALG, the context key, and an IV formed from the
first 8 bytes of the previously calculated INT_CKSUM field. After
sending a gss_sign() or gss_seal() token, the sender's sequence
number is incremented by one.
The receiver of the token will first verify the INT_CKSUM field. If
valid, the sequence number field may be decrypted and compared to the
expected sequence number. The repetition of the (effectively 1-bit)
direction indicator within the sequence number field provides
redundancy so that the receiver may verify that the decryption
succeeded.
Since the checksum computation is used as an IV to the sequence
number decryption, attempts to splice a checksum and sequence number
from different messages will be detected. The direction indicator
will detect packets that have been maliciously reflected.
3.2.2. Per-message Tokens - Seal
Use of the gss_seal() call yields a token which encapsulates the
input user data (optionally encrypted) along with associated
integrity check quantities. The token emitted by gss_seal() consists
of an integrity header whose format is identical to that emitted by
gss_sign() (except that the TOK_ID field contains the value 02 01),
followed by a body portion that contains either the plaintext data
(if CONF_ALG = ff ff) or encrypted data for any other supported value
of CONF_ALG.
Adams Document Expiration: 31 December 1994 11
The gss_seal() token has the following format:
# of Bytes Name Description
2 TOK_ID Identification field.
Tokens emitted by gss_seal() contain
the hex value 02 01 in this field.
variable INT_ALG Integrity algorithm indicator (must
be one of the agreed integrity
algorithms for this context).
OBJECT IDENTIFIER
variable SEQ_ALG Encryption alg. to compute sequence
(must be one of the agreed symmetric
algorithms for this context).
OBJECT IDENTIFIER
variable CONF_ALG Confidentiality algorithm indicator
(must be 'ff ff' or one of the agreed
symmetric algorithms for this
context).
OBJECT IDENTIFIER
ff ff - none
2 INT_LEN Contains bitlength of checksum.
8 SND_SEQ Encrypted sequence number field.
variable INT_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in INT_ALG field.
variable Data encrypted or plaintext padded data
GSS-API tokens must be encapsulated within the higher-level protocol
by the application; no embedded length field is necessary.
3.2.2.1. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the plaintext padded data field, logically
prepended by the first 8 bytes of the plaintext packet header. The
result binds the data to the packet type, protocol version, and
integrity algorithm identifier fields.
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, and then computing an RSA signature on the 16-byte
MD5 result. The signature is computed using the RSA private key
retrieved from the credentials structure. The result (of bitlength
INT_LEN) is stored in the INT_CKSUM field.
As another example, if the INT_ALG specifies a symmetric encryption
algorithm such as the DES-CBC algorithm -- note that this is
allowable for gss_seal() but not for gss_sign() -- then the encrypted
data itself acts as the checksum (therefore CONF_ALG must be the same
as INT_ALG). In this case the INT_CKSUM field contains the last
eight bytes of the encrypted data and INT_LEN contains the value 64.
Adams Document Expiration: 31 December 1994 12
3.2.2.2 Sequence Number
Sequence number field: The 8 byte plaintext sequence number field is
formed from the sender's four-byte sequence number as follows. If
the four bytes of the sender's sequence number are named s0, s1, s2
and s3 (from least to most significant), the plaintext sequence
number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
di), where 'di' is the direction-indicator (Hex 0 - sender is the
context initiator, Hex FF - sender is the context acceptor).
The field is then CBC encrypted using the symmetric algorithm
specified in SEQ_ALG, the context key, and an IV formed from the
first 8 bytes of the INT_CKSUM field.
After sending a gss_sign() or gss_seal() token, the sender's sequence
numbers are incremented by one.
3.2.2.3: Padding
Data padding: Before encryption and/or integrity checksum
calculation, plaintext data is padded to the next highest multiple of
8 bytes, by appending between 1 and 8 bytes, the value of each such
byte being the total number of pad bytes. For example, given data of
length 20 bytes, four pad bytes will be appended, and each byte will
contain the hex value 04. An 8-byte random confounder is prepended
to the data, and integrity checksums are calculated over the
resulting padded plaintext.
After padding, the data is encrypted according to the algorithm
specified in the CONF_ALG field. The data is encrypted using CBC
with an IV of zero. The key used is derived from the established
context key by XOR-ing the context key with the hexadecimal constant
f0f0f0f0f0f0f0f0.
Adams Document Expiration: 31 December 1994 13
3.2.3. Context deletion token
The token emitted by gss_delete_sec_context() is based on the packet
format for tokens emitted by gss_sign(). The context-deletion token
has the following format:
# of Bytes Name Description
2 TOK_ID Identification field.
Tokens emitted by
gss_delete_sec_context() contain
the hex value 01 02 in this field.
variable INT_ALG Integrity algorithm indicator (must
be one of the agreed integrity
algorithms for this context).
OBJECT IDENTIFIER
variable SEQ_ALG Encryption alg. to compute sequence
(must be one of the agreed symmetric
algorithms for this context).
OBJECT IDENTIFIER
2 filler Contains ff ff.
2 INT_LEN Contains bitlength of checksum.
8 SND_SEQ Sequence number field.
variable INT_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in INT_ALG field.
SND_SEQ will be calculated as for tokens emitted by gss_sign(). The
INT_CKSUM will be calculated as for tokens emitted by gss_sign(),
except that the user-data component of the "to-be-signed" data will
be a zero-length string.
Adams Document Expiration: 31 December 1994 14
4. NAME TYPES AND OBJECT IDENTIFIERS
No name types have yet been defined for SPKM. This section is for
further study.
5. PARAMETER DEFINITIONS
This section defines parameter values used by the SPKM GSS-API
mechanism. It defines interface elements in support of portability.
5.1. Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the SPKM GSS-API mechanism. Use of these
definitions will enable independent implementors to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of gss_display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation should make available, through include files or other
means, a facility to translate these symbolic names into the concrete
values which a particular GSS-API implementation uses to represent
the minor_status values specified in this section. It is recognized
that this list may grow over time, and that the need for additional
minor_status codes specific to particular implementations may arise.
5.1.1. Non-SPKM-specific codes
(Note that other codes may be added in the future.)
GSS_S_G_NOUSER
/* "UID does not resolve to username" */
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" */
Adams Document Expiration: 31 December 1994 15
5.1.2. SPKM-specific-codes
(Note that other codes may be added in the future.)
GSS_SPKM_S_KG_CCACHE_NOMATCH
/* "Principal in credential cache does not match desired name" */
GSS_SPKM_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_SPKM_S_KG_BAD_INT_ALG_TYPE
/* "Unknown integrity algorithm type in token" */
GSS_SPKM_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_SPKM_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
5.2. Quality of Protection Values
Quality of Protection (QOP) values are defined for the SPKM GSS-API
mechanism, and are used as input to gss_sign() and gss_seal() to
select among alternate integrity-checking algorithms. Once a set of
algorithms has been agreed upon by the context initiator and target,
the QOP parameter simply selects from this ordered set.
More specifically, the SPKM_REQ token may send a sequence of "n" OBJ.
IDs specifying integrity-checking algorithms supported by the
initiator. The target may support only a subset m (m <= n) of these,
and so will return the sequence of "m" OBJ. IDs which it supports in
the SPKM_REP_TI token. The first OBJ. ID is therefore the default
algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through
QOP = m-1, respectively. Any QOP value greater than or equal to m is
equated to m-1 and is therefore mapped to the last OBJ. ID in the
agreed set.
To aid in implementation and interoperability, the following
stipulations are made. The set of n OBJ. IDs sent by the initiator
must contain at least one specifying an algorithm which computes
a true digital signature, must contain at least one specifying any
other (non-signature) integrity algorithm, and may contain at least
one specifying a symmetric algorithm. The set of m OBJ. IDs returned
by the target must contain one specifying an algorithm which computes
a true digital signature in the first position, must contain one
specifying a (non-signature) integrity algorithm in the second
position, and must contain one specifying a symmetric encryption
algorithm or NULL in the final position.
Adams Document Expiration: 31 December 1994 16
The reason for these stipulations is to allow the QOP parameter to
convey the semantics of the desired integrity service without forcing
it to specify the actual algorithms to be used. The result is that
the application is always able to choose, in a completely general and
portable way, an integrity service which provides non-repudiation
semantics (by passing QOP = Hex 00), one which does not provide non-
repudiation semantics (by passing QOP = Hex 01), and one which uses
encryption for both integrity and confidentiality -- if this is
available over the established context -- (by passing QOP = Hex FF).
Note that an application which is aware of its own underlying
environment and/or is aware of the underlying environment of its peer
is not unduly constrained by the above stipulations because any other
number or kind of algorithms may be agreed upon during context
establishment, making other QOP values perfectly valid and meaningful
over that context and between those peers.
6. SECURITY CONSIDERATIONS
Security issues are discussed throughout this memo.
7. REFERENCES
[RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.
[RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC 1422.
[RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security
Service", RFC 1507.
[RFC-1508]: J. Linn, "Generic Security Service Application Program
Interface", RFC 1508.
[RFC-1509]: J. Wray, "Generic Security Service Application Program
Interface: C-bindings", RFC 1509.
[RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510.
[KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
Internet Draft draft-ietf-cat-kerb5gss-00.
[FIPS-113]: National Bureau of Standards, Federal Information
Processing Standard 113, "Computer Data Authentication", May 1985.
[PKCS]: RSA Encryption Standard, Version 1.4, RSA Data Security,
Inc., June 3, 1991.
[X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication Framework", CCITT
Recommendation X.509.
[X9.44]: ANSI, "Public Key Cryptography Using Reversible
Algorithms for the Financial Services Industry: Transport of
Symmetric Algorithm Keys Using RSA", X9.44-1993.
Adams Document Expiration: 31 December 1994 17
8. AUTHOR'S ADDRESS
Carlisle Adams
Bell-Northern Research, Ltd.
P.O.Box 3511, Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613.763.9008
E-mail: cadams@bnr.ca
Adams Document Expiration: 31 December 1994 18
Appendix: IMPORTS
A.1 ASN.1 encoding
The following definitions are taken from X.501 and X.509.
--CCITT Definitions:
joint-iso-ccitt OBJECT IDENTIFIER ::= {2}
ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
algorithm OBJECT IDENTIFIER ::= {ds 8}
encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}
hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2}
signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}
rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}
iso OBJECT IDENTIFIER ::= {1}
identified-organization OBJECT IDENTIFIER ::= {iso 3}
--1989 OSI Implementors Workshop "Stable" Agreements
oiw OBJECT IDENTIFIER ::= {identified-organization 14}
dssig OBJECT IDENTIFIER ::= {oiw 7}
oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2}
oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3}
--PKCS #1 definition [PKCS]
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1
}
--X.501 definitions
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
Name ::= CHOICE { --only one for now
RDNSequence
}
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
Adams Document Expiration: 31 December 1994 19
--X.509 definitions (with proposed 1992 extensions presumed)
ENCRYPTED MACRO ::=
BEGIN
TYPE NOTATION ::= type(ToBeEnciphered)
VALUE NOTATION ::= value(VALUE BIT STRING)
END -- of ENCRYPTED
SIGNED MACRO ::=
BEGIN
TYPE NOTATION ::= type (ToBeSigned)
VALUE NOTATION ::= value (VALUE
SEQUENCE{
ToBeSigned,
AlgorithmIdentifier, --of the algorithm used to
--generate the signature
ENCRYPTED OCTET STRING --where the octet string is the
--result of the hashing of the
--value of "ToBeSigned"
}
)
END -- of SIGNED
SIGNATURE MACRO ::=
BEGIN
TYPE NOTATION ::= type (OfSignature)
VALUE NOTATION ::= value (VALUE
SEQUENCE {
AlgorithmIdentifier, --of the algorithm used to compute
ENCRYPTED OCTET STRING -- the signature where the octet
-- string is a function (e.g., a
-- compressed or hashed version)
-- of the value 'OfSignature',
-- which may include the
-- identifier of the algorithm
-- used to compute the signature
}
)
END -- of SIGNATURE
Certificate ::= SIGNED 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
}
Adams Document Expiration: 31 December 1994 20
Version ::= INTEGER {v1(0), v2(1)}
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
NotBefore UTCTime,
NotAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
UID ::= BIT STRING
CertificatePair ::= SEQUENCE {
forward [0] SingleCertificate OPTIONAL,
reverse [1] SingleCertificate OPTIONAL
} -- at least one of the pair shall be present
CertificateList ::= SIGNED SEQUENCE {
signature [0] AlgorithmIdentifier,
issuer [1] Name,
thisUpdate [2] UTCTime,
nextUpdate [3] UTCTime OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime
} OPTIONAL
}
Adams Document Expiration: 31 December 1994 21
A.2 Encoding Rules
Whenever a structure is to be signed it must always be constructed
the same way. This is particularly important where a signed structure
has to be reconstructed by the recipient before the signature is
verified. The rules listed below are taken from X.509.
- the definite form of length encoding shall be used, encoded in
the minimum number of octets;
- for string types, the constructed form of encoding shall not
be used;
- if the value of a type is its default value, it shall be
absent;
- the components of a Set type shall be encoded in ascending
order of their tag value;
- the components of a Set-of type shall be encoded in ascending
order of their octet value;
- if the value of a Boolean type is true, the encoding shall
have its contents octet set to `FF'16;
- each unused bits in the final octet of the encoding of a
BitString value, if there are any, shall be set to zero;
- the encoding of a Real type shall be such that bases 8, 10 and
16 shall not be used, and the binary scaling factor shall be
zero.
Adams Document Expiration: 31 December 1994 22
| PAFTECH AB 2003-2026 | 2026-04-23 06:11:14 |