One document matched: draft-ietf-nfsv4-rpcsec-gss-v2-02.txt
Differences from draft-ietf-nfsv4-rpcsec-gss-v2-01.txt
NFSv4 M. Eisler
Internet-Draft NetApp
Intended status: Standards Track February 24, 2008
Expires: August 27, 2008
RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
Version 2 is the same as Version 1 but adds support for channel
bindings.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Eisler Expires August 27, 2008 [Page 1]
Internet-Draft RPCSEC_GSSv2 February 2008
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3
2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3
3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . . 4
3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . . 4
3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 4
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5
3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6
4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Eisler Expires August 27, 2008 [Page 2]
Internet-Draft RPCSEC_GSSv2 February 2008
1. Introduction and Motivation
RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version
1 (RPCSEC_GSSv1) except that support for channel bindings has been
added. The primary motivation for channel bindings is to securely
take advantage of hardware assisted encryption that might exist at
lower levels of the networking protocol stack, such as at the
Internet Protocol (IP) layer in the form of IPsec. The secondary
motivation is that even if lower levels are not any more efficient at
encryption than the RPCSEC_GSS layer, if encryption is occurring at
the lower level, it can be redundant at the RPCSEC_GSS level.
Once an RPCSEC_GSS target and initiator are mutually assured that
they are each using the same secure, end to end channel, the overhead
of computing message integrity codes (MICs) for authenticating and
integrity protecting RPC requests and replies can be eliminated
because the channel is performing the same function. Similarly, if
the channel also provides confidentiality, the overhead of RPCSEC_GSS
privacy protect can also be eliminated.
2. Channel Bindings Explained
If a channel between two parties is secure, there must be shared
information between the two parties. This information might be
secret or not. The requirement for secrecy depends on the specifics
of the channel.
For example, the shared information could be the concatenation of the
public key of the source and destination of the channel (where each
public key has a corresponding private key). Suppose the channel is
not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are
two channels, one from the initiator to the MITM, and one from the
MITM to the target. The MITM cannot simply force each channel to use
the same public keys, because the public keys come from private keys,
and the key management system for each node will surely assign unique
or random private keys. At most the MITM can force one end of each
channel to use the same public key. The MIC of public keys from the
initiator will not be verified by the target, because at least one of
public keys will be different. Similarly, the MIC of the public keys
from the target will not be verified by the initiator because at
least one of the public keys will be different.
A higher layer protocol using the secure channel can safely exploit
the channel to the mutual benefit of the higher level parties if each
higher level party can prove:
Eisler Expires August 27, 2008 [Page 3]
Internet-Draft RPCSEC_GSSv2 February 2008
o They each know the channel's shared information.
o The proof of the knowledge of the shared information is in fact
being conveyed by each of the higher level parties, and not some
other entities.
RPCSEC_GSSv2 simply adds an optional round trip that has the
initiator compute a GSS MIC on the channel binding's shared
information, and sends the MIC to the target. The target verifies
the MIC, and in turn sends its own MIC of the shared information to
the initiator which verifies the target's MIC. This accomplishes
three things. First the initiator and target are mutually
authenticated. Second, the initiator and target prove they know the
channel's shared information, and thus are using the same channel.
Third, the first and second things are done simultaneously.
3. The RPCSEC_GSSv2 Protocol
The RPCSEC_GSSv2 protocol will now be explained. The entire protocol
is not presented. Instead the differences between RPCSEC_GSSv2 and
RPCSEC_GSSv1 are shown.
3.1. Compatibility with RPCSEC_GSSv1
The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.
3.2. New Version Number
const RPCSEC_GSS_VERS_1 = 1;
const RPCSEC_GSS_VERS_2 = 2; /* new */
struct rpc_gss_cred_t {
union switch (unsigned int version) { /* version of
RPCSEC_GSS */
case RPCSEC_GSS_VERS_1:
case RPCSEC_GSS_VERS_2: /* new */
struct {
rpc_gss_proc_t gss_proc; /* control procedure */
unsigned int seq_num; /* sequence number */
rpc_gss_service_t service; /* service used */
opaque handle<>; /* context handle */
} rpc_gss_cred_vers_1_t;
As is apparent from the above, the RPCSEC_GSSv2 credential has the
same format as the RPCSSEC_GSSv1 credential. By setting the version
field to 2, this indicates that the initiator and target support
channel bindings.
Eisler Expires August 27, 2008 [Page 4]
Internet-Draft RPCSEC_GSSv2 February 2008
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL
enum rpc_gss_proc_t {
RPCSEC_GSS_DATA = 0,
RPCSEC_GSS_INIT = 1,
RPCSEC_GSS_CONTINUE_INIT = 2,
RPCSEC_GSS_DESTROY = 3,
RPCSEC_GSS_BIND_CHANNEL = 4 /* new */
};
struct rpc_gss_chan_bind_input {
opaque rgcbi_chan_bindings<>;
};
Once an RPCSEC_GSSv2 handle has been established over a secure
channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST
support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and
RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be
used. Unlike those two requests, the arguments of the NULL procedure
are not overloaded, because the verifier is of sufficient size for
the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to
RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc
were set to RPCSEC_GSS_DATA. The service field is set to
rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS
handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.
When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is
set to the output of GSS_GetMIC() on the RPC header as described in
Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
verifier of an RPC request is set to the output of GSS_GetMIC() on
the concatenation of the RPC header ("up to and including the
credential") and the XDR encoding of an instance of type data
rpc_gss_chan_bind_input.
Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC
reply is set to the output of GSS_GetMIC() on the seq_num of the
credential of the corresponding request (as described in Section
5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the
concantenation of the seq_num and the XDR encoding of an instance of
data type rpc_gss_chan_bind_input.
The content of rpc_gss_chan_bind_input has a single field,
rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of
channel bindings as defined in [3]. The channel bindings are a
"canonical octet string encoding of the channel bindings", starting
"with the channel bindings prefix followed by a colon (ASCII 0x3A)."
Eisler Expires August 27, 2008 [Page 5]
Internet-Draft RPCSEC_GSSv2 February 2008
Thus the channel bindings of the initiator are verified when the
target verifies the verifier via GSS_VerifyMIC(). Similarly, the
channel bindings of the target are verified when the initiator
verifies the verifier of the RPC reply via GSS_VerifyMIC(). Errors
are handled the same way as described in Section 5.3.3.4.2 of [2].
3.4. New Security Service - rpc_gss_svc_channel_prot
enum rpc_gss_service_t {
/* Note: the enumerated value for 0 is reserved. */
rpc_gss_svc_none = 1,
rpc_gss_svc_integrity = 2,
rpc_gss_svc_privacy = 3,
rpc_gss_svc_channel_prot = 4 /* new */
};
The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is
being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed
successfully, and the secure channel still exists. When
rpc_gss_svc_channel_prot is used, the RPC requests and replies are
similar to those of rpc_gss_svc_none except that the verifiers on the
request and reply always have the flavor set to AUTH_NONE, and the
contents are zero length.
Note that even though NULL verifiers are used when
rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are
used. The same credential is used as before, except that service
field is set to rpc_gss_svc_channel_prot.
4. Version Negotiation
An initiator that supports version 2 of RPCSEC_GSS simply issues an
RPCSEC_GSS request with the version field set to RPCSEC_GSS_VERS_2.
If the target does not recognize RPCSEC_GSS_VERS_2, the target will
return an RPC error per section 5.1 of [2].
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
by version 2 of a target with version 1 of the same target. The
initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
version 1 of a target with version 2 of the same target.
5. Implementation Notes
Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been
performed on an RPCSEC_GSSv2 context handle, the initiator's
implementation may map application requests for rpc_gss_svc_none and
Eisler Expires August 27, 2008 [Page 6]
Internet-Draft RPCSEC_GSSv2 February 2008
rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And
if the secure channel has privacy enabled, requests for
rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot.
6. Acknowledgements
Nico Williams had the idea for extending RPCSEC_GSS to support
channel bindings.
7. Security Considerations
The security considerations are the same as [2].
8. IANA Considerations
None.
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[3] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Author's Address
Mike Eisler
NetApp
5765 Chase Point Circle
Colorado Springs, CO 80919
USA
Phone: +1-719-599-9026
Email: email2mre-ietf@yahoo.com
Eisler Expires August 27, 2008 [Page 7]
Internet-Draft RPCSEC_GSSv2 February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Eisler Expires August 27, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-19 00:30:17 |