One document matched: draft-ietf-cat-lipkey-00.txt
Network Working Group M. Eisler
Internet Draft Sun Microsystems, Inc.
Document: draft-ietf-cat-lipkey-00.txt February 1999
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
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 memorandum describes a method whereby one can use GSS-API
[RFC2078] to supply a secure channel between a client and server,
authenticating the client with a password, and server with a public
key certificate. As such, it is analogous to the common low
infrastructure usage of the Transport Layer Service (TLS) protocol
[RFC2246].
The method leverages the existing Simple Public Key Mechanism (SPKM)
[RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY)
layered on top of SPKM.
Expires: August 1999 [Page 1]
INTERNET-DRAFT LIPKEY February 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LIPKEY Requirements of SPKM . . . . . . . . . . . . . . . . . 4
2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Context Establish Tokens . . . . . . . . . . . . . . . . . . 6
2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 6
2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . . 6
2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . . 7
2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 7
3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . . 7
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . . 8
3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . . 9
3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . . 9
4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 10
4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 10
4.3.1.1. Context Tokens Prior to SPKM-1 Context Establishment . 11
4.3.1.2. Post-SPKM-1 Context Establishment Token . . . . . . . 11
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 12
4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . 13
5.1. Password Management . . . . . . . . . . . . . . . . . . . 13
5.2. Certificate Authorities . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Expires: August 1999 [Page 2]
INTERNET-DRAFT LIPKEY February 1999
1. Introduction
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 [RFC2119].
This memorandum describes a new security mechanism under the GSS-API
called the Low Infrastructure Public Key Mechanism (LIPKEY). GSS-API
provides a way for an application protocol to implement
authentication, integrity, and privacy. TLS is another way. While TLS
is in many ways simpler for an application to incorporate than GSS-
API, there are situations where GSS-API might be more suitable.
Certainly this is the case with application protocols that run over
connectionless protocols. It is also the case with application
protocols such as ONC RPC [RFC1831] [RFC2203], which have their own
security architecture, and so don't easily mesh with a protocol like
TLS that is implemented as a layer that encapsulates the upper layer
application protocol. GSS-API allows the application protocol to
encapsulate as much of the application protocol as necessary.
Despite the flexibility of GSS-API, it compares unfavorably with TLS
with respect to the perception of the amount of infrastructure
required to deploy it. The better know GSS-API mechanisms, Kerberos
V5 [RFC1964] and SPKM require a great deal of infrastructure to set
up. Compare this to the typical TLS deployment scenario, which
consists of a client with no public key certificate accessing a
server with a public key certificate. The client:
* obtains the server's certificate,
* verifies that it was signed by a trusted certificate authority
(CA),
* generates a random session symmetric key,
* encrypts the session key with the server's public key, and
* sends the encrypted session key to the server.
At this point, the client and server have a secure channel. TLS is
most frequently used with a http, and the http server will then
presents the client with an html page that prompts for a user name
and password. This information is then encrypted with the session key
and sent to the server. The server then authenticates the client.
Note that the client is not required to have certificate. The only
security infrastructure required, other than a TLS implementation, is
a public key certificate and password database on the server. Most
Expires: August 1999 [Page 3]
INTERNET-DRAFT LIPKEY February 1999
operating systems that the http server would run on already have a
native password database, so the net additional infrastructure is a
server certificate. Hence the term "low infrastructure security
model" to identify this typical TLS deployment scenario.
By using unilateral authentication, and using the SPKM-1 mechanism
type, SPKM can offer many aspects of the previously described low
infrastructure security model. An application that uses GSS-API is
certainly free use GSS-API's GSS_Wrap() routine to encrypt a user
name and password and send them to the server, for it to decrypt and
verify.
Applications often have application protocols associated with them,
and there might not be any provision in the protocol to specify a
password. Layering a thin GSS-API mechanism over SPKM-1 can mitigate
this problem. This can be a useful approach to avoid versioning
applications that have already bound to GSS-API, assuming the
applications have not been written to statically bind to specific
GSS-API mechanisms. The remainder of this memorandum describes
section defines the thin mechanism: Low Infrastructure Public Key
Mechanism (LIPKEY).
2. LIPKEY Requirements of SPKM
SPKM-1 with unilateral authentication is close to the desired low
infrastructure model described earlier. This section describes some
additional changes to how SPKM-1 operates in order to realize the low
infrastructure model.
2.1. Mechanism Type
LIPKEY uses only SPKM-1 and so the SPKM implementation must support
this mechanism type as described in RFC 2025:
{ iso(1) identifier-organization(3) dod(6) internet(1) security(5)
mechanisms(5) spkm(1) spkm-1(1) }
2.2. Name Type
RFC 2025 defines no required name types of SPKM. LIPKEY requires that
the SPKM-1 implementation support all the mechanism independent
name types in RFC 2078.
2.3. Algorithms
RFC 2025 defines various algorithms for integrity, confidentiality,
key establishment, and subkey derivation. SPKM is designed to
extensible with regard to new algorithms. In order for LIPKEY to work
correctly and securely, the following algorithms are MUST be
Expires: August 1999 [Page 4]
INTERNET-DRAFT LIPKEY February 1999
implemented in SPKM:
* Integrity algorithm (I-ALG)
Because the initiator may not have a certificate for itself, nor
for the target, it is not possible it to calculate an Integrity
value in the initiator's REQ-TOKEN that is sent to the target.
So we define, in ASN.1 [CCITT] syntax, a null I-ALG that returns
a zero length bit string regardless of the input passed to it:
NULL-MAC ::= {
-- OID to be defined
}
The other consequence of the initiator not having a
certificate is that it cannot use the md5WithRSAEncryption
integrity algorithm. RFC 2025 notes that the DES-MAC I-ALG
is RECOMMENDED; LIPKEY MUST have this algorithm present in
SPKM-1. Note that we still need and so continue to REQUIRE
md5WithRSAEncryption for the checksumming the target's
context token.
* Confidentiality algorithm (C-ALG).
RFC 2025 does not have a MANDATORY confidentiality algorithm,
and instead has RECOMMENDED a 56 bit DES algorithm. Since the
LIPKEY initiator needs to send a password to the target, and
since 56 bit DES has been demonstrated as inadequate [EFF],
LIPKEY MUST be layered over an SPKM-1 implementation that
supports this triple DES algorithm:
DES-EDE3-CBC OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
encryptionAlgorithm(3) 7
}
The reference for this algorithm OID of this algorithm is [RSA].
The reference for the algorithm's description is believed to be
[X9.52].
* Key Establishment Algorithm (K-ALG)
RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional
algorithm. As will be described later, the required
RSAEncryption key establishment algorithm is of no use for a low
infrastructure security mechanism as defined by this memorandum.
Hence, dhKeyAgreement is a REQUIRED key establishment algorithm:
Expires: August 1999 [Page 5]
INTERNET-DRAFT LIPKEY February 1999
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
The REQUIRED Key Establishment (K-ALG), Integrity (I-ALG) and One-Way
Functions for Subkey Derivation (O-ALG) algorithms listed in RFC 2025
continue to be REQUIRED.
2.4. Context Establish Tokens
RFC 2025 sets up a context with a initiator first token (REQ-TOKEN),
a target reply (REP-TI-TOKEN), and finally an initiator second token
(REP-TI-TOKEN) to reply to the target's reply. Since LIPKEY uses
SPKM-1 with unilateral authentication, the REP-TI-TOKEN is not used.
LIPKEY has certain requirements on the contents of the REQ-TOKEN and
REP-TI-TOKEN.
2.4.1. REQ-TOKEN Content Requirements
2.4.1.1. algId and req-integrity
If the initiator cannot calculate a req-integrity field due to the
lack of a target certificate, it should use the NULL-MAC I-ALG
described earlier in this memorandum. This will produce a zero length
bit string the Integrity field.
2.4.1.2. Req-contents
Because RFC 2025 requires that the RSAEncryption K-ALG be present,
SPKM must be able to map the target (targ-name) to its public key
certificate, and thus SPKM can use the RSAEncryption algorithm to
fill in the key-estb-req field. Because LIPKEY assumes a low
infrastructure deployment, SPKM MUST be prepared to be unable to map
the targ-name field of the Req-contents field. This is a
contradiction which is resolved by LIPKEY requiring that the SPKM-1
implementation support the dhKeyAgreement algorithm. Note that if an
SPKM-1 implementation tries to map the target to a certificate, and
succeeds, it is free to use the RSAEncryption K-ALG algorithm. It is
also free to use an algID other than NULL-MAC in the REQ-TOKEN type.
2.4.1.2.1. Options
LIPKEY REQUIRES that the SPKM implementation set the target-certif-
data-required bit to 1 if the only K-ALG in in the key-estb-set field
of Req-contents is dhKeyAgreement. This would normally occur if the
Expires: August 1999 [Page 6]
INTERNET-DRAFT LIPKEY February 1999
SPKM implementation cannot resolve the target name to a certificate.
2.4.1.2.2. Conf-Algs
If the SPKM implementation supports an algorithm weaker than DES-
EDE3-CBC, DES-EDE3-CBC MUST be listed first to encourage the target
to negotiate the stronger algorithm.
2.4.1.2.3. Intg-Algs
Because the initiator will be anonymous (at the SPKM-1 level) and
will not have a certificate for itself, the initiator cannot use an
integrity algorithm that supports non-repudiation.
2.4.2. REP-TI-TOKEN Content Requirements
With the previously described requirements on REQ-TOKEN, the contents
of REP-TI-TOKEN can for the most part be derived from specification
of RFC 2025. The exceptions are the algId and rep-ti-integ fields.
2.4.2.1. algId
The target must never use a NULL-MAC I-ALG; it MUST use
md5WithRSAEncryption.
2.4.2.2. rep-ti-integ
If the req-token has an algId of NULL-MAC, then the target MUST
compute the rep-ti-integ on the concatenation of the req-contents and
rep-ti-contents.
3. How LIPKEY Uses SPKM
3.1. Tokens
LIPKEY will invoke SPKM-1 to produce SPKM tokens. Since the mechanism
that the application uses is LIPKEY, LIPKEY will wrap some of the
SPKM-1 tokens with LIPKEY prefixes. The exact definition of the
tokens is described later in this memorandum.
3.2. Initiator
3.2.1. GSS_Import_name
The initiator uses GSS_Import_name to import the target's name,
typically using the GSS_C_NT_HOSTBASED_SERVICE name type. Ultimately,
Expires: August 1999 [Page 7]
INTERNET-DRAFT LIPKEY February 1999
the output of GSS_Import_name will apply to an SPKM-1 mechanism type
because a LIPKEY target is an SPKM-1 target.
3.2.2. GSS_Acquire_cred
The initiator calls GSS_Acquire_cred. The credentials that are
acquired are LIPKEY credentials, a user name and password. How the
user name and password is acquired is dependent upon the operating
environment. A application that invokes GSS_Acquire_cred() while the
application's user has has a graphical user interface running might
trigger the appearance of a pop up window that prompts for the
information. A application embedded into the operating system, such
as an NFS [Sandberg] client implemented as a native file system might
broadcast a message to the user's terminals telling him to invoke a
command that prompts for the information.
3.2.3. GSS_Init_sec_context
When a program invokes GSS_Init_sec_context on the LIPKEY mechanism
type, if the context handle is NULL, the LIPKEY mechanism will in
turn invoke GSS_Init_sec_context on an SPKM-1 mechanisms implemented
according the requirements described previously. This call to SPKM-1
MUST have the following attributes:
* claimant_cred_handle is NULL
* targ_name is from the previously mentioned GSS_Import_name call
* mutual_req_flag is FALSE
* anon_req_flag is TRUE
* input_token is NULL
All other arguments are derived from the LIPKEY GSS_Init_sec_context
arguments.
The call to the SPKM-1 GSS_Init_sec_context will create a context
handle. The LIPKEY implementation will want to record this within a
LIPKEY context handle, and return the LIPKEY context handle, along
with the rest of the outputs of the SPKM-1 call back to the caller of
the LIPKEY GSS_Init_sec_context call. Since the major status will be
GSS_S_CONTINUED_NEEDED, the caller of LIPKEY will send the
output_token to the target. The initiator then gets back the response
token, and invokes the LIPKEY GSS_Init_sec_context routine again.
LIPKEY invokes the SPKM-1 GSS_Init_sec_context again, and upon
return, the major status should be GSS_S_COMPLETE. However, LIPKEY is
not yet done, because now it must send the user name and password
Expires: August 1999 [Page 8]
INTERNET-DRAFT LIPKEY February 1999
that was passed to it in the claimant_cred_handle on the first call
to the LIPKEY GSS_Init_sec_context. LIPKEY uses the established
SPKM-1 context handle as the input to GSS_Wrap (with conf_req_flag
set to TRUE) to encrypt what the claimant_cred_handle refers to (user
name and password), and returns that as the output token to caller
(provided the conf_state output of GSS_Wrap is TRUE), along with a
major status of GSS_S_CONTINUED_NEEDED.
The caller sends its second token to the target, and waits for either
GSS_S_COMPLETE response from the target, indicating that the user
name and password was accepted, or a and error indicting rejection of
user name and password (GSS_NO_CRED), or some other appropriate
error.
The SPKM-1 context remains established while LIPKEY context is
established. If the SPKM-1 context expires before the LIPKEY context
is destroyed, the LIPKEY implementation should expire the LIPKEY
context and return the appropriate error on the next operation.
3.2.4. Other operations
For other operations, the LIPKEY context acts as a pass through to
the SPKM-1 context. Operations that affect or inquire context state,
such as GSS_Delete_sec_context, GSS_Export_sec_context,
GSS_Import_sec_context, and GSS_Inquire_context will require a pass
through to the SPKM-1 context and a state modification of the LIPKEY
context.
3.3. Target
3.3.1. GSS_Import_name
As with initiator, the imported name will be that of the target.
3.3.2. GSS_Acquire_cred
The acceptor calls the LIPKEY GSS_Acquire_cred to get a credential
for an SPKM-1 target, via the SPKM-1 GSS_Acquire_cred routine. The
desired_name is the output_name from GSS_Import_name.
3.3.3. GSS_Accept_sec_context
When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism
type, if the context handle is NULL, the LIPKEY mechanism will in
turn invoke GSS_Accept_sec_context on an SPKM-1 mechanisms
implemented according the requirements described previously. This
call first SPKM-1 is no different than what one would expect for an
Expires: August 1999 [Page 9]
INTERNET-DRAFT LIPKEY February 1999
layered call to GSS_Accept_sec_context.
If all goes well, the SPKM-1 GSS_Accept_sec_context call succeeds
with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call
returns the output_token to caller, but with a major status of
GSS_S_CONTINUED_NEEDED because the LIPKEY initiator is still expected
to send the user name and password.
Once the SPKM-1 context is in a GSS_S_COMPLETE state, the next token
the target receives will contain the user name and password, wrapped
by the output of an SPKM-1 GSS_Wrap call. The target invokes the
LIPKEY GSS_Accept_sec_context, which in turn invokes SPKM-1
GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then
compares the user name and password with its user name name and
password database. If the initiator's user name and password are
valid, GSS_S_COMPLETE is returned to the caller. Otherwise
GSS_NO_CRED is returned. In either case, a zero length output_token
is returned to the caller. The target should send the major status
to the initiator and expect no more context tokens for that context.
4. LIPKEY Description
4.1. Mechanism Type
The Object Identifier for LIPKEY is to be defined.
4.2. Name Types
LIPKEY uses only the mechanism independent name types defined in RFC
2078.
4.3. Token Formats
4.3.1. Context Tokens
GSS-API defines the context tokens as:
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
Expires: August 1999 [Page 10]
INTERNET-DRAFT LIPKEY February 1999
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
The contents of the innerContextToken depend on whether the SPKM-1
context is established or not.
4.3.1.1. Context Tokens Prior to SPKM-1 Context Establishment
In a LIPKEY InitialContextToken, thisMech will be the Object
identifier for LIPKEY. However, as long as LIPKEY has not
established the SPKM-1 mechanism, the innerContextToken for both the
InitialContextToken and the SubsequentContextToken will be the output
of an SPKM GSS_Init_sec_context or GSS_Accept_sec_context. So the
LIPKEY innerContextToken would be either:
* An InitialContextToken, with thisMech set to the object
identifier for SPKM-1, with innerContextToken defined to be an
SPKMInnerContextToken, as defined in RFC 2025.
* A SubsequentContextToken, with innerContextToken defined to be
SPKMInnerContextToken
4.3.1.2. Post-SPKM-1 Context Establishment Token
Once the SPKM-1 context is established, there is just one token sent
from the initiator to the target, and no token returned to initiator.
This token is the result of a GSS_Wrap (conf_req is set to TRUE) of a
user name and password by the SPKM-1 context. This is the SPKM-WRAP
token and is partially reproduced here from RFC 2025:
SPKM-WRAP ::= SEQUENCE {
wrap-header Wrap-Header,
wrap-body Wrap-Body
}
Wrap-Body ::= SEQUENCE {
int-cksum BIT STRING,
-- Checksum of header and data,
-- calculated according to
-- algorithm specified in int-alg
-- field of wrap-header
data BIT STRING
-- encrypted data.
}
The "data" field of Wrap-Body is contains the result of encrypting
this type:
Expires: August 1999 [Page 11]
INTERNET-DRAFT LIPKEY February 1999
UserName-Password ::= SEQUENCE {
user-name OCTET STRING,
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
password OCTET STRING
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
}
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap
RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required
sealedUserData ANY
As one can seem there are no mechanism independent prefixes in
PerMSGToken or SealedMessage, and no explicit mechanism specific
information either. Since LIPKEY doesn't add any value to GSS_GetMIC
and GSS_Wrap other than passing the message to the SPKM-1 GSS_GetMIC
and GSS_Wrap, the PerMsgToken and SealedMessage tokens are exactly
what SPKM-1's GSS_GetMIC and GSS_Wrap routines produce.
4.4. Quality of Protection
LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-1,
doesn't interpret or alter the QOPs passed to the aforementioned
routines or received from their complements, GSS_Unwrap, and
GSS_VerifyMIC.
The SPKM-1 initiator and target negotiate the set of algorithms they
mutually support. If a QOP of zero is specified, then the initiator
and target will use the first C-ALG (privacy), and I-ALG integrity
algorithm negotiated. SPKM also lets one explicitly specify mechanism
specific and implementation specific algorithms, but the QOPs for
additional algorithms outside of RFC 2025 both appear to be
indeterminate. Since this memorandum adds a triple DES algorithm, it
would be desirable to the the application ensure that it is used.
Expires: August 1999 [Page 12]
INTERNET-DRAFT LIPKEY February 1999
SPKM has a type of QOP that lets one specify a algorithm by relative
strength. Since the key length of triple DES is 112 bits, one can
specify a QOP of 0x14000002 to get strong privacy with DES_MAC
integrity. Or just 0x2 to get just DES_MAC integrity. See section 5.2
of RFC 2025 to a fuller explanation.
5. Security Considerations
5.1. Password Management
LIPKEY sends the clear text password encrypted by triple DES, so the
risk in this approach is in how the target manages the password after
it is done with it. Provided the target clears the memory (primary
and secondary, such as disk) buffers that contained the password, and
any hash of the password immediately after if has verify the user's
password, this approach should be safe.
5.2. Certificate Authorities
The initiator must have a list of trusted Certificate authorities in
order to verify the checksum on the SPKM-1 target's context reply
token. It if encounters a certificate signed by an unknown
certificate authority, the initiator MUST NOT silently accept the
certificate. If it does wish to accept the certificate, it MUST get
confirmation from the user running the application that is using
GSS-API.
Expires: August 1999 [Page 13]
INTERNET-DRAFT LIPKEY February 1999
References
[CCITT]
CCITT (1988). "Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1)"
[EFF]
Electronic Frontier Foundation, John Gilmore (Editor),
(1998). "Cracking Des: Secrets of Encryption Research,
Wiretap Politics & Chip Design". O'Reilly & Associates,
ISBN 1565925203.
[PKCS-3]
RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-
Agreement Standard, Version 1.4,"
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
[RSA]
S/MIME Editor, RSA Data Security, Inc. (1995). "S/MIME
Implementation Guide Interoperability Profile, Version 1."
ftp://ftp.rsa.com/pub/S-MIME/smimeimp.txt
[Sandberg]
Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
B.. (1985). "Design and Implementation of the Sun Network
Filesystem," Proceedings of the 1985 Summer USENIX
Technical Conference.
[RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol
Specification Version 2," RFC 1831.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1831.txt
[RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation
Standard," RFC 1832.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1832.txt
[RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol
Specification," RFC 2203.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2203.txt
[RFC2025] Adams, C. (1996). "The Simple Public-Key GSS-API Mechanism
(SPKM)," RFC 2025.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2025.txt
[RFC2078] Linn, J. (1997). "Generic Security Service Application
Program Interface, Version 2," RFC 2078.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2078.txt
Expires: August 1999 [Page 14]
INTERNET-DRAFT LIPKEY February 1999
[RFC2119] Bradner, S. (1997). "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt
[RFC2246] T. Dierks, C. Allen (1999). "The TLS Protocols Version
1.0," RFC 2246.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt
[RFC2279] Yergeau, F. (1998), "UTF-8, a transformation format of ISO
10646", RFC2279,
http://info.internet.isi.edu/in-notes/rfc/files/rfc2279.txt
[X9.52] American National Standards Institute (1996) ANSI Draft
X9.52. "Triple Data Encryption Algorithms Modes of
Operations," Revision 6.0.
Acknowledgments
The author thanks and acknowledges:
* Jack Kabat for his patient explanation of the intricacies of
SPKM, and for his excellent suggestions.
* This memorandum includes ASN.1 definitions for GSS-API tokens
from RFC 2078, which was authored by John Linn.
* This memorandum includes ASN.1 definitions and other text from
the SPKM definition in RFC 2025, which was authored by Carlisle
Adams.
Author's Address
Address comments related to this memorandum to:
cat-ietf@mit.edu
Mike Eisler
Sun Microsystems, Inc.
5565 Wilson Road
Colorado Springs, CO 80919
Phone: 1-719-599-9026
E-mail: mre@eng.sun.com
Expires: August 1999 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 06:10:00 |