📄 rfc2847.txt
字号:
Network Working Group M. Eisler
Request for Comments: 2847 Zambeel
Category: Standards Track June 2000
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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 a server with a public
key certificate. As such, it is analogous to the common low
infrastructure usage of the Transport Layer Security (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 above SPKM.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LIPKEY's Requirements of SPKM . . . . . . . . . . . . . . . . 4
2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
2.4. Context Establishment Tokens . . . . . . . . . . . . . . . . 8
2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . . 8
2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . . 9
Eisler Standards Track [Page 1]
RFC 2847 LIPKEY June 2000
2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . . 9
2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Quality of Protection (QOP) . . . . . . . . . . . . . . . .10
3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . 11
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 11
3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 11
3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 12
3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE . . . . 12
3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE . . . . 13
3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . 14
3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 14
3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 14
3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 15
4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 15
4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 16
4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment . 16
4.3.1.2. Post-SPKM-3 Context Establishment Tokens . . . . . . . 16
4.3.1.2.1. From LIPKEY Initiator . . . . . . . . . . . . . . . 17
4.3.1.2.2. From LIPKEY Target . . . . . . . . . . . . . . . . . 17
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 17
4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 18
5.1. Password Management . . . . . . . . . . . . . . . . . . . 18
5.2. Certification Authorities . . . . . . . . . . . . . . . . 18
5.3. HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 18
5.4. Security of cast5CBC . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 22
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
Eisler Standards Track [Page 2]
RFC 2847 LIPKEY June 2000
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 do not 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 known 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 Certification 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. The
client can then provide a user name and password to the server to
authenticate the client. For example, when TLS is being used with the
http protocol, once there is a secure channel, the http server will
present 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 a certificate for itself
to identify and authenticate it to the server. In addition to a TLS
implementation, the required security infrastructure includes a
public key certificate and password database on the server, and a
list of trusted CAs and their public keys on the client. Most
operating systems that the http server would run on already have a
native password database, so the net additional infrastructure is a
server certificate and CA list. Hence the term "low infrastructure
security model" to identify this typical TLS deployment scenario.
Eisler Standards Track [Page 3]
RFC 2847 LIPKEY June 2000
By using unilateral authentication, and using a mechanism resembling
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 to 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 a mechanism
resembling SPKM-1 can mitigate this problem. This can be a useful
approach to avoid modifying applications that have already bound to
GSS-API, assuming the applications are not statically bound to
specific GSS-API mechanisms. The remainder of this memorandum
defines the thin mechanism: the Low Infrastructure Public Key
Mechanism (LIPKEY).
2. LIPKEY's 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. These changes include some minor changes in
semantics. While it would be possible to implement these semantic
changes within an SPKM-1 implementation (including using the same
mechanism type Object Identifier (OID) as SPKM-1), the set of changes
stretch the interpretation of RFC 2025 to the point where
compatibility would be in danger. A new mechanism type, called SPKM-
3, is warranted. LIPKEY requires that the SPKM implementation support
SPKM-3. SPKM-3 is equivalent to SPKM-1, except as described in the
remainder of this section.
2.1. Mechanism Type
SPKM-3 has a different mechanism type OID from SPKM-1.
spkm-3 OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)spkm(1)spkm-3(3)}
2.2. Name Type
RFC 2025 defines no required name types of SPKM. LIPKEY requires that
the SPKM-3 implementation support all the mechanism independent name
types in RFC 2078.
Eisler Standards Track [Page 4]
RFC 2847 LIPKEY June 2000
2.3. Algorithms
2.3.1. MANDATORY Algorithms
RFC 2025 defines various algorithms for integrity, confidentiality,
key establishment, and subkey derivation. Except for
md5WithRSAEncryption, 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.
SPKM is designed to be extensible with regard to new algorithms. In
order for LIPKEY to work correctly and securely, the following
algorithms MUST be implemented in SPKM-3:
* Integrity algorithms (I-ALG)
NULL-MAC
Because the initiator may not have a certificate for itself,
nor for the target, it is not possible for 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 OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
integrity(3)NULL-MAC(3)}
id-dsa-with-sha1
This is the signature algorithm as defined in Section 7.2.2
of [RFC2459]. As noted in RFC 2459, the ASN.1 OID used to
identify this signature algorithm is:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 3
}
Note that there is a work-in-progress [PKIX] to obsolete RFC
2459. However that work-in-progress does not change the
definition of id-dsa-with-sha1.
HMAC-MD5
A consequence of the SPKM-3 initiator not having a
certificate is that it cannot use a digital signature
algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or
sha1WithRSAEncryption once the context is established.
Instead, a message authentication code (MAC) algorithm is
Eisler Standards Track [Page 5]
RFC 2847 LIPKEY June 2000
required. DES-MAC is specified as recommended in [RFC2025].
Since the security of 56 bit DES has been shown to be
inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3
MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:
HMAC-MD5 OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) isakmpOakley(1)
1
}
The reference for the algorithm OID of HMAC-MD5 is [IANA].
The reference for the HMAC-MD5 algorithm is [RFC2104].
The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC
because SHA-1 is about half the speed of MD5 [Young]. A MAC
based on an encryption algorithm like cast5CBC, DES EDE3, or
RC4 is not mandatory because MD5 is 31 percent faster than
the fastest of the three encryption algorithms [Young].
* Confidentiality algorithm (C-ALG).
RFC 2025 does not have a MANDATORY confidentiality algorithm,
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -