One document matched: draft-ietf-cat-srpgm-01.txt
Differences from draft-ietf-cat-srpgm-00.txt
CAT Working Group K.R. Burdis
Internet Draft Rhodes University
Expires: June 2000 December 1999
draft-ietf-cat-srpgm-01.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 copied verbatim.
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-01.txt December 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."
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
Burdis [Page 2]
draft-ietf-cat-srpgm-01.txt December 1999
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 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 mallicious loss, replay or
reordering of tokens, as well as to remove the need for secure
timestamps
* 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
Burdis [Page 3]
draft-ietf-cat-srpgm-01.txt December 1999
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:
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.
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
Burdis [Page 4]
draft-ietf-cat-srpgm-01.txt December 1999
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
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 code for the SrpgmEvidence token.
4.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 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
Burdis [Page 5]
draft-ietf-cat-srpgm-01.txt December 1999
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.
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 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
Burdis [Page 6]
draft-ietf-cat-srpgm-01.txt December 1999
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
When thisMech is SRPGM, innerContextToken is defined as follows:
SrpgmInnerContextToken ::= CHOICE {
request [0] SrpgmReq,
reply [1] SrpgmRep,
evidence [2] SrpgmEvidence,
error[3] SrpgmError,
mic[4] SrpgmMic,
wrap[5] SrpgmWrap,
del[6] SrpgmDel
}
All tokens are encoded using ASN.1 DER. (The merits of using the XER
encoding described in [XER] need to be discussed).
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;
SrpgmEvidence; and SrpgmError.
5.1.1 SrpgmReq
SrpgmReq ::= SEQUENCE {
tokenId INTEGER(256),
contextId RandomInteger,
publicKeyA BIT STRING,
username OCTET STRING,
reqData ContextData,
validity Validity
}
tokenId
Used to identify the type of token. It must have the value 256
(decimal).
contextId
Burdis [Page 7]
draft-ietf-cat-srpgm-01.txt December 1999
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.
publicKeyA
The ephemeral public key generated by the initiator.
username
The initiator's username.
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.
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.
ChannelId ::= OCTET STRING
Burdis [Page 8]
draft-ietf-cat-srpgm-01.txt December 1999
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
5.1.2 SrpgmRep
SrpgmRep ::= SEQUENCE {
tokenId INTEGER(512),
contextId RandomInteger,
repData ContextData,
validity Validity OPTIONAL,
salt BIT STRING,
publicKeyB 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.
repData
Specifies the algorithms that the acceptor supports out of the
lists that the initiator provided, and the options that the acceptor
Burdis [Page 9]
draft-ietf-cat-srpgm-01.txt December 1999
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.
publicKeyB
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).
Note, that if the values for n and g in the SrpgmRep token are
different from the ones that the initiator used in its calculations
for the SrpgmReq token, then the initiator MUST send a new SrpgmReq
token with data computed using the new values for n and g.
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
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.
Burdis [Page 10]
draft-ietf-cat-srpgm-01.txt December 1999
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.
5.1.3 SrpgmEvidence
SrpgmEvidence ::= SEQUENCE {
evidence EvidenceToken,
evidenceIntg BIT STRING
}
evidence
evidence that the sender knows the shared context key.
evidenceIntg
The integrity checksum.
EvidenceToken ::= SEQUENCE {
tokenId INTEGER(768),
contextId RandomInteger,
seqnumInitiator INTEGER,
seqnumAcceptor INTEGER,
contextData ContextData,
validity Validity,
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.
seqnumInitiator
The initiator's four-byte initial sequence number. See section 6.5.
seqnumAcceptor
The acceptor's four-byte initial sequence number. See section 6.5.
contextData
The agreed upon context settings and algorithm lists.
validity
The agreed upon context lifetime.
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 token using the HMAC-MD5
algorithm and the shared context key. The checksum is stored in the
evidenceIntg field of the SrpgmEvidence token.
Burdis [Page 11]
draft-ietf-cat-srpgm-01.txt December 1999
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 EvidenceToken, 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 SrpgmDel
token if they are not.
The lack of integrity protection of the SrpgmReq and SrpgmRep tokens
is the reason why the HMAC-MD5 algorithm (the mandatory integrity
algorithm) MUST be used to compute the checksum on the SrpgmEvidence
token. The set of negotiated integrity algorithms can not be trusted
before the SrpgmEvidence token is generated, because this set of
algorithms may have been modified by an attacker.
5.1.4 Error Token
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 an SrpgmReq or SrpgmRep token is received in error, the
receiving function (either gss_init_sec_context() or
gss_accept_sec_context()) will generate an SrpgmError token to be
sent to the peer (if the peer is still in the context establishment
process) and will return GSS_S_CONTINUE_NEEDED. If, on the other hand,
no context establishment response is expected from the peer (i.e., the
peer has completed context establishment), the function will return
the appropriate major status code (e.g., GSS_S_BAD_SIG) along with a
minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all
context-relevant information will be deleted. The output token will
not be an SrpgmError token but will instead be an SrpgmDel 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 SrpgmReq 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 SrpgmReq token when it is
expecting an SrpgmEvidence token, it will discard the data from the
Burdis [Page 12]
draft-ietf-cat-srpgm-01.txt December 1999
previous SrpgmReq 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 SrpgmRep 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.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 for SRPGM 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:
6.1.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" */
Burdis [Page 13]
draft-ietf-cat-srpgm-01.txt December 1999
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 to prove knowledge of context key and
settings." */
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
given in Section 3, 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 mallicious loss, replay or
reordering of tokens, as well as to remove the need for secure
Burdis [Page 14]
draft-ietf-cat-srpgm-01.txt December 1999
timestamps. 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.
8 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",
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
Burdis [Page 15]
draft-ietf-cat-srpgm-01.txt December 1999
[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
[XER] Sue, Hoylen, "XER - A Bridge between ASN.1 and XML", URL:
http://www.dstc.edu.au/Research/Projects/xer/xer-2.html
9 Author's Address
Keith Burdis
Computer Science Department
Rhodes University
6139 Grahamstown
South Africa
Email: cskb@cs.ru.ac.za
Appendix A: 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,
evidence [2] SrpgmEvidence,
error[3] SrpgmError,
mic[4] SrpgmMic,
wrap[5] SrpgmWrap,
del[6] SrpgmDel
}
SrpgmReq ::= SEQUENCE {
tokenId INTEGER(256),
contextId RandomInteger,
publicKeyA BIT STRING,
username OCTET STRING,
reqData ContextData,
validity Validity
}
Burdis [Page 16]
draft-ietf-cat-srpgm-01.txt December 1999
ContextData ::= SEQUENCE {
channelId ChannelId OPTIONAL,
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)
}
SrpgmRep ::= SEQUENCE {
tokenId INTEGER(512),
contextId RandomInteger,
repData ContextData,
validity Validity OPTIONAL,
salt BIT STRING,
publicKeyB BIT STRING,
n INTEGER,
g INTEGER
}
SrpgmEvidence ::= SEQUENCE {
evidence EvidenceToken,
evidenceIntg BIT STRING
}
EvidenceToken ::= SEQUENCE {
tokenId INTEGER(768),
contextId RandomInteger,
seqnumInitiator INTEGER,
seqnumAcceptor INTEGER,
contextData ContextData,
validity Validity,
evidence BIT STRING
}
SrpgmError ::= SEQUENCE {
tokId INTEGER(1024),
contextId RandomInteger
}
SrpgmMic ::= SEQUENCE {
Burdis [Page 17]
draft-ietf-cat-srpgm-01.txt December 1999
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
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
AlgorithmIdentifier ::= SEQUENCE {
Burdis [Page 18]
draft-ietf-cat-srpgm-01.txt December 1999
algorithm OBJECT IDENTIFIER,
paramter ANY DEFINED BY algorithm OPTIONAL
}
END
Burdis [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 10:30:49 |