One document matched: draft-ietf-cat-srpgm-02.txt
Differences from draft-ietf-cat-srpgm-01.txt
CAT Working Group K.R. Burdis
Internet Draft Rhodes University
Expires: July 2000 January 2000
draft-ietf-cat-srpgm-02.txt
The Secure Remote Password GSS-API Mechanism (SRPGM)
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 (SRP) and the
existing Simple Public Key Mechanism (SPKM). This mechanism is
suitable for establishing a secure context between two entities that
have established a shared secret as per the SRP protocol.
Acknowledgements
This document is a synthesis of the work done by Thomas Wu in
developing SRP and Carlisle Adams in developing SPKM. I am grateful
for the excellent work done by these two authors. The idea of using
SPKM as a basis for an SRP-based GSS-API mechanism comes from Mike
Eisler's LIPKEY. Some parts of [SPKM] have been reused in this
document.
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].
Burdis [Page 1]
draft-ietf-cat-srpgm-02.txt January 2000
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Relationship to SPKM . . . . . . . . . . . . . . . . . . . . . 4
4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. SRP Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Integrity Algorithms . . . . . . . . . . . . . . . . . . . . 5
4.3. One-Way Functions . . . . . . . . . . . . . . . . . . . . . 6
4.4. Confidentiality Algorithms . . . . . . . . . . . . . . . . . 6
4.5. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Subkey Derivation . . . . . . . . . . . . . . . . . . . . . 7
5. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Context Establishment Tokens . . . . . . . . . . . . . . . . 8
5.1.1. SrpgmReq . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.2. SrpgmParameters . . . . . . . . . . . . . . . . . . . . 11
5.1.3. SrpgmRep . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.4. SrpgmEvidence . . . . . . . . . . . . . . . . . . . . . 14
5.1.5. SrpgmError . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Per-Message and Context Deletion Tokens . . . . . . . . . 15
6. Miscellaneous Details . . . . . . . . . . . . . . . . . . . 15
6.1. Minor Status Codes . . . . . . . . . . . . . . . . . . . . 15
6.2. Quality of Protection . . . . . . . . . . . . . . . . . . 16
6.3. Support Functions . . . . . . . . . . . . . . . . . . . . 17
6.4. Context-ids . . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Sequence numbers . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
A. Modulus and Generator values . . . . . . . . . . . . . . . . 19
B. ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . . . 20
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.
According to RFC 2078 there are certain specifications related to the
GSS-API 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."
Burdis [Page 2]
draft-ietf-cat-srpgm-02.txt January 2000
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."
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 [CAT-WG] 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.
Burdis [Page 3]
draft-ietf-cat-srpgm-02.txt January 2000
3 Relationship to SPKM
Many of the protocols, procedures and conventions defined in SPKM are
re-used:
* The method of negotiating algorithms to be used over the context
* The use of sequence numbers to avoid malicious loss, replay or
reordering of tokens after context establishment
* The process of deriving subkeys from the context key
* Quality of Protection values, and support functions
* Token formats for per-message and context deletion tokens.
The appropriate sections in the SPKM specification are referred to
and any SRPGM-specific changes are noted.
SRPGM context establishment tokens are derived from corresponding
SPKM tokens. The table below shows these relationships:
+--------------+-----------------+
| SPKM | SRPGM |
+--------------+-----------------+
| SPKM-REQ | SRPGM-REQ |
| SPKM-REP-TI | SRPGM-REP |
| SPKM-REP-IT | SRPGM-EVIDENCE |
| SPKM-ERROR | SRPGM-ERROR |
+--------------+-----------------+
This should be kept in mind when reading the SPKM sections that are
referred to in this document.
4 Algorithms
4.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 -- SrpgmReq -->
<-- SrpgmRep -- s,B
M1 -- SrpgmEvidence -->
-- SrpgmEvidence --> M2
where:
Burdis [Page 4]
draft-ietf-cat-srpgm-02.txt January 2000
* C is the initiator's username
* A is the initiator's ephemeral public key
* s is the initiator's password salt
* 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.
It is RECOMMENDED that the acceptor use values for n and g chosen from
those listed in Appendix A so that the initiator can avoid expensive
constraint checks, since these predefined values already meet the
constraints described in [SRP-DRAFT]:
"For maximum security, N should be a safe prime (i.e. a number
of the form N = 2q + 1, where q is also prime). Also, g should
be a generator modulo N (see [SRP] for details), which means
that for any X where 0 < X < N, there exists a value x for which
g^x % N == X."
4.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.
The following MANDATORY algorithm provides integrity protection using
a message digest and a secret key:
HMAC-MD5 OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) isakmpOakley(2)
}
Motivation for the use of the HMAC algorithm comes from [RFC 2316]:
"One particular technique used by IPsec, HMAC [RFC 2104], is more
generally useful. If cryptographic authentication but not
secrecy is needed, and IPsec is not applicable, HMAC should be
used."
[LIPKEY] motivates for the use of HMAC-MD5 since it is faster than
both HMAC-SHA and MAC algorithms based on secret key encryption
algorithms. In addition, weaknesses found in MD5 do not impact
Burdis [Page 5]
draft-ietf-cat-srpgm-02.txt January 2000
HMAC-MD5 [DOBBERTIN]. See sections 2.3.1 and 5.3 of [LIPKEY].
The HMAC-MD5 algorithm MUST be used to calculate the message
authentication codes for the SrprgmRep and SrpgmEvidence tokens.
4.3 One-Way Functions
An iterative one-way hash function is used in the SRP protocol and 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.
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 26
}
The actual one-way function used over the context is specified by the
acceptor in the SrpgmRep token.
4.4 Confidentiality Algorithms
Confidentiality algorithms are used with the SrpgmWrap token to
encrypt message data. In the interests of interoperability support for
this algorithm is RECOMMENDED:
blowfishCBC OBJECT IDENTIFIER ::= {
-- object identifier registration in progress
}
Blowfish was chosen because [BLOWFISH]:
* It is free from intellectual property constraints
* It is fast
* It supports variable key lengths from 32 bits to 448 bits
* It has withstood cryptanalysis since 1993
* A number of implementations in various programming languages are
freely available
When the chosen AES algorithm is announced it will also be
recommended [AES].
4.5 Negotiation
Algorithm negotiation is the same as for SPKM (see section 2.5 of
[SPKM]), except that the parties also negotiate the use of a
one-way-function, and even with unilateral authentication both parties
are involved in the negotiation. The slightly modified negotiation
procedure is described below.
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.
Burdis [Page 6]
draft-ietf-cat-srpgm-02.txt January 2000
The confidentiality algorithms selected by the acceptor become the set
of confidentiality algorithms used over the established context and
the integrity algorithms selected by the acceptor become the set of
integrity algorithms used over the established context. The acceptor
selects algorithms by returning, in the same relative order, the
subset of each offered set that it supports. The acceptor also selects
a single one-way function out of the set of possible one-way functions
offered by the initiator.
Note that any confidentiality algorithm and integrity algorithm 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
selected one-way function is used in the SRP protocol and in the
derivation of context subkeys for the agreed upon integrity and
confidentiality algorithms.
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 6.2 for details.
4.6 Subkey Derivation
Subkey derivation is the same as for SPKM (see section 2.4 of [SPKM]).
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].
5 Tokens
As with SPKM all tokens emitted by this mechanism will be contained
in an InitialContextToken framing (see section 3.1 of [SPKM]).
Per RFC-1508, Appendix B, the initial context establishment token will
be enclosed within framing as follows:
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech OBJECT IDENTIFIER,
innerContextToken ANY DEFINED BY thisMech
}
thisMech
Object identifier for the mechanism type. In this case the object
identifier representing "SRPGM".
innerContextToken
Mechanism-specific data. In this case it contains an
SrpgmInnerContextToken
Burdis [Page 7]
draft-ietf-cat-srpgm-02.txt January 2000
When thisMech is SRPGM, innerContextToken is defined as follows:
SrpgmInnerContextToken ::= CHOICE {
request [0] SrpgmReq,
reply [1] SrpgmRep,
parameters [2] SrpgmParameters,
evidence [3] SrpgmEvidence,
error[4] SrpgmError,
mic[5] SrpgmMic,
wrap[6] SrpgmWrap,
del[7] SrpgmDel
}
All tokens are encoded using ASN.1 DER. (The merits of using the XER
encoding described in [XER] need to be discussed).
The full ASN.1 specification is given in Appendix B.
5.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() [SPKM].
As mentioned above all tokens must be framed in an
InitialContextToken. The innerContextToken field of context
establishment tokens will contain one of the following tokens:
SrpgmReq; SrpgmRep; SrpgmParameters; SrpgmEvidence; and SrpgmError.
5.1.1 SrpgmReq
SrpgmReq ::= SEQUENCE {
contents ReqContents,
checksum BIT STRING
}
contents
Contents of the token.
checksum
Integrity checksum.
The integrity checksum is computed by using the value of the contents
field in the SrpgmReq token as input to the SHA-1 one-way function.
ReqContents ::= SEQUENCE {
tokenId INTEGER(256),
contextId RandomInteger,
A BIT STRING,
Burdis [Page 8]
draft-ietf-cat-srpgm-02.txt January 2000
username OCTET STRING,
n INTEGER,
g INTEGER,
reqData ContextData,
validity Validity
}
tokenId
Used to identify the type of token. It must have the value 256
(decimal).
contextId
Used to identify to which context the token belongs. Here this is a
fresh random number generated by the initiator. See section 6.4 for
more information.
A
The ephemeral public key generated by the initiator.
username
The initiator's username.
n
A large prime number. All additions, multiplications, and
exponentiations are performed modulo n.
g
A generator in the finite field GF(n).
reqData
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.
ContextData ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seqNumber INTEGER OPTIONAL,
options Options,
intgAlgs AlgList,
owfAlgs AlgList,
confAlgs AlgList OPTIONAL
}
channelId
Used to provide channel binding as per section 1.1.6 of RFC 2078
[GSS-APIv2].
seqNumber
The initiator's four-byte initial sequence number. See section 6.5.
Burdis [Page 9]
draft-ietf-cat-srpgm-02.txt January 2000
options
The options requested by the initiator.
intgAlgs
The set of integrity algorithms supported by the initiator.
owfAlgs
The set of one-way function algorithms supported by the initiator.
confAlgs
The set of confidentiality algorithms supported by the initiator.
This is optional because confidentiality may not be available over
the context.
Note that the sets of algorithms MUST include those specified as
MANDATORY in section 4. (See section 4.5 for details on how the
algorithm negotiation process takes place). If this is not so then the
acceptor MUST generate an SrpgmError token. In addition, the sets of
algorithms SHOULD, if possible, include those specified as RECOMMENDED
in section 4.
ChannelId ::= OCTET STRING
AlgList ::= SEQUENCE OF AlgorithmIdentifier
Options ::= BIT STRING {
delegationState (0),
mutualState (1),
replayDetState (2),
sequenceState (3),
confState (4),
integState (5)
}
delegationState
whether or not delegation should be allowed if available
mutualState
whether or not mutual authentication is requested
replayDetState
whether or not replay detection should be performed
sequenceState
whether or not sequencing should be performed
confState
whether or not confidentiality protection should be provided, if
available
integState
whether or not integrity protection should be provided
We optimise for the case where the initiator and acceptor use
Burdis [Page 10]
draft-ietf-cat-srpgm-02.txt January 2000
prearranged values for n and g. If the values are prearranged then
they MUST meet the constraints described in [SRP-DRAFT] (see section
4.1 above). If the initiator does not know what values for n and g the
acceptor uses then it MAY set the values of the n and g fields in the
ReqContents structure of the SrpgmReq token to zero. The values of the
other fields MAY then be set to dummy values.
The acceptor MUST first check that the the values for n and g in the
received SrpgmReq token are correct, and if not MUST send an
SrpgmParameters token to the initiator that contains the correct
values. (It is RECOMMENDED that the initiator cache the values for n
and g used by the acceptor to avoid this extra message exchange in
future).
If n and g are correct, the acceptor MUST also check that the value of
A in the received SrpgmReq token is not zero, and generate an
SrpgmError token if it is.
5.1.2 SrpgmParameters
SrpgmParameters ::= SEQUENCE {
tokenId INTEGER(257),
contextId RandomInteger,
n INTEGER,
g INTEGER,
}
tokenId
Used to identify the type of token. It must have the value 257
(decimal).
contextId
Used to identify to which context the token belongs. Here this is
the value that was contained in the contextId field of the
ReqContents structure in the received SrpgmReq token.
n
The large prime number used by the acceptor. All additions,
multiplications, and exponentiations are performed modulo n.
g
A generator in the finite field GF(n).
If the initiator receives an SrpgmParameters token it MUST ensure that
the values for n and g meet the constraints described in [SRP-DRAFT]
(see section 4.1 above), and abort the context if they do not. If the
values are valid then the initiator MUST generate a new SrpgmReq token
with data computed using the given values for n and g.
5.1.3 SrpgmRep
SrpgmRep ::= SEQUENCE {
contents RepContents,
mac BIT STRING
Burdis [Page 11]
draft-ietf-cat-srpgm-02.txt January 2000
}
contents
Contents of the token.
mac
Keyed checksum of contents.
The contents of the RepContents structure are integrity protected by
computing a checksum of the encoded contents of this structure using
the HMAC-MD5 algorithm and the shared context key. This keyed checksum
is stored in the mac field of the SrpgmRep token.
Note that the initiator needs to obtain data from the RepContents
structure of the received SrpgmRep token before it has sufficient
information to derive the session key and verify the integrity
checksum.
The lack of integrity protection of the SrpgmReq token is the reason
why the HMAC-MD5 algorithm (the mandatory integrity algorithm) MUST be
used to compute the integrity checksum for the SrpgmRep token. The set
of integrity algorithms specified in the SrpgmReq token can not be
trusted, because this set of algorithms may have been modified by an
attacker.
RepContents ::= SEQUENCE {
tokenId INTEGER(512),
contextId RandomInteger,
reqChecksum BIT STRING,
repData ContextData,
validity Validity OPTIONAL,
salt BIT STRING,
B BIT STRING,
n INTEGER,
g INTEGER
}
tokenId
Used to identify the type of token. It must have the value 512
(decimal).
contextId
Used to identify to which context the token belongs. See section
6.4 for details on how it is calculated.
reqChecksum
The checksum from the SrpgmReq token.
repData
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
Burdis [Page 12]
draft-ietf-cat-srpgm-02.txt January 2000
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.
B
The ephemeral public key generated by the acceptor.
n
A large prime number. All additions, multiplications, and
exponentiations are performed modulo n.
g
A generator in the finite field GF(n).
The reqChecksum field contains the value found in the checksum field
of the received SrpgmReq token. The initiator MUST verify this
checksum upon receipt of the SrpgmRep token, and abort the context if
it does not match. This is necessary to avoid an attacker modifiying
the contents of the SrpgmReq token, perhaps in order to have the
weakest possible algorithms negotiated for the context.
The initiator MUST also:
* check that the values for n and g in the received SrpgmRep token
are the same as those used in its calculations to produce the
SrpgmReq token, and abort the context if they are not.
* check that the value of B in the received SrpgmRep token is not
zero, and generate an SrpgmError token if it is.
ContextData ::= SEQUENCE {
channelId ChannelId OPTIONAL,
seqNumber INTEGER OPTIONAL,
options Options,
intgAlgs AlgList,
owfAlgs AlgList,
confAlgs AlgList OPTIONAL
}
channelId
Used to provide channel binding as per section 1.1.6 of RFC 2078
[GSS-APIv2].
seqNumber
The acceptor's four-byte initial sequence number. See section 6.5.
options
The options requested by the initiator that acceptor is prepared to
honour.
intgAlgs
Burdis [Page 13]
draft-ietf-cat-srpgm-02.txt January 2000
The set of integrity algorithms selected by the acceptor.
owfAlgs
The one-way function algorithm selected by the acceptor.
confAlgs
The set of confidentiality algorithms selected by the acceptor, if
any.
Note that the algorithms selected by the acceptor MUST be selected out
of the sets of algorithms proposed by the initiator. (See section 4.5
for details on how the algorithm negotiation process takes place). If
this is not so then the initiator MUST generate an SrpgmError token.
5.1.4 SrpgmEvidence
SrpgmEvidence ::= SEQUENCE {
contents EvidenceToken,
mac BIT STRING
}
contents
Contents of the token.
mac
Keyed checksum of contents.
EvidenceToken ::= SEQUENCE {
tokenId INTEGER(768),
contextId RandomInteger,
evidence BIT STRING
}
tokenId
Used to identify the type of token. It must have the value 768
(decimal).
contextId
Used to identify to which context the token belongs. See section
6.4.
evidence
Proof that the sender knows the shared context key.
The contents of the EvidenceToken are integrity protected by computing
a checksum of the encoded contents of this structure using the
HMAC-MD5 algorithm and the shared context key. This keyed checksum is
stored in the mac field of the SrpgmEvidence token.
The receiver of this token MUST verify that the evidence supplied is
correct and abort the context if it is not.
Burdis [Page 14]
draft-ietf-cat-srpgm-02.txt January 2000
5.1.5 SrpgmError
Error tokens are used to signal errors that occur during the context
establishment process.
SrpgmError ::= SEQUENCE {
tokId INTEGER(1024),
contextId RandomInteger
}
tokId
Used to identify the type of token. It must have the value 1024
(decimal).
contextId
Used to identify to which context the token belongs. See section
6.4.
The SrpgmError token is only used during the context establishment
process. If either the initiator or the acceptor receives such a token
after the context establishment process is complete it MUST be
discarded and ignored.
If the initiator receives an SrpgmError token during context
establishment it MUST regenerate a SrpgmReq token, and if the acceptor
receives an SrpgmError token during context establishment it MUST
regenerate a SrpgmRep token.
Occasions when an SrpgmError token may be generated are specified
above.
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.2 Per-Message and Context Deletion Tokens
SRPGM uses exactly the same per-message and context deletion tokens as
SPKM. Refer to section 3.2 of [SPKM]. As mentioned above all tokens
must be framed in an InitialContextToken. The innerContextToken field
of per-message tokens will contain one of the following tokens:
SrpgmMic; SrpgmWrap; and SrpgmDel.
Note that in the ASN.1 specification for SRPGM (see appendix B) some
of the definitions with SPKM-specific names have been renamed.
6 Miscellaneous Details
6.1 Minor Status Codes
Minor status codes are used as per section 5.1 of [SPKM].
GSS-Related and Implementation-Related codes are the same.
SPKM-specific codes should be replaced with:
Burdis [Page 15]
draft-ietf-cat-srpgm-02.txt January 2000
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_BAD_OWF_ALG_TYPE
/* "Unknown one-way function 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" */
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" */
6.2 Quality of Protection
Quality of Protection (QOP) values, which are used to select amongst
negotiated algorithms, are constructed and used as per section 5.2 of
[SPKM].
However, in accordance with the MANDATORY and RECOMMENDED algorithms
Burdis [Page 16]
draft-ietf-cat-srpgm-02.txt January 2000
given in Section 4, the following QOP values are specified for SRPGM:
For the Confidentiality MA field:
0001 (1) = blowfishCBC
For the Integrity MA field:
0001 (1) = HMAC-MD5
6.3 Support Functions
SRPGM implementations MUST provide the SPKM_Parse_token function
(appropriately renamed) described in sections 6.1 and 6.2 of [SPKM].
6.4 Context-ids
All tokens have a context-id which is used to map the token to an
associated context handle. A description of their use and construction
is given in section 6.3 of [SPKM].
6.5 Sequence numbers
Sequence numbers are used to avoid malicious loss, replay or
reordering of tokens after context establishment. They are used and
processed as discussed in sections 3.2.1.2 and 3.2.1.3 of [SPKM].
7 Security Considerations
Security issues are discussed throughout this document.
This mechanism relies on the security of SRP, which bases its security
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.
The recommended Blowfish cipher has undergone cryptanalysis for a long
period of time and no weaknesses have been found [Blowfish].
References
[AES] WWW, "Advanced Encryption Standard (AES) Development
Effort", URL: http://www.nist.gov/aes
[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
[BLOWFISH] Schneier, Bruce, "The Blowfish Encryption Algorithm",
Burdis [Page 17]
draft-ietf-cat-srpgm-02.txt January 2000
URL: http://www.counterpane.com/blowfish.html
[CAT-WG] WWW, "Common Authentication Technology (cat) Charter",
URL: http://www.ietf.org/html.charters/cat-charter.html
[DOBBERTIN] Dobbertin, Hans, "The Status of MD5 After a Recent
Attack", CryptoBytes, RSA Laboratories, URL:
ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[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
[LIPKEY] Eisler, Mike, "LIPKEY - A Low Infrastructure Public Key
Mechanism Using SPKM", Internet Draft, draft-ietf-cat-lipkey-02.txt
[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-WWW] WWW, "SRP: The Open Source Password Authentication
Standard", http://srp.stanford.edu/srp/
[XER] Sue, Hoylen, "XER - A Bridge between ASN.1 and XML", URL:
http://www.dstc.edu.au/Research/Projects/xer/xer-2.html
Author's Address
Keith Burdis
Computer Science Department
Rhodes University
6139 Grahamstown
South Africa
Address comments related to this submission to:
cat-ietf@mit.edu
Burdis [Page 18]
draft-ietf-cat-srpgm-02.txt January 2000
Appendix A: Modulus and Generator values
Modulus (n) and generator (g) values for various modulus lengths are
given below. In each case the modulus is a large safe prime and the
generator is a primitve root of GF(n) [SRP]. These values are taken
from software developed by Tom Wu and Eugene Jhong for the Stanford
SRP distribution [SRP-WWW]. The modulus values are base64 encoded.
[264 bits]
Modulus =
HMujfBWu4LfBFA0j3PpN7UbgUYfv.rMoMNuVRMoekpZ
Generator = 2
[384 bits]
Modulus =
W2KsCfRxb3/ELBvnVWufMA0gbdBlLXbJihgZkgp3xLTKwtPCUhSOHNZ5VLb9pBGR
Generator = 2
[512 bits]
Modulus =
3Kn/YYiomHkFkfM1x4kayR125MGkzpLUDy3y14FlTMwYnhZkjrMXnoC2TcFAecNl
U5kFzgcpKYUbBOPZFRtyf3
Generator = 2
[640 bits]
Modulus =
CbDP.jR6YD6wAj2ByQWxQxQZ7.9J9xkn2.Uqb3zVm16vQyizprhBw9hi80psatZ8
k54vwZfiIeEHZVsDnyqeWSSIpWso.wh5GD4OFgdhVI3
Generator = 2
[768 bits]
Modulus =
iqJ7nFZ4bGCRjE1F.FXEwL085Zb0kLM2TdHDaVVCdq0cKxvnH/0FLskJTKlDtt6s
Dl89dc//aEULTVFGtcbA/tDzc.bnFE.DWthQOu2n2JwKjgKfgCR2lZFWXdnWmoOh
Generator = 2
[1024 bits]
Modulus =
Ewl2hcjiutMd3Fu2lgFnUXWSc67TVyy2vwYCKoS9MLsrdJVT9RgWTCuEqWJrfB6u
E3LsE9GkOlaZabS7M29sj5TnzUqOLJMjiwEzArfiLr9WbMRANlF68N5AVLcPWvNx
6Zjl3m5Scp0BzJBz9TkgfhzKJZ.WtP3Mv/67I/0wmRZ
Generator = 2
[1280 bits]
Modulus =
3NUKQ2Re4P5BEK0TLg2dX3gETNNNECPoe92h4OVMaDn3Xo/0QdjgG/EvM.hiVV1B
dIGklSI14HA38Mpe5k04juR5/EXMU0r1WtsLhNXwKBlf2zEfoOh0zVmDvqInpU69
5f29Iy7sNW3U5RIogcs740oUp2Kdv5wuITwnIx84cnO.e467/IV1lPnvMCr0pd1d
gS0a.RV5eBJr03Q65Xy61R
Generator = 2
[1536 bits]
Modulus =
dUyyhxav9tgnyIg65wHxkzkb7VIPh4o0lkwfOKiPp4rVJrzLRYVBtb76gKlaO7ef
Burdis [Page 19]
draft-ietf-cat-srpgm-02.txt January 2000
5LYGEw3G.4E0jbMxcYBetDy2YdpiP/3GWJInoBbvYHIRO9uBuxgsFKTKWu7RnR7y
Tau/IrFTdQ4LY/q.AvoCzMxV0PKvD9Odso/LFIItn8PbTov3VMn/ZEH2SqhtpBUk
WtmcIkEflhX/YY/fkBKfBbe27/zUaKUUZEUYZ2H2nlCL60.JIPeZJSzsu/xHDVcx
Generator = 2
[2048 bits]
Modulus =
2iQzj1CagQc/5ctbuJYLWlhtAsPHc7xWVyCPAKFRLWKADpASkqe9djWPFWTNTdeJ
tL8nAhImCn3Sr/IAdQ1FrGw0WvQUstPx3FO9KNcXOwisOQ1VlL.gheAHYfbYyBax
XL.NcJx9TUwgWDT0hRzFzqSrdGGTN3FgSTA1v4QnHtEygNj3eZ.u0MThqWUaDiP8
7nqha7XnT66bkTCkQ8.7T8L4KZjIImrNrUftedTTBi.WCi.zlrBxDuOM0da0JbUk
QlXqvp0yvJAPpC11nxmmZOAbQOywZGmu9nhZNuwTlxjfIro0FOdthaDTuZRL9VL7
MRPUDo/DQEyW.d4H.UIlzp
Generator = 2
Appendix B: ASN.1 Definitions
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech OBJECT IDENTIFIER,
innerContextToken ANY DEFINED BY thisMech
}
SrpgmInnerContextToken ::= CHOICE {
request [0] SrpgmReq,
reply [1] SrpgmRep,
parameters [2] SrpgmParameters,
evidence [3] SrpgmEvidence,
error[4] SrpgmError,
mic[5] SrpgmMic,
wrap[6] SrpgmWrap,
del[7] SrpgmDel
}
SrpgmReq ::= SEQUENCE {
contents ReqContents,
checksum BIT STRING
}
ReqContents ::= SEQUENCE {
tokenId INTEGER(256),
contextId RandomInteger,
A BIT STRING,
username OCTET STRING,
n INTEGER,
g INTEGER,
reqData ContextData,
validity Validity
}
ContextData ::= SEQUENCE {
channelId ChannelId OPTIONAL,
Burdis [Page 20]
draft-ietf-cat-srpgm-02.txt January 2000
seqNumber INTEGER OPTIONAL,
options Options,
intgAlgs AlgList,
owfAlgs AlgList,
confAlgs AlgList OPTIONAL
}
ChannelId ::= OCTET STRING
AlgList ::= SEQUENCE OF AlgorithmIdentifier
Options ::= BIT STRING {
delegationState (0),
mutualState (1),
replayDetState (2),
sequenceState (3),
confState (4),
integState (5)
}
SrpgmParameters ::= SEQUENCE {
tokenId INTEGER(257),
contextId RandomInteger,
n INTEGER,
g INTEGER,
}
SrpgmRep ::= SEQUENCE {
contents RepContents,
mac BIT STRING
}
RepContents ::= SEQUENCE {
tokenId INTEGER(512),
contextId RandomInteger,
reqChecksum BIT STRING,
repData ContextData,
validity Validity OPTIONAL,
salt BIT STRING,
B BIT STRING,
n INTEGER,
g INTEGER
}
SrpgmEvidence ::= SEQUENCE {
evidence EvidenceToken,
mac BIT STRING
}
EvidenceToken ::= SEQUENCE {
tokenId INTEGER(768),
contextId RandomInteger,
evidence BIT STRING
}
Burdis [Page 21]
draft-ietf-cat-srpgm-02.txt January 2000
SrpgmError ::= SEQUENCE {
tokId INTEGER(1024),
contextId RandomInteger
}
SrpgmMic ::= SEQUENCE {
micHeader MicHeader,
intCksum BIT STRING
}
MicHeader ::= SEQUENCE {
tokId INTEGER(257),
contextId RandomInteger,
intAlg [0] AlgorithmIdentifier OPTIONAL,
sndSeq [1] SeqNum OPTIONAL
}
SeqNum ::= SEQUENCE {
num INTEGER,
dirInd BOOLEAN
}
SrpgmWrap ::= SEQUENCE {
wrapHeader WrapHeader,
wrapBody WrapBody
}
WrapHeader ::= SEQUENCE {
tokId INTEGER(513),
contextId RandomInteger,
intAlg [0] AlgorithmIdentifier OPTIONAL,
confAlg [1] AlgorithmIdentifier OPTIONAL,
sndSeq [2] SeqNum OPTIONAL
}
WrapBody ::= SEQUENCE {
intCksum BIT STRING,
data BIT STRING
}
SrpgmDel ::= SEQUENCE {
delHeader DelHeader,
intCksum BIT STRING
}
DelHeader ::= SEQUENCE {
tokId INTEGER(769),
contextId RandomInteger,
intAlg[0] AlgorithmIdentifier OPTIONAL,
sndSeq [1] SeqNum OPTIONAL
}
RandomInteger ::= BIT STRING
Burdis [Page 22]
draft-ietf-cat-srpgm-02.txt January 2000
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
paramter ANY DEFINED BY algorithm OPTIONAL
}
END
Burdis [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 10:34:48 |