One document matched: draft-ietf-cat-fipsjjjgss-00.txt
Network Working Group S. Murphy
INTERNET-DRAFT D. Balenson
IETF Common Authentication Technology WG J. Galvin
<draft-ietf-cat-fipsjjjgss-00.txt> TIS
July 1995
The FIPS PUB JJJ Entity Authentication GSS-API Mechanism
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are 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''.
To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This specification defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service Application
Program Interface, as specified in RFCs 1508 and 1509 [2] [3], (and as
amended by the Internet Draft defining GSS-API Version 2 [4]) when using
the FIPS PUB JJJ class of authentication mechanisms (as defined in FIPS
PUB JJJ [1]).
1. Acknowledgements
Some of the material in this document, particularly Sections 2 and 5, is
based on the Simple Public-Key GSS-API Mechanism (SPKM) specification
[5]. The authors of this document thank Warwick Ford, Paul Van Oorschot,
and Carlisle Adams of Bell-Northern Research, John Linn and Marc
Horowitz of OpenVision Technologies, and Joan Marshall for many fruitful
Murphy/Balenson/Galvin Expires: January 1996 [Page 1]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
discussions.
2. Introduction
FIPS PUB JJJ, recently proposed as a Federal Information Processing
Standard (FIPS) [8], defines a class of mechanisms employing digital
signatures to provide either unilateral and mutual authentication using
public key cryptography. It is based primarily on a subset of ISO
Standard 9798 [6].
The goal of the Generic Security Service Application Program Interface
(GSS-API) is stated in the abstract of RFC 1508 [2] as follows:
"This Generic Security Service Application Program Interface (GSS-
API) definition provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments. This specification defines
GSS-API services and primitives at a level independent of
underlying mechanism and programming language environment, and is
to be complemented by other, related specifications:
- documents defining specific parameter bindings for particular
language environments;
- documents defining token formats, protocols, and procedures to
be implemented in order to realize GSS-API services atop
particular security mechanisms."
Each mechanism in the FIPS PUB JJJ class of authentication mechanisms is
an instance of the latter type of document and is therefore termed a
"GSS-API Mechanism". If a FIPS PUB JJJ class mechanism conforms to the
interface defined by RFC 1508 [2], it can be used as a drop-in
replacement by any application which makes use of security services
through GSS-API calls (for example, any application which already uses
the Kerberos GSS-API for security).
The tokens defined in this document are intended to be used by
application programs according to the GSS API "operational paradigm"
(see RFC 1508 [2] for further details):
The operational paradigm in which GSS-API operates is as follows.
A typical GSS-API caller is itself a communications protocol [or
is an application program which uses a communications protocol],
calling on GSS-API in order to protect its communications with
authentication, integrity, and/or confidentiality security
services. A GSS-API caller accepts tokens provided to it by its
local GSS-API implementation [i.e., its GSS-API mechanism] and
transfers the tokens to a peer on a remote system; that peer
Murphy/Balenson/Galvin Expires: January 1996 [Page 2]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
passes the received tokens to its local GSS-API implementation for
processing.
3. Related Work
FIPS PUB JJJ defines unilateral and mutual authentication mechanisms
based on ISO Standard 9798. There is an IETF effort presently ongoing
called Simple Public Key Mechanism [5] that defines unilateral and
mutual authentication mechanisms based on CCITT Standard X.509 [7]. The
two standards are extremely close in intent and technique. SPKM
includes more than just authentication; it also includes provisions for
confidentiality and integrity protection of the messages transmitted
through the established context. FIPS PUB JJJ provides authentication,
but no protection of the resultant context. The possibility that FIPS
PUB JJJ and the SPKM work could be combined should be pursued.
4. GSS-API Interface Calls
As FIPS PUB JJJ deals only with authentication, we define the
implementation of only the GSS-API context establishment calls for a
FIPS PUB JJJ class mechanism. We presume that some other negotiation,
either out of band, by the calling protocol, or by some as yet undefined
GSS-API negotiation mechanism, has determined that a FIPS PUB JJJ
mechanism will be used, or that a FIPS PUB JJJ mechanism is the local
default for the initiator and target.
4.1. GSS_Init_sec_context call
FIPS PUB JJJ defines authentication mechanisms for both unilateral and
mutual authentication. Unilateral authentication authenticates the
initiator to the target. There may be mechanisms that can support only
unilateral authentication or support only mutual authentication or that
can support both. As there is no reason to believe that any one
mechanism in the FIPS PUB JJJ class can do both types of authentication,
one duty of the GSS-API interface calls will be to negotiate the use of
mutual or unilateral authentication.
As FIPS PUB JJJ defines a class of authentication mechanisms, it is
possible that the initiator's and target's individual mechanisms may
have different sets of digital signature algorithms available. A
negotiation for algorithm type will proceed concurrently with the
negotiation of use of unilateral or mutual authentication.
Murphy/Balenson/Galvin Expires: January 1996 [Page 3]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
4.1.1. First call to GSS_Init_sec_context
On the initial call to GSS_Init_sec_context, the initiator creates a
FIPS_SETUP token containing the set of representations for the digital
signature algorithms available locally, as well as flags indicating
whether mutual and/or unilateral authentication is available and whether
mutual or unilateral authentication is requested in the
GSS_Init_sec_context call. The services, i.e., delegation, sequencing,
etc., requested in the GSS_Init_sec_context call may optionally be
included in the token. (Different FIPS PUB JJJ class mechanisms may
have some or all of these services available; the negotiation for those
services is not specified here.) GSS_S_CONTINUE_NEEDED is returned as
the major_status code and FIPS_SETUP is returned as output_token. The
mech_type on entry must be FIPS_PUB_JJJ or null, and the returned value
must be FIPS_PUB_JJJ.
4.1.2. Second call to GSS_Init_sec_context
A second call to GSS_Init_sec_context must pass an input_token that is
either FIPS_ERROR, indicating an error, or FIPS_CHALN, containing the
final negotiated type of authentication, a subset of the initially
offered digital signature algorithm set indicating the algorithms
acceptable to the target and the FIPS PUB JJJ challenge from the target.
If the input_token is FIPS_ERROR, the major_status return code must be
GSS_S_FAILURE, with a minor_status code chosen to represent the error
indicated in the FIPS_ERROR token. No context is established.
If the input_token is FIPS_CHALN, then the initiator must pick one of
the set of digital signature algorithms indicated in the alg_subset
field to be used for the remainder of the authentication. The algorithm
choice is included in the output_token.
If unilateral authentication is indicated in the FIPS_CHALN, the
initiator must form a response to the challenge according to FIPS PUB
JJJ using the chosen digital signature algorithm and include the
response in the output_token. The output_token will be FIPS_REP_IT, the
major_status returned will be GSS_S_COMPLETE and a context should be
established. The values returned for deleg_state, mutual_state,
replay_det_state, sequence_state, and anon_state must take their values
from the FIPS_CHALN options field, if present.
If mutual authentication is indicated in the FIPS_CHALN, the initiator
must form a response to the challenge (using the chosen digital
signature algorithm) and a new challenge both according to FIPS PUB JJJ
Murphy/Balenson/Galvin Expires: January 1996 [Page 4]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
and include the response and new challenge in the output_token. The
output_token will be FIPS_REPCHALN_IT and the major_status returned will
be GSS_S_CONTINUE_NEEDED.
4.1.3. Third call to GSS_Init_sec_context
A third call to GSS_Init_sec_context, necessary only if mutual
authentication is agreed upon, will pass an input_token that is either
FIPS_ERROR, indicating an error, or FIPS_REP_TI, containing the target's
response to the challenge from the initiator found in FIPS_REPCHALN_IT.
If the input_token is FIPS_ERROR, the major_status return code must be
GSS_S_FAILURE, as discussed above.
If the input_token is FIPS_REP_TI and the response to the challenge
fails verification, then the major_status returned should be either
GSS_S_BAD_SIG or GSS_S_FAILURE with an appropriate minor_status code, at
the implementor's option. Note that it is the decision and
responsibility of the caller to inform the other end of the connection
that authentication has failed.
If the input_token is FIPS_REP_TI and the response to the challenge is
verified, then the major_status returned must be GSS_S_COMPLETE and the
context should be established. The values returned for deleg_state,
mutual_state, replay_det_state, sequence_state, and anon_state must take
their values from the FIPS_REP_TI options field, if present.
The second and third calls to GSS_Init_sec_context can be distinguished
from the first by the fact that the input_token and input_context_handle
must be null in the first call and not null in the subsequent calls.
The second and third calls to GSS_Init_sec_context can be distinguished
by the token_ID's in the input_token, except in the case that the
input_token is FIPS_ERROR. FIPS_ERROR is a permissible parameter for
both the second and the third GSS_Init_sec_context calls. As the
processing in both cases is the same, this should not be a problem.
4.2. GSS_Accept_sec_context call
The GSS_Accept_sec_context call will always be called twice, whether
unilateral or mutual authentication is used in the context
establishment.
Murphy/Balenson/Galvin Expires: January 1996 [Page 5]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
4.2.1. First call to GSS_Accept_sec_context
The call to GSS_Accept_sec_context will pass an input_token. If this is
the first call to GSS_Accept_sec_context, the token must be FIPS_SETUP.
The token contains the availability of unilateral and mutual
authentication at the initiator, as well as the caller's request for
unilateral or mutual authentication, and an indication of the set of
digital signature algorithms the initiator has available.
The target constructs the subset of the offered set of digital signature
algorithms that it has available. If this subset is empty, then the
initiator and target have no common digital signature algorithms. The
target must return a GSS_S_FAILURE major_status code and a FIPS_ERROR
token containing the error code 0001. No context will be established.
If this subset is not empty, then the subset must be included in the
alg_subset field of the FIPS_CHALN token.
If the initiator can do only unilateral authentication and the target
can do only mutual authentication or vice versa, then no context can be
established. The token returned will be FIPS_ERROR, with an error code
of 0002 and a major_status of GSS_S_FAILURE. If the initiator and
target can both do unilateral or both do mutual authentication, but not
both do both, then the common type must be specified in the returned
FIPS_CHALN token by setting the value of the mutual_tobeused field to
true (for mutual) or false (for unilateral). If both initiator and
target can both do both types of authentication, then the value of the
mutual_tobeused field in the returned FIPS_CHALN token must be set to
the value of the mutual_req field in the FIPS_SETUP token. In other
words, if the initiator and target can both do both types of
authentication, then the initiator's caller's request determines the
type.
If no error was determined, then a challenge must be formed (using the
chosen digital signature algorithm) according to FIPS PUB JJJ and
included in the output_token. The first call to GSS_Accept_sec_context
must return with a GSS_S_CONTINUE_NEEDED major_status code and
FIPS_CHALN as the output_token.
4.2.2. Second call to GSS_Accept_sec_context
The second call to GSS_Accept_sec_context can be distinguished by a
non-null input_context_handle and by the token_ID in the input_token.
The second call should pass an input_token containing either FIPS_ERROR
or a response token. If the authentication type was determined on the
first call to be unilateral authentication, then the response token must
Murphy/Balenson/Galvin Expires: January 1996 [Page 6]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
be FIPS_REP_IT; if it was mutual, then the response token must be
FIPS_REPCHALN_IT.
The response token contains the response to the target's challenge. The
response must be verified according to FIPS PUB JJJ. If the
verification fails and mutual authentication was chosen, then a
FIPS_ERROR token must be formed with an error code of 0003. The
major_status returned should be either GSS_S_BAD_SIG or GSS_S_FAILURE
with an appropriate minor_status code, at the implementor's option.
Note that if unilateral authentication is chosen, receipt of a
FIPS_REP_IT token means that the other side of the connection has
completed context establishment. Therefore, it is the decision and
responsibility of the caller to inform the other side of the connection
that authentication has failed.
If the response to the challenge is verified, then the major_status
returned must be GSS_S_COMPLETE and the context must be established. If
the type of authentication is mutual, then the input_token was
FIPS_REPCHALN_IT and contains a challenge. A response to this challenge
must be formed according to FIPS PUB JJJ and included in a FIPS_REP_TI
output_token. In either case, the values returned for deleg_state,
mutual_state, replay_det_state, sequence_state, and anon_state must take
their values from the input_token, if present.
5. 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() and GSS_Accept_sec_context(), and potentially
consumed by calls to GSS_Init_sec_context() and
GSS_Accept_sec_context(). The "Initiator" tokens are FIPS_SETUP,
FIPS_REP_IT, and FIPS_REPCHALN_IT. The "Target" tokens are FIPS_CHALN
and FIPS_REP_TI. The "Error" token is FIPS_ERROR.
Per RFC-1508, Appendix B, the initial context establishment token will
be enclosed within framing as follows:
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "FIPS PUB JJJ"
innerContextToken ANY DEFINED BY thisMech
Murphy/Balenson/Galvin Expires: January 1996 [Page 7]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
-- contents mechanism-specific
}
The above GSS-API framing shall be applied to all tokens emitted by the
FIPS PUB JJJ GSS-API mechanism, FIPS_CHALN (the challenge from the
Target to the Initiator) FIPS_REP_IT (the response from the Initiator to
the Target for unilateral authentication), FIPS_REPCHALN_IT (the
response from the Initiator to the Target for mutual authentication),
FIPS_REP_TI (the response from the Target to the Initiator for mutual
authentication), and FIPS_ERROR, not just to the initial token
(FIPS_SETUP) in a context establishment sequence. While not required by
RFC-1508, this enables implementations to perform enhanced error-
checking. Furthermore, every innerContextToken will contain a token-id
followed by a context-id.
The innerContextToken field of context establishment tokens for the FIPS
PUB JJJ GSS-API mechanism will consist of a token (FIPS_SETUP
FIPS_CHALN, FIPS_REP_IT, FIPS_REPCHALN_IT,FIPS_REP_TI or FIPS_ERROR)
containing a token_ID field having the value 0100 (hex) for FIPS_SETUP
tokens, 0200 (hex) for FIPS_CHALN tokens, 0300 (hex) for FIPS_REP_IT,
0400 (hex) for FIPS_REPCHALN_IT tokens, 0500 (hex) for FIPS_REP_TI
tokens, and 0600 (hex) for FIPS_ERROR tokens. All innerContextToken's
are encoded using Abstract Syntax Notation One Basic Encoding Rules
(ASN.1 BER).
Each of the following tokens contains a token ID field. The FIPS tokens
themselves have an optional token ID field. But because this token is
an optional field, there is no guarantee that any particular mechanism
in the FIPS PUB JJJ class will have implemented that field. It is
therefore necessary to include such a field in the tokens here.
The FIPS tokens are defined in FIPS PUB JJJ, Appendix A.
Murphy/Balenson/Galvin Expires: January 1996 [Page 8]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
FIPS_SETUP ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
alg_choices SEQUENCE OF AlgorithmIdentifier,
mutual_req BOOLEAN,
mutual_avail BOOLEAN,
unilateral_avail BOOLEAN,
context ContextData OPTIONAL
}
RandomNumber ::= INTEGER
ContextData ::= SEQUENCE {
chan_bindings OCTET STRING OPTIONAL,
options Options OPTIONAL
}
Options ::= BIT STRING {
deleg_req (0),
replay_req (1),
sequence_req (2),
anon_req (3),
lifetime_req (4)
}
FIPS_CHALN ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
alg_subset SEQUENCE OF AlgorithmIdentifier,
mutual_tobeused BOOLEAN,
context ContextData OPTIONAL
fips_token MessageBA
}
Murphy/Balenson/Galvin Expires: January 1996 [Page 9]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
FIPS_REP_IT ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
alg_choice AlgorithmIdentifier,
context ContextData OPTIONAL
fips_token MessageABU
}
FIPS_REPCHALN_IT ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
alg_choice AlgorithmIdentifier,
context ContextData OPTIONAL
fips_token MessageABM
}
FIPS_REP_TI ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
alg_choice AlgorithmIdentifier,
context ContextData OPTIONAL
fips_token MessageBA2
}
FIPS_ERROR ::= SEQUENCE {
token_ID INTEGER,
context_ID RandomNumber,
error_type INTEGER
}
Murphy/Balenson/Galvin Expires: January 1996 [Page 10]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
Where the value of error_type will be
0001 No compatible authentication algorithm found
0002 No compatible authentication type (mutual/unilateral) found
0003 Verification of challenge response has failed.
0004 Invalid token format
0005 Invalid format for fips_token field inside token
The following definition is taken from X.509 - The Directory:
Authentication Framework [7]
Algorithm Identifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
}
6. Security Considerations
This document deals with the security issue of public-key based entity
authentication.
7. References
[1] Standard for Public Key Cryptographic Entity Authentication
Mechanisms (Draft), FIPS PUB JJJ, National Institute of Standards
and Technology, March 13, 1995. (Available online at
http://csrc.ncsl.nist.gov/fips as pkauth.txt and pkauth.ps.)
[2] Linn, J., Generic Security Service Application Program Interface,
RFC 1508, September 10, 1993.
[3] Wray, J., Generic Security Service API : C-bindings, RFC 1509,
September 10, 1993.
[4] Wray, J., Generic Security Service Application Program Interface,
Version 2, Internet Draft (work in progress), <draft-ietf-cat-
gssv2-01.txt>, March 1995.
[5] Adams, C., The Simple Public-Key GSS-API Mechanism (SPKM), Internet
Draft (work in progress), <draft-ietf-cat-spkmgss-02.txt>
Murphy/Balenson/Galvin Expires: January 1996 [Page 11]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
[6] ISO/IEC 9798-1, Information Technology - Security Technologies -
Entity Authentication Mechanisms - Part 1: General model, 1991-09-
01.
[7] ITU-T Rec. X.509 | ISO/IEC 9594-8, Information Technology - Open
Systems Interconnection - The Directory: Authentication Framework,
Editor's DRAFT, February 14, 1993.
[8] Public Key Cryptography Entity Authentication Mechanisms, Federal
Register, Volume 60, Number 108, June 6, 1995, pp. 29749-29958.
8. Authors' Address
Sandra Murphy <murphy@tis.com>
Dave Balenson <balenson@tis.com>
Jim Galvin <galvin@tis.com>
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Murphy/Balenson/Galvin Expires: January 1996 [Page 12]
Internet Draft FIPS PUB JJJ GSS-API Mechanism July 1995
Table of Contents
Status of this Memo .............................................. 1
Abstract ......................................................... 1
1 Acknowledgements ................................................ 1
2 Introduction .................................................... 2
3 Related Work .................................................... 3
4 GSS-API Interface Calls ......................................... 3
4.1 GSS_Init_sec_context call ..................................... 3
4.1.1 First call to GSS_Init_sec_context .......................... 4
4.1.2 Second call to GSS_Init_sec_context ......................... 4
4.1.3 Third call to GSS_Init_sec_context .......................... 5
4.2 GSS_Accept_sec_context call ................................... 5
4.2.1 First call to GSS_Accept_sec_context ........................ 6
4.2.2 Second call to GSS_Accept_sec_context ....................... 6
5 Tokens .......................................................... 7
6 Security Considerations ......................................... 11
7 References ...................................................... 11
8 Authors' Address ................................................ 12
Murphy/Balenson/Galvin Expires: January 1996 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 06:25:00 |