One document matched: draft-ietf-cat-srpgm-00.txt
CAT Working Group K.R. Burdis
Internet Draft Rhodes University
Expires: April 2000 October 1999
The Secure Remote Password GSS-API Mechanism (SRPGM)
draft-ietf-cat-srpgm-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a password-based low-infrastructure GSS-API
mechanism based on the Secure Remote Password protocol and the
existing Simple Public Key Mechanism.
Acknowledgements
This document is a synthesis of the work done by Thomas Wu in
developing SRP and Carlisle Adams in developing SPKM. Much of the
material in this document comes from RFC 2025, the SPKM GSS-API
mechanism specification. Many sections have been copied almost word-
for-word with only minor modifications and omissions where
appropriate.
Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
1 Overview
The Secure Remote Password Authentication and Key Exchange System
(SRP) is a security mechanism that provides mutual authentication and
the establishment of a shared session key.
Burdis [Page 1]
draft-ietf-cat-srpgm-00.txt October 1999
According to RFC 2078 there are certain specifications related to the
GSSAPI that are:
"documents defining token formats, protocols, and procedures to
be implemented in order to realize GSS-API services atop
particular security mechanisms"
This is such a document. It defines token formats, protocols, and
procedures to be implemented in order to realize GSS-API services
atop the SRP protocol, so that SRP can be used according to the GSS-
API operational paradigm:
"GSS-API operates in the following paradigm. A typical GSS-API
caller is itself a communications protocol, calling on GSS-API
in order to protect its communications with authentication,
integrity, and/or confidentiality security services."
Many of the protocols, procedures and conventions defined in SPKM are
re-used in order to provide security services using the SRP protocol.
The SPKM specification in RFC 2025 is described as follows:
"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."
The method of negotiating sets of integrity, confidentiality and one-
way function algorithms to be used over the context is re-used. The
use of sequence numbers for sequencing and fresh random numbers for
replay detection is also re-used. Token formats have been reused as
much as possible; SPKM specific data has been removed and replaced
with SRP specific data. SPKM key derivation, quality of protection
and support functions are also reused.
2 Motivation
SRP is described in [SRP-DRAFT] as follows:
"SRP is a strong network authentication mechanism, suitable for
negotiating secure connections using a user-supplied password,
while eliminating the security problems traditionally associated
with reusable passwords."
[SRP-DRAFT] describes the need for a secure password-based
authentication mechanism:
"The lack of a secure authentication mechanism that is also easy
to use has been a long-standing problem with the vast majority
of Internet protocols currently in use. The problem is two-fold:
Users like to use passwords that they can remember, but most
password-based authentication systems offer little protection
against even passive attackers, especially if weak and
easily-guessed passwords are used."
Burdis [Page 2]
draft-ietf-cat-srpgm-00.txt October 1999
It then goes on to describe SRP's security-relevant features:
"SRP meets the strictest requirements laid down in [RFC 1704]
for a non-disclosing authentication protocol. It offers complete
protection against both passive and active attacks, and
accomplishes this efficiently using a single
Diffie-Hellman-style round of computation, making it feasible
to use in both interactive and non-interactive authentication
for a wide range of Internet protocols. Since it retains its
security when used with low-entropy passwords, it can be
seamlessly integrated into existing user applications."
The two existing GSS-API mechanism specifications that have reached
Internet RFC status are Kerberos and SPKM. Both of these mechanisms
require additional infrastructure to be in place before they can be
used. Kerberos needs a key server, and SPKM needs a certification
authority and public-key infrastructure. There has been recent
interest by the IETF CAT Working Group in the development of low
infrastructure mechanisms:
"The CAT Working Group also defines supporting mechanisms to
provide security services; current activity includes
specification of "low infrastructure" mechanisms to support ease
of deployment and use."
SRP can be classified as a low-infrastructure mechanism [SRP-DRAFT]:
"Trusted key servers and certificate infrastructures are not
required, and clients are not required to store and manage any
long-term keys."
In order for SRP to operate, the server needs to have a verifier
database, and the client a memorized password.
3 Algorithms
3.1 SRP Algorithm
Optimised SRP as described in [SRP] is used, since this reduces the
total number of messages exchanged by grouping together pieces of
information that do not depend on earlier messages.
The SRP data and the tokens used to carry this data are illustrated
below:
Initiator Token Acceptor
C,A -- SRPGM-REQ -->
<-- SRPGM-REP -- s,B
M1 -- SRPGM-EVIDENCE -->
<-- SRPGM-EVIDENCE -- M2
where:
Burdis [Page 3]
draft-ietf-cat-srpgm-00.txt October 1999
C is the initiator's username
A is the initiator's ephemeral public key
B is the acceptor's ephemeral public key
M1 is the initiator's evidence that the shared key is known
M2 is the acceptor's evidence that the shared key is known
If mutual authentication is not requested by the initiator then the
second token from the acceptor to the initiator (M2) need not be sent.
For a more formal description of the protocol's operation and how each
of the above values are calculated, see [SRP-DRAFT].
The SRP-SHA1 algorithm described in [SRP-DRAFT] is the MANDATORY SRP
algorithm. SRP algorithms using other hash functions MAY be used.
3.2 Integrity Algorithms
Integrity algorithms are used to ensure that a message has not been
altered in any way after being constructed by the legitimate sender.
HMAC OBJECT IDENTIFIER :: {
}
This MANDATORY algorithm provides integrity protection using a message
digest and a secret key. The HMAC-SHA1 algorithm MUST be used to
calculate the message authentication code for the SRPGM-EVIDENCE
token.
3.3 One-Way Functions
Both the SRP protocol and the HMAC algorithm make use of an iterative
hash function in their operation. In addition a hash function is used
to derive the set of subkeys for the various confidentiality and
integrity algorithms supported over the context.
The SHA-1 hash function is specified as a MANDATORY one-way-function.
SHA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 18
}
The actual one-way function used over the context is specified by the
acceptor in the SRPGM-REP token.
3.4 Confidentiality Algorithms
Confidentiality algorithms are used with the SRPGM-WRAP token to
encrypt message data.
Burdis [Page 4]
draft-ietf-cat-srpgm-00.txt October 1999
DES-CBC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(4)
secsig(3) algorithm(2) 7
}
In the interests of interoperability support for this algorithm is
RECOMMENDED. However users SHOULD negotiate the use of a stronger
algorithm where possible.
3.5 Negotiation
During context establishment, the initiator offers a set of
possible integrity algorithms, a set of possible confidentiality
algorithms, and a set of possible one-way function algorithms to
the acceptor. The acceptor selects a single one-way function
(O-ALG) out of the set of possible one-way functions offered by
the initiator. This one-way function is used in the SRP protocol,
the HMAC integrity algorithm, and in the derivation of context
subkeys for the agreed upon integrity and confidentiality
algorithms. The confidentiality algorithms selected by the
acceptor become the set of confidentiality algorithms used over
the established context (C-ALGs) and the integrity algorithms
selected by the acceptor become the set of integrity algorithms
used over the established context (I-ALGs). The acceptor selects
algorithms by returning, in the same relative order, the subset of
of each offered set 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 algorithm 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 the gss_wrap() calls - see
Section 7 for details [SPKM].
3.6 Subkey Derivation
Having established a context key, both the initiator and acceptor
must be able to derive a set of subkeys for the various
confidentiality algorithms (C-ALGs) and integrity algorithms
(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 (ordered) list of agreed I-ALGs be
numbered in the same way. Finally, let the context key be a binary
string of arbitrary length "M", subject to the following
constraint: L <= M (where the lower limit "L" is the bit length of
the longest key needed by any agreed C-ALG or keyed I-ALG).
For example, if DES and two-key-triple-DES are the negotiated
confidentiality algorithms and DES-MAC is the negotiated keyed
integrity algorithm, then the context key must be at least 112 bits
long [SPKM].
Burdis [Page 5]
draft-ietf-cat-srpgm-00.txt October 1999
Note that SRP produces context keys that are twice the length of the
output of the one-way-function used. So, using SHA1 the context key
would be 320 bits long and using MD5 the context key would be 256
bits long. If the length of the context key is too short then the
size of the context key should be doubled using the Interleaved SHA
function described in Section 3.1 of [SRP-DRAFT].
The derivation algorithm for a k-bit subkey is specified as follows:
rightmost_k_bits (OWF(context_key || x || n || s || context_key))
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 the previous OWF outputs), until "k" bits have been generated;
* "||" is the concatenation operation; and
* "OWF" is any appropriate One-Way Function.
[SPKM]
4 Context Establishment Tokens
4.1 SRPGM-REQ
SRPGM-REQ ::= SEQUENCE {
token_id INTEGER(256),
context_id Random-INTEGER,
public_key_A BIT STRING,
username OCTET STRING,
req_data Context-Data,
validity Validity
}
token_id
Used to identify the type of token. It must have the value 256
(decimal).
context_id
Used to identify to which context the token belongs. Here this is a
fresh random number generated by the initiator. See section 8.3 for
more information.
Burdis [Page 6]
draft-ietf-cat-srpgm-00.txt October 1999
public_key_A
The ephemeral public key generated by the initiator.
username
The initiator's username.
req_data
Specifies the algorithms that the initiator supports and the
settings that the initiator requests for the context.
validity
The span of time that the initiator requests that the context be
valid for.
Context-Data ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seq-number INTEGER OPTIONAL,
options Options,
conf-algs Conf-Algs,
intg-algs Intg-Algs,
owf-algs OWF-Algs
}
channelId
Used to provide channel binding as per section 1.1.6 of RFC 2078
[GSS-APIv2].
seq-number
The initiator's initial sequence number, which is used for
sequencing and replay detection. See sections 5.3 and 5.4 for
details on sequence numbers and how they are processed.
options
The options requested by the initiator.
conf-algs
The set of confidentiality algorithms supported by the initiator, or
null.
intg-algs
The set of integrity algorithms supported by the initiator..
owf-algs
The set of one-way function algorithms supported by the initiator.
Note that the sets of algorithms MUST include those specified as
MANDATORY in section 3. See section 3.5 for details on how the
algorithm negotiation process takes place.
ChannelId ::= OCTET STRING
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL
Burdis [Page 7]
draft-ietf-cat-srpgm-00.txt October 1999
}
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
Options ::= BIT STRING {
delegation-state (0),
mutual-state (1),
replay-det-state (2),
sequence-state (3),
conf-state (4),
integ-state (5)
}
delegation-state
whether or not delegation should be allowed if available
mutual-state
whether or not mutual authentication is requested
replay-det-state
whether or not replay detection should be performed
sequence-state
whether or not sequencing should be performed
conf-state
whether or not confidentiality protection should be performed if
available
integ-state
whether or not integrity protection should be performed
4.2 SRPGM-REP
SRPGM-REP ::= SEQUENCE {
token_id INTEGER(512),
context_id INTEGER,
rep_data Context-Data,
validity Validity OPTIONAL,
salt INTEGER,
public_key_B BIT STRING,
u Random-INTEGER,
n INTEGER,
g INTEGER
}
token_id
Used to identify the type of token. It must have the value 512
(decimal).
context_id
Used to identify to which context the token belongs. See section
Burdis [Page 8]
draft-ietf-cat-srpgm-00.txt October 1999
8.3 for details on how it is calculated.
rep_data
Specifies the algorithms that the acceptor supports out of the lists
that the initiator provided, and the options that the acceptor will
provide for the context.
validity
The span of time that the acceptor will keep the context valid, if
different from the initiator's requested context lifetime.
salt
The random salt associated with the username.
public_key_B
The ephemeral public key generated by the acceptor.
u
A random number.
n
A large prime number. All additions, multiplications, and
exponentiations are performed modulo n.
g
A generator in the finite field GF(n).
Note, that if the values for n and g in the SRPGM-REP token are
different from the ones that the initiator used in its calculations
for the SRPGM-REQ token, then the initiator MUST send a new SRPGM-REQ
token with data computed using the new values for n and g.
Context-Data ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seq-number INTEGER OPTIONAL,
options Options,
conf-algs Conf-Algs,
intg-algs Intg-Algs,
owf-algs OWF-Algs
}
channelId
Used to provide channel binding as per section 1.1.6 of RFC 2078
[GSS-APIv2].
seq-number
The acceptor's initial sequence number, which is used for
sequencing. See sections 5.2 and 5.3 for details on sequence numbers
and how they are processed.
options
The options requested by the initiator that acceptor is prepared to
honour.
Burdis [Page 9]
draft-ietf-cat-srpgm-00.txt October 1999
conf-algs
The set of confidentiality algorithms selected by the acceptor, or
null.
intg-algs
The set of integrity algorithms selected by the acceptor.
owf-algs
The set of one-way function algorithms selected by the initiator.
Note that the sets of algorithms MUST include those specified as
MANDATORY in section 3. See section 3.5 for details on how the
algorithm negotiation process takes place.
4.3 SRPGM-EVIDENCE
SRPGM-EVIDENCE ::= SEQUENCE {
evidence EVIDENCE-TOKEN,
evidenceIntg BIT STRING
}
evidence
evidence that the sender knows the shared context key.
evidenceIntg
The integrity checksum.
EVIDENCE-TOKEN ::= SEQUENCE {
token_id INTEGER(768),
context_id INTEGER,
seqnumInitiator INTEGER,
seqnumAcceptor INTEGER,
context_data Context-Data,
validity Validity,
evidence BIT STRING
}
token_id
Used to identify the type of token. It must have the value 768
(decimal).
context_id
Used to identify to which context the token belongs. See section
8.3.
seqnumInitiator
The initiator's initial sequence number.
seqnumAcceptor
The acceptor's initial sequence number.
context_data
The agreed upon context settings and algorithm lists.
Burdis [Page 10]
draft-ietf-cat-srpgm-00.txt October 1999
validity
The agreed upon context lifetime.
evidence
Proof that the sender knows the shared context key.
The contents of the EVIDENCE-TOKEN are integrity protected by
computing a checksum of the encoded contents of this token using the
HMAC-SHA1 algorithm and the shared context key. The checksum is stored
in the evidenceIntg field of the SRPGM-EVIDENCE token.
In SRPGM, the initial exchange of sequence numbers is not in integrity
protected tokens. Nor is the negotiation of context settings and valid
algorithms. For this reason, the sequence numbers, the agreed upon
context settings, the agreed upon one-way function and the sets of
agreed upon integrity and confidentiality algorithms are included as
part of the EVIDENCE-TOKEN, which is integrity protected. The receiver
of the token MUST check that these values in the token are consistent
with what it believes the negotiated values are, and send an SRPGM-DEL
token if they are not.
The lack of integrity protection of the SRPGM-REQ and SRPGM-REP tokens
is the reason why the HMAC-SHA1 algorithm (the mandatory integrity
algorithm) must be used to compute the checksum on the SRPGM-EVIDENCE
token. The set of negotiated integrity algorithms can not be trusted
before the SRPGM-EVIDENCE token is generated, because this set of
algorithms may have been modified by an attacker.
4.4 Error Token
Error tokens are used to signal errors that occur during the context
establishment process.
SRPGM-ERROR ::= SEQUENCE {
tok-id INTEGER (1024),
context-id Random-Integer
}
token_id
Used to identify the type of token. It must have the value 1024
(decimal).
context_id
Used to identify to which context the token belongs. See section
8.3.
The SRPGM-ERROR token is only used during the context establishment
process. If an SRPGM-REQ or SRPGM-REP token is received in error, the
receiving function (either gss_init_sec_context() or
gss_accept_sec_context()) will generate an SRPGM-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
Burdis [Page 11]
draft-ietf-cat-srpgm-00.txt October 1999
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 SRPGM-ERROR token but will instead be an SRPGM-DEL token
which will be processed by the peer's gss_process_context_token().
If gss_init_sec_context() receives an error token (whether valid or
invalid), it will regenerate SRPGM-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 a SRPGM-REQ token when it is
expecting an SRPGM-EVIDENCE token, it will discard the data from the
previous SRPGM-REQ token and process the new one. This usually results
when the initiator uses values for n and g that are different to those
used by the acceptor.)
Similarly, if gss_accept_sec_context() receives an error token
(whether valid or invalid), it will regenerate SRPGM-REP as its output
token and return a major status code of GSS_S_CONTINUE_NEEDED [SPKM].
Note that, unlike SPKM, error tokens are not integrity protected, so
they could be used to perform a denial-of-service attack, preventing
context establishment from taking place.
5 Per-Message and Context Deletion Tokens
Three classes of tokens are defined in this section: "MIC" tokens,
emitted by calls to gss_getMIC() and consumed by calls to
gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and
consumed by calls to gss_unwrap(); and context deletion tokens,
emitted by calls to gss_init_sec_context(), gss_accept_sec_context(),
or gss_delete_sec_context() and consumed by calls to
gss_process_context_token() [SPKM].
5.1 Checksum
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.
If the integrity algorithm specifies a keyed hashing algorithm (for
example, DES-MAC or HMAC-SHA1), then the key to be used is the
appropriate subkey derived from the context key (see Section 3.6)
[SPKM].
5.2 Data Encryption
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.
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
Burdis [Page 12]
draft-ietf-cat-srpgm-00.txt October 1999
from the established context key using the subkey derivation algorithm
described in Section 3.6 (this ensures that the subkey used for
encryption and the subkey used for a separate, keyed integrity
algorithm are different) [SPKM].
5.3 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 SRPGM purely for security, as opposed to
reliability, reasons (that is, to avoid malicious loss, replay, or
re-ordering of SRPGM 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 SRPGM-REQ and the
acceptor's initial sequence number may be explicitly given in the
Context-Data field of SRPGM-REP; 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 sequence number is incremented by 1 [SPKM].
5.4 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.
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 [SPKM].
5.5 SRPGM-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
Burdis [Page 13]
draft-ietf-cat-srpgm-00.txt October 1999
separately by the sending application and it is the receiving
application's responsibility to associate the received data with the
received token [SPKM].
The SRPGM-MIC token has the following format:
SRPGM-MIC ::= SEQUENCE {
mic-header MIC-Header,
int-cksum BIT STRING
}
int-cksum
Checksum over header and data calculated according to the algorithm
specified in the int-alg field of mic-header. See section 5.1.
Mic-Header ::= SEQUENCE {
tok-id INTEGER (257),
context-id Random-INTEGER,
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
tok-id
Used to identify the type of token. It must have the value 257
(decimal).
context-id
Used to identify to which context the token belongs. See section
8.3.
int-alg
The integrity algorithm used to produce the checksum.
snd-seq
The sender's sequence number.
SeqNum ::= SEQUENCE {
num INTEGER,
dir-ind BOOLEAN
}
num
The actual sequence number
dir-ind
The boolean direction indicator. FALSE - sender is the context
initiator, TRUE - sender is the context acceptor.
See sections 5.3 and 5.4 for a description of sequence numbers and how
they are processed.
5.6 SRPGM-WRAP
SRPGM-WRAP ::= SEQUENCE {
Burdis [Page 14]
draft-ietf-cat-srpgm-00.txt October 1999
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
Wrap-Header ::= SEQUENCE {
tok-id INTEGER(513),
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
conf-alg [1] Conf-Alg OPTIONAL,
snd-seq [2] SeqNum OPTIONAL
}
tok-id
Used to identify the type of token. It must have the value 513
(decimal).
context-id
Used to identify to which context the token belongs. See section
8.3.
int-alg
The integrity algorithm used to construct the integrity checksum.
conf-alg
The confidentiality algorithm (if any) used encrypt the message
data.
snd-seq
The sender's sequence number, used for sequencing and replay
detection. See sections 5.3 and 5.4.
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
data BIT STRING
}
int-chksum
The checksum of the header and data, used for integrity protection.
See section 5.1.
data
The encrypted or plaintext data. See section 5.2.
Conf-Alg ::= CHOICE {
algId [0] AlgorithmIdentifier,
null [1] NULL
}
Due to restrictions on the use of encryption in some countries, the
confidentiality algorithm may be null indicating that no encryption of
the data is to take place [SPKM]. See section 5.1 for details on how
the checksum is created, and section 5.2 for a description of how data
encryption takes place.
Burdis [Page 15]
draft-ietf-cat-srpgm-00.txt October 1999
5.7 SRPGM-DEL
This token is issued by the gss_delete_sec_context() GSS-API method
call and is used to delete the context between the initiator and
acceptor [GSS-APIv2].
SRPGM-DEL ::= SEQUENCE {
del-header Del-Header,
int-cksum BIT STRING
}
int-cksum
The integrity checksum of the header.
Del-Header ::= SEQUENCE {
tok-id INTEGER (769),
context-id Random-Integer,
int-alg[0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
tok-id
Used to identify the type of token. It must have the value 769
(decimal).
context-id
Used to identify to which context the token belongs. See section
8.3.
int-alg
The integrity algorithm used to construct the integrity checksum.
snd-seq
The sender's sequence number, used for sequencing and replay
detection. See sections 5.3 and 5.4.
6 Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the SRPGM 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 [SPKM].
6.1 Non-SRPGM-specific codes (Minor Status Code MSB, bit 31, SET)
Burdis [Page 16]
draft-ietf-cat-srpgm-00.txt October 1999
6.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" */
6.1.2 Implementation-Related codes (Minor Status Code bit 30 OFF)
GSS_S_G_MEMORY_ALLOC
/* "Couldn't perform requested memory allocation" */
6.2 SRPGM-specific-codes (Minor Status Code MSB, bit 31, OFF)
GSS_SRPGM_S_SG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_SRPGM_S_SG_BAD_INT_ALG_TYPE
/* "Unknown integrity algorithm type in token" */
GSS_SRPGM_S_SG_BAD_CONF_ALG_TYPE
/* "Unknown confidentiality algorithm type in token" */
GSS_SRPGM_S_SG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
GSS_SRPGM_S_SG_BAD_INT_ALG_SET
/* "No integrity algorithm in common from offered set" */
GSS_SRPGM_S_SG_BAD_CONF_ALG_SET
/* "No confidentiality algorithm in common from offered set" */
GSS_SRPGM_S_SG_BAD_OWF_ALG_SET
/* "No one-way function algorithm in common from offered set" */
GSS_SRPGM_S_SG_INVALID_TOKEN_DATA
/* "Data is improperly formatted: cannot encode into token" */
GSS_SRPGM_S_SG_INVALID_TOKEN_FORMAT
/* "Received token is improperly formatted: cannot decode" */
Burdis [Page 17]
draft-ietf-cat-srpgm-00.txt October 1999
GSS_SRPGM_S_SG_CONTEXT_DELETED
/* "Context deleted at peer's request" */
GSS_SRPGM_S_SG_BAD_DELETE_TOKEN_RECD
/* "Invalid delete token received -- context not deleted "*/
GSS_SRPGM_S_SG_CONTEXT_ESTB_ABORT
/* "Unrecoverable context establishment error. Context deleted"*/
GSS_SRPGM_S_SG_INVALID_KEY
/* "Invalid ephemeral public key"*/
GSS_SRPGM_S_SG_INVALID_EVIDENCE
/* "Invalid evidence provided to prove knowledge of context key and
settings." */
7 Quality of Protection Values
The Quality of Protection (QOP) parameter is used in the SRPGM 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 SRPGM-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 acceptor
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 SRPGM-REP token (in the same relative orders as
those given by the initiator). Thus, the initiator and acceptor each
know the algorithms which they themselves support and the algorithms
which both sides support (the latter are defined to be those supported
over the established context). The QOP parameter has meaning and
validity with reference to this knowledge. For example, an application
may request integrity algorithm number 3 as defined by the mechanism
specification. If this algorithm is supported over this context then
it is used; otherwise, GSS_S_FAILURE and an appropriate minor status
code are returned.
The QOP parameter for SPKM is defined to be a 32-bit unsigned integer
(an OM_uint32) with the following bit-field assignments:
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
----------------------------------|---------------------------------
| TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) |
----------------------------------|---------------------------------
where
TS is a 5-bit Type Specifier (a semantic qualifier whose value
Burdis [Page 18]
draft-ietf-cat-srpgm-00.txt October 1999
specifies the type of algorithm which may be used to protect the
corresponding token -- see below for details);
U is a 3-bit Unspecified field (available for future use/expansion);
IA is a 4-bit field enumerating Implementation-specific Algorithms;
and
MA is a 4-bit field enumerating Mechanism-defined Algorithms.
The interpretation of the QOP parameter is as follows (note that the
same procedure is used for both the confidentiality and the integrity
halves of the parameter). The MA field is examined first. If it is
non-zero then the algorithm used to protect the token is the
mechanism-specified algorithm corresponding to that integer value.
If MA is zero then IA is examined. If this field value is non-zero
then the algorithm used to protect the token is the implementation-
specified algorithm corresponding to that integer value (if this
algorithm is available over the established context). Note that use of
this field may hinder portability since a particular value may specify
one algorithm in one implementation of the mechanism and may not be
supported or may specify a completely different algorithm in another
implementation of the mechanism.
Finally, if both MA and IA are zero then TS is examined. A value of
zero for TS specifies the default algorithm for the established
context, which is defined to be the first algorithm on the initiator's
list of offered algorithms (confidentiality or integrity, depending on
which half of QOP is being examined) which is supported over the
context. A non-zero value for TS corresponds to a particular
algorithm qualifier and selects the first algorithm supported over the
context which satisfies that qualifier.
The following TS values (i.e., algorithm qualifiers) are specified;
other values may be added in the future.
For the Confidentiality TS field:
00001 (1) = SRPGM_SYM_ALG_STRENGTH_STRONG
00010 (2) = SRPGM_SYM_ALG_STRENGTH_MEDIUM
00011 (3) = SRPGM_SYM_ALG_STRENGTH_WEAK
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
Burdis [Page 19]
draft-ietf-cat-srpgm-00.txt October 1999
confidentiality and integrity (since "0" is reserved for "default").
This document specifies three for confidentiality and none for
integrity, leaving a lot of room for future specification. Suggestions
of qualifiers such as "fast", "medium-speed", and "slow" have been
made, but such terms are difficult to quantify (and in any case are
platform- and processor-dependent), and so have been left out of this
initial specification. The intention is that the TS terms be
quantitative, environment-independent qualifiers of algorithms, as
much as this is possible.
Use of the QOP structure as defined above is ultimately meant to be as
follows.
* TS values are specified at the GSS-API level and are therefore
portable across mechanisms. Applications which know nothing about
algorithms are still able to choose "quality" of protection for
their message tokens.
* MA values are specified at the mechanism level and are therefore
portable across implementations of a mechanism. For example, all
implementations of the Kerberos V5 GSS mechanism must support
GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
(Note that these Kerberos-specified integrity QOP values do not
conflict with the QOP structure defined above.)
* IA values are specified at the implementation level (in user
documentation, for example) and are therefore typically
non-portable. An application which is aware of its own mechanism
implementation and the mechanism implementation of its peer,
however, is free to use these values since they will be perfectly
valid and meaningful over that context and between those peers.
The receiver of a token must pass back to its calling application a
QOP parameter with all relevant fields set. For example, if triple-DES
has been specified by a mechanism as algorithm 8, then a receiver of a
triple-DES-protected token must pass to its application (QOP
Confidentiality TS=1, IA=0, MA=8). In this way, the application is
free to read whatever part of the QOP it understands (TS or IA/MA).
In accordance with the MANDATORY and RECOMMENDED algorithms given in
Section 3, the following QOP values are specified for SRPGM.
For the Confidentiality MA field:
0001 (1) = DES-CBC
For the Integrity MA field:
0001 (1) = HMAC-SHA1
Burdis [Page 20]
draft-ietf-cat-srpgm-00.txt October 1999
[SPKM]
8 Support Functions
This section describes a mandatory support function for
SRPGM-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 SRPGM context-establishment, error,
context-deletion, and per-message tokens. The function is defined in
the following section [SPKM].
8.1 SPKM_Parse_token call
Inputs:
* input_token OCTET STRING
Outputs:
* major_status INTEGER,
* minor_status INTEGER,
* mech_type OBJECT IDENTIFIER,
* token_type INTEGER,
* context_handle CONTEXT HANDLE,
Return major_status codes:
* 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).
* 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.
* GSS_S_NO_TYPE indicates that the token-id information could be
parsed, but it did not correspond to any valid token_type. (Note
that this major status code has not been defined for GSS in
RFC-1508. Until such a definition is made (if ever), SRPGM
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.)
* GSS_S_NO_CONTEXT indicates that the context-id could be parsed, but
it did not correspond to any valid context_handle.
* GSS_S_FAILURE indicates that the mechanism type could not be parsed
(for example, the token may be corrupted).
SRPGM_Parse_token() is used to return to an application the mechanism
type, token type, and context handle which correspond to a given input
Burdis [Page 21]
draft-ietf-cat-srpgm-00.txt October 1999
token. Since GSS-API tokens are meant to be opaque to the calling
application, this function allows the application to determine
information about the token without having to violate the opaqueness
intention of GSS. Of primary importance is the token type, which the
application can then use to decide which GSS function to call in order
to have the token processed.
If all tokens are framed as suggested in RFC-1508, Appendix B
(specified both in the Kerberos V5 GSS mechanism [KRB5] and in this
document), then any mechanism implementation should be able to return
at least the mech_type parameter (the other parameters being NULL) for
any uncorrupted input token. If the mechanism implementation whose
SRPGM_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 SRPGM does), then an implementation
can map the context-id to a context_handle and return this to the
application. This is necessary for the situation where an application
has multiple contexts open simultaneously, all using the same
mechanism. When an incoming token arrives, the application can use
this function to determine not only which GSS function to call, but
also which context_handle to use for the call. Note that this function
does no cryptographic processing to determine the validity of tokens;
it simply attempts to parse the mech_type, token_type, and context-id
fields of any token it is given. Thus, it is conceivable, for
example, that an arbitrary buffer of data might start with random
values which look like a valid mech_type and that SRPGM_Parse_token()
would return incorrect information if given this buffer. While
conceivable, however, such a situation is unlikely.
The SRPGM_Parse_token() function is mandatory for SRPGM-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 SRPGM_Parse_token(). Furthermore, if this function ever
migrates up to the GSS-API level, then SRPGM_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].
8.2 The token_type Output Parameter
The following token types are defined:
GSS_INIT_TOKEN = 1
GSS_ACCEPT_TOKEN = 2
GSS_ERROR_TOKEN = 3
GSS_SIGN_TOKEN = GSS_GETMIC_TOKEN = 4
GSS_SEAL_TOKEN = GSS_WRAP_TOKEN = 5
Burdis [Page 22]
draft-ietf-cat-srpgm-00.txt October 1999
GSS_DELETE_TOKEN = 6
All SRPGM mechanisms shall be able to perform the mapping from the
token-id information which is included in every token (through the tag
values in SRPGMInnerContextToken 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].
8.3 The context_handle Output Parameter
The SRPGM mechanism implementation is responsible for maintaining a
mapping between the context-id value which is included in every token
and a context_handle, thus associating an individual token with its
proper context. Clearly the value of context_handle may be locally
determined and may, in fact, be associated with memory containing
sensitive data on the local system, and so having the context-id
actually be set equal to a computed context_handle will not work in
general. Conversely, having the context_handle actually be set equal
to a computed context-id will not work in general either, because
context_handle must be returned to the application by the first call
to gss_init_sec_context() or gss_accept_sec_context(), whereas
uniqueness of the context-id (over all contexts at both ends) may
require that both initiator and target be involved in the computation.
Consequently, context_handle and context-id must be computed
separately and the mechanism implementation must be able to map from
one to the other by the completion of context establishment at the
latest.
Computation of context-id during context establishment is accomplished
as follows. Each SRPGM 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 SRPGM-REQ
token. The acceptor then 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 SRPGM-REP and
in all subsequent tokens over that context.
Having both peers contribute to the context-id assures each peer of
freshness and therefore precludes replay attacks between contexts
(where a token from an old context between two peers is maliciously
injected into a new context between the same or different peers)
[SPKM].
9 Security Considerations
Security issues are discussed throughout this document.
This mechanism relies on the security of SRP, which bases its security
Burdis [Page 23]
draft-ietf-cat-srpgm-00.txt October 1999
on the difficulty of solving the Diffie-Hellman problem in the
multiplicative field modulo a large safe prime. See section 4
"Security Considerations" of [SRP-DRAFT] and section 4 "Security
analysis" of [SRP].
This mechanism also relies on the security of the HMAC algorithm and
the underlying hash function. Section 6 "Security" of [HMAC] discusses
these security issues in detail.
10. References
[ASN.1] Kaliski, Burton, "A Layman's Guide to a Subset of
ASN.1, BER, and DER", RSA Laboratories Technical Note, RSA Data
Security Inc. Public-Key Cryptography Standards (PKCS), November 1993
[CAT-WG] WWW, "Common Authentication Technology (cat) Charter",
URL: http://www.ietf.org/html.charters/cat-charter.html
[GSS-APIv1] Linn, John, "Generic Security Service Application
Program Interface", Internet RFC 1508
[GSS-APIv2]: Linn, John, "Generic Security Service Application
Program Interface, Version 2", Internet RFC 2078
[HMAC] Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message
Authentication", Internet RFC 2104
[KEYWORDS] Bradner, Scott, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119
[KRB5] Linn, John, "The Kerberos Version 5 GSS-API Mechanism",
Internet RFC 1964
[SPKM]: Adams, Carlisle, "The Simple Public-Key GSSAPI
Mechanism (SPKM)", Internet RFC 2025
[SRP] Wu, Thomas, "The Secure Remote Password Protocol", 1998
Internet Society Symposium on Network and Distributed Security
[SRP-DRAFT] Wu, Thomas, "The SRP Authentication and Key Exchange
System", Internet Draft, draft-wu-srp-auth-03.txt
[SRP-ADV] WWW, "Advantages and Benefits of SRP", URL:
http://srp.stanford.edu/srp/advantages.html
11. Author's Address
Keith Burdis
Computer Science Department
Rhodes University
6139 Grahamstown
Email: cskb@cs.ru.ac.za
Burdis [Page 24]
draft-ietf-cat-srpgm-00.txt October 1999
Appendix A: ASN.1 Definitions
SRPGM-REQ ::= SEQUENCE {
token_id INTEGER(256),
context_id Random-INTEGER,
public_key_A BIT STRING,
username OCTET STRING,
req_data Context-Data,
validity Validity
}
Context-Data ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seq-number INTEGER OPTIONAL,
options Options,
conf-algs Conf-Algs,
intg-algs Intg-Algs,
owf-algs OWF-Algs
}
ChannelId ::= OCTET STRING
Conf-Algs ::= CHOICE {
algs [0] SEQUENCE OF AlgorithmIdentifier,
null [1] NULL
}
Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
Options ::= BIT STRING {
delegation-state (0),
mutual-state (1),
replay-det-state (2),
sequence-state (3),
conf-state (4),
integ-state (5)
}
SRPGM-REP ::= SEQUENCE {
token_id INTEGER(512),
context_id INTEGER,
rep_data Context-Data,
validity Validity OPTIONAL,
salt INTEGER,
public_key_B BIT STRING,
u Random-INTEGER,
n INTEGER,
g INTEGER
}
SRPGM-EVIDENCE ::= SEQUENCE {
evidence EVIDENCE-TOKEN,
Burdis [Page 25]
draft-ietf-cat-srpgm-00.txt October 1999
evidenceIntg BIT STRING
}
EVIDENCE-TOKEN ::= SEQUENCE {
token_id INTEGER(768),
context_id INTEGER,
seqnumInitiator INTEGER,
seqnumAcceptor INTEGER,
context_data Context-Data,
validity Validity,
evidence BIT STRING
}
SRPGM-ERROR ::= SEQUENCE {
tok-id INTEGER (1024),
context-id Random-Integer
}
SRPGM-MIC ::= SEQUENCE {
mic-header MIC-Header,
int-cksum BIT STRING
}
Mic-Header ::= SEQUENCE {
tok-id INTEGER (257),
context-id Random-INTEGER,
int-alg [0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
SeqNum ::= SEQUENCE {
num INTEGER,
dir-ind BOOLEAN
}
SRPGM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
Wrap-Header ::= SEQUENCE {
tok-id INTEGER(513),
context-id Random-Integer,
int-alg [0] AlgorithmIdentifier OPTIONAL,
conf-alg [1] Conf-Alg OPTIONAL,
snd-seq [2] SeqNum OPTIONAL
}
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
data BIT STRING
}
Conf-Alg ::= CHOICE {
Burdis [Page 26]
draft-ietf-cat-srpgm-00.txt October 1999
algId [0] AlgorithmIdentifier,
null [1] NULL
}
SRPGM-DEL ::= SEQUENCE {
del-header Del-Header,
int-cksum BIT STRING
}
Del-Header ::= SEQUENCE {
tok-id INTEGER (769),
context-id Random-Integer,
int-alg[0] AlgorithmIdentifier OPTIONAL,
snd-seq [1] SeqNum OPTIONAL
}
RandomInteger ::= BIT STRING
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
paramter ANY DEFINED BY algorithm OPTIONAL
}
Burdis [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-23 10:39:50 |