< draft-wilkinson-afs3-rxgk-afs-07.txt   draft-wilkinson-afs3-rxgk-afs-08.txt >
Network Working Group S. Wilkinson Network Working Group S. Wilkinson
Internet-Draft YFS Internet-Draft YFS
Intended status: Informational B. Kaduk Intended status: Informational B. Kaduk
Expires: March 9, 2015 MIT Expires: November 22, 2015 MIT
September 5, 2014 May 21, 2015
Integrating rxgk with AFS Integrating rxgk with AFS
draft-wilkinson-afs3-rxgk-afs-07 draft-wilkinson-afs3-rxgk-afs-08
Abstract Abstract
This document describes how the new GSSAPI-based rxgk security class This document describes how the new GSSAPI-based rxgk security class
for RX is integrated with the AFS application protocol. It describes for RX is integrated with the AFS application protocol. It describes
a number of extensions to the basic rxgk protocol, clarifies a number a number of extensions to the basic rxgk protocol, clarifies a number
of implementation issues, and provides values for the application- of implementation issues, and provides values for the application-
specific elements of rxgk. specific elements of rxgk.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2015. This Internet-Draft will expire on November 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
5. Key Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 5. Key Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Application-Specific GSSNegotiate Behavior for AFS-3 . . 6 5.1. Application-Specific GSSNegotiate Behavior for AFS-3 . . 6
5.2. Token Applicability . . . . . . . . . . . . . . . . . . . 6 5.2. Token Applicability . . . . . . . . . . . . . . . . . . . 6
6. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Container . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Container . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Token Encryption . . . . . . . . . . . . . . . . . . . . 7 6.2. Token Encryption . . . . . . . . . . . . . . . . . . . . 7
6.3. Token Contents . . . . . . . . . . . . . . . . . . . . . 7 6.3. Token Contents . . . . . . . . . . . . . . . . . . . . . 7
7. Cache Manager Tokens . . . . . . . . . . . . . . . . . . . . 8 7. Cache Manager Tokens . . . . . . . . . . . . . . . . . . . . 8
7.1. Keyed Clients . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Keyed Clients . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Unkeyed Clients . . . . . . . . . . . . . . . . . . . . . 9 7.2. Unkeyed Clients . . . . . . . . . . . . . . . . . . . . . 9
8. Combining Tokens . . . . . . . . . . . . . . . . . . . . . . 9 8. Combining Tokens . . . . . . . . . . . . . . . . . . . . . . 10
9. The AFSCombineTokens Operation . . . . . . . . . . . . . . . 10 9. The AFSCombineTokens Operation . . . . . . . . . . . . . . . 10
10. Server to Server Communication . . . . . . . . . . . . . . . 12 10. Server to Server Communication . . . . . . . . . . . . . . . 12
10.1. Token Printing . . . . . . . . . . . . . . . . . . . . . 12 10.1. Token Printing . . . . . . . . . . . . . . . . . . . . . 13
10.2. Declaring rxgk Support for a Fileserver . . . . . . . . 13 10.2. Declaring rxgk Support for a Fileserver . . . . . . . . 13
10.2.1. File Servers With the Cell-Wide Key . . . . . . . . 13 10.2.1. File Servers With the Cell-Wide Key . . . . . . . . 14
10.2.2. File Servers With Per-Server Keys . . . . . . . . . 13 10.2.2. File Servers With Per-Server Keys . . . . . . . . . 14
10.3. Registering Per Server Keys . . . . . . . . . . . . . . 14 10.3. Registering Per Server Keys . . . . . . . . . . . . . . 15
11. Securing the Callback Channel . . . . . . . . . . . . . . . . 17 11. Securing the Callback Channel . . . . . . . . . . . . . . . . 18
11.1. Lifetime and scope of the callback channel . . . . . . . 17 11.1. Lifetime and scope of the callback channel . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 18 13. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14.1. Downgrade attacks . . . . . . . . . . . . . . . . . . . 18 14.1. Downgrade attacks . . . . . . . . . . . . . . . . . . . 19
14.2. Per Server Keys . . . . . . . . . . . . . . . . . . . . 18 14.2. Per Server Keys . . . . . . . . . . . . . . . . . . . . 19
14.3. Combined Key Materials . . . . . . . . . . . . . . . . . 18 14.3. Combined Key Materials . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.1. Informational References . . . . . . . . . . . . . . . . 18 15.1. Informational References . . . . . . . . . . . . . . . . 19
15.2. Normative References . . . . . . . . . . . . . . . . . . 19 15.2. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 20
B.1. Since 00 . . . . . . . . . . . . . . . . . . . . . . . . 19 B.1. Since 00 . . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Since 01 . . . . . . . . . . . . . . . . . . . . . . . . 20 B.2. Since 01 . . . . . . . . . . . . . . . . . . . . . . . . 21
B.3. Since 02 . . . . . . . . . . . . . . . . . . . . . . . . 20 B.3. Since 02 . . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. Since 03 . . . . . . . . . . . . . . . . . . . . . . . . 20 B.4. Since 03 . . . . . . . . . . . . . . . . . . . . . . . . 21
B.5. Since 04 . . . . . . . . . . . . . . . . . . . . . . . . 20 B.5. Since 04 . . . . . . . . . . . . . . . . . . . . . . . . 22
B.6. Since 05 . . . . . . . . . . . . . . . . . . . . . . . . 21 B.6. Since 05 . . . . . . . . . . . . . . . . . . . . . . . . 22
B.7. Since 06 . . . . . . . . . . . . . . . . . . . . . . . . 21 B.7. Since 06 . . . . . . . . . . . . . . . . . . . . . . . . 22
B.8. Since 07 . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
rxgk [I-D.wilkinson-afs3-rxgk] is a new GSSAPI-based [RFC2743] rxgk [I-D.wilkinson-afs3-rxgk] is a new GSSAPI-based [RFC2743]
security layer for the RX [RX] remote procedure call system. The security layer for the RX [RX] remote procedure call system. The
rxgk specification details how it may be used with a generic RX rxgk specification details how it may be used with a generic RX
application, but leaves some aspects of the protocol as application- application, but leaves some aspects of the protocol as application-
specific. This document resolves the application-specific portions specific. This document resolves the application-specific portions
of rxgk for use with the AFS-3 distributed file system, and provides of rxgk for use with the AFS-3 distributed file system, and provides
additional detail specific to integrating rxgk with AFS-3. additional detail specific to integrating rxgk with AFS-3.
skipping to change at page 4, line 47 skipping to change at page 4, line 48
use the indicated callback key. use the indicated callback key.
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Security Index 2. Security Index
When used within the AFS protocol, rxgk has an RX securityIndex value When used within the AFS-3 protocol, rxgk has an RX securityIndex
of 4. value of 4.
3. Authenticator Data 3. Authenticator Data
The appdata opaque within the RXGK_Authenticator structure used in The appdata opaque within the RXGK_Authenticator structure used in
the rx challenge/response authentication exchange contains the the rx challenge/response authentication exchange contains the
results of XDR encoding the RXGK_Authenticator_AFSAppData structure. results of XDR [RFC4506] encoding the RXGK_Authenticator_AFSAppData
structure.
struct RXGK_Authenticator_AFSAppData { struct RXGK_Authenticator_AFSAppData {
afsUUID client_uuid; afsUUID client_uuid;
RXGK_Data cb_tok; RXGK_Data cb_tok;
RXGK_Data cb_key; RXGK_Data cb_key;
afs_int32 enctype; afs_int32 enctype;
afsUUID target_uuid; afsUUID target_uuid;
}; };
client_uuid the UUID of the client. client_uuid the UUID of the client.
cb_tok the rxgk token to be used for secure callbacks created by cb_tok the rxgk token to be used for secure callbacks created by
RPCs over this connection. In some implementations this token RPCs over this connection. In some implementations this token
may be empty (zero-length). may be empty (zero-length).
cb_key the raw key material (k0) to which cb_tok corresponds, to be cb_key the raw key material (k0) to which cb_tok corresponds, to be
used as the master key for the secure callback connections used as the master key for the secure callback connections
created by RPCs over this connection. created by RPCs over this connection.
enctype the RFC 3961 enctype of the cb_key key material. enctype the [RFC3961] enctype of the cb_key key material.
target_uuid the UUID of the server being authenticated to (if target_uuid the UUID of the server being authenticated to (if
applicable). Database servers do not have UUIDs; when applicable). Database servers do not have UUIDs; when
authenticating to database servers, this field should be set to authenticating to database servers, this field should be set to
all zero bits. File server UUIDs may be obtained from the VLDB all zero bits. File server UUIDs may be obtained from the VLDB
in the same call that returns their addresses. in the same call that returns their addresses.
4. Application-Specific Constant 4. Application-Specific Constant
The constant RXGK_MAXDATA takes the value 1048576 for use with AFS-3. The constant RXGK_MAXDATA takes the value 1048576 for use with AFS-3.
skipping to change at page 6, line 4 skipping to change at page 6, line 5
An AFS cell wishing to support rxgk MUST run an rxgk key negotiation An AFS cell wishing to support rxgk MUST run an rxgk key negotiation
service, as specified in [I-D.wilkinson-afs3-rxgk], on each of its service, as specified in [I-D.wilkinson-afs3-rxgk], on each of its
vlservers. The service MUST listen on the same port as the vlserver. vlservers. The service MUST listen on the same port as the vlserver.
The GSS identity afs-rxgk@_afs.<cellname> of nametype The GSS identity afs-rxgk@_afs.<cellname> of nametype
GSS_C_NT_HOSTBASED_SERVICE is the acceptor identity for this service. GSS_C_NT_HOSTBASED_SERVICE is the acceptor identity for this service.
Where multiple vlservers exist for a single cell, all of these Where multiple vlservers exist for a single cell, all of these
servers must have access to the key material for this identity, which servers must have access to the key material for this identity, which
MUST be identical across the cell. Clients MAY use the presence of MUST be identical across the cell. Clients MAY use the presence of
this identity as an indicator of rxgk support for a particular cell. this identity as an indicator of rxgk support for a particular cell.
Clients that wish to support cells using other rx security objects Clients that wish to support cells using other rx security objects
MAY downgrade if this identity is not available. MAY downgrade if this identity is not available. Note that not all
GSS mechanisms can expose to the initiator whether or not a given
acceptor identity exists.
5.1. Application-Specific GSSNegotiate Behavior for AFS-3 5.1. Application-Specific GSSNegotiate Behavior for AFS-3
The input and output opaques of the GSSNegotiate RPC are left as The input and output opaques of the GSSNegotiate RPC are left as
implementation-defined, as needed to retain information across implementation-defined, as needed by the implementation to retain
subsequent calls during a single GSS negotiation loop. information across subsequent calls during a single GSS negotiation
loop.
5.2. Token Applicability 5.2. Token Applicability
Tokens returned from the GSSNegotiate and CombineTokens calls MUST Tokens returned from the GSSNegotiate and CombineTokens calls MUST
only be used with database servers. Tokens for fileservers MUST be only be used with database servers. Tokens for fileservers MUST be
obtained by calling AFSCombineTokens (Section 9) before each server obtained by calling AFSCombineTokens (Section 9) before each server
is contacted. is contacted.
rxgk tokens are in general only usable with the particular rx service rxgk tokens are in general only usable with the particular rx service
that produced them. For the AFS-3 protocol, the database server that produced them. For the AFS-3 protocol, the database server
skipping to change at page 6, line 48 skipping to change at page 7, line 6
6.1. Container 6.1. Container
rxgk tokens for AFS take the form of some key management data, rxgk tokens for AFS take the form of some key management data,
followed by an encrypted data blob. The key management data (a followed by an encrypted data blob. The key management data (a
version number, followed by an RFC 3961 encryption type) allows the version number, followed by an RFC 3961 encryption type) allows the
server receiving a token to identify which key has been used to server receiving a token to identify which key has been used to
encrypt the core token data. encrypt the core token data.
struct RXGK_TokenContainer { struct RXGK_TokenContainer {
afs_int32 kvno; afs_uint32 kvno;
afs_int32 enctype; afs_int32 enctype;
opaque encrypted_token<>; opaque encrypted_token<>;
}; };
The RXGK_TokenContainer structure is XDR encoded and transported The RXGK_TokenContainer structure is XDR encoded and transported
wherever a token is used, such as in the 'token' field of the wherever a token is used, such as in the 'token' field of the
RXGK_ClientInfo structure specified in [I-D.wilkinson-afs3-rxgk]. RXGK_ClientInfo structure specified in [I-D.wilkinson-afs3-rxgk].
6.2. Token Encryption 6.2. Token Encryption
rxgk supports encrypting tokens both with a single cell-wide key and rxgk supports encrypting tokens with either a single cell-wide key or
with per-file-server keys. The cell-wide key must be installed on with per-file-server keys. The cell-wide key must be installed on
all database servers in the cell, and may additionally be installed all database servers in the cell, and may additionally be installed
on non-database file servers when per-file-server keys are not on non-database file servers when per-file-server keys are not in
desired. Cell-wide keys should be for a selected RFC 3961 encryption use. Cell-wide keys should be for a selected RFC 3961 encryption
mechanism that is supported by all servers within the cell that will mechanism that is supported by all servers within the cell that will
use that key. Per-server keys should be for an encryption mechanism use that key. Per-server keys should be for an encryption mechanism
that is supported by both the destination server and the negotiation that is supported by both the destination server and the negotiation
service on the vlserver. The management of per-server keys is service on the vlserver. The management of per-server keys is
discussed in more detail in Section 14.2. discussed in more detail in Section 14.2.
Key rollover is permitted by means of a key version number. When a Key rollover is permitted by means of a key version number. When a
key is changed, whether cell-wide or per-server, a different (larger) key is changed, whether cell-wide or per-server, a different (larger)
key version number MUST be selected. Servers SHOULD accept tokens key version number MUST be selected. Servers SHOULD accept tokens
using old keys until the lifetime of all existing non-printed (see using old keys until the lifetime of all existing non-printed (see
skipping to change at page 9, line 10 skipping to change at page 9, line 21
may be authenticated at the fileserver while still preserving the may be authenticated at the fileserver while still preserving the
integrity of the data obtained by the cache manager. In order to integrity of the data obtained by the cache manager. In order to
obtain a token, the cache manager must have some means of acquiring/ obtain a token, the cache manager must have some means of acquiring/
using key material. using key material.
7.1. Keyed Clients 7.1. Keyed Clients
When a host already has key material for a GSSAPI mechanism supported When a host already has key material for a GSSAPI mechanism supported
by the vlserver, that material MAY be used to key the cache manager. by the vlserver, that material MAY be used to key the cache manager.
The cache manager simply calls the rxgk negotiation service using the The cache manager simply calls the rxgk negotiation service using the
relevant material, and obtains a token. The cache manager should relevant material, and obtains a token. This token is a database
frequently regenerate this token, to avoid combined tokens having server token; there is no need in the protocol for it to be usable as
unnecessarily close expiration times. The cache manager should not the user_tok input to AFSCombineTokens or for there to be an entry in
regenerate this token so often so as to place excessive load on the the protection database corresponding to the cache manager's GSS
vlservers. identity. The cache manager should frequently regenerate its token,
to avoid combined tokens having expiration times which are
substantially earlier than the expiration time of the corresponding
user credentials. The cache manager should not regenerate this token
so often so as to place excessive load on the vlservers.
It is recommended that GSS identities created specifically for use by It is recommended that GSS identities created specifically for use by
a cache manager have the name afs3-callback@<hostname> of name type a cache manager have the name afs3-callback@<hostname> of name type
GSS_C_NT_HOSTBASED_SERVICE where <hostname> is the fully qualified GSS_C_NT_HOSTBASED_SERVICE where <hostname> is the fully qualified
domain name of the cache manager. domain name of the machine upon which the cache manager is running.
7.2. Unkeyed Clients 7.2. Unkeyed Clients
When a client has no key material, it is possible that an anonymous When a client has no key material, it is possible that an anonymous
GSSAPI connection may succeed. Clients MAY attempt to negotiate such GSSAPI connection may succeed. Clients MAY attempt to negotiate such
a connection by calling GSS_Init_sec_context() with the anon_req_flag a connection by calling GSS_Init_sec_context() with the anon_req_flag
[RFC2743] and the default credentials set. [RFC2743] and the default credentials set.
In some cases a cache manager may not have any dedicated credentials, In some cases a cache manager may not have any dedicated credentials,
but have user credentials from multiple different users. These but have user credentials from multiple different users. These
skipping to change at page 10, line 22 skipping to change at page 10, line 39
enctype and security level negotiation with the server, and a enctype and security level negotiation with the server, and a
destination file server identifier. It returns a token specific to destination file server identifier. It returns a token specific to
the specified destination fileserver, and a structure containing some the specified destination fileserver, and a structure containing some
information describing the returned token. AFSCombineTokens is the information describing the returned token. AFSCombineTokens is the
only way to obtain a valid file server token (other than printing a only way to obtain a valid file server token (other than printing a
token, see Section 10.1). token, see Section 10.1).
AFSCombineTokens(IN RXGK_Data *user_tok, AFSCombineTokens(IN RXGK_Data *user_tok,
IN RXGK_Data *cm_tok, IN RXGK_Data *cm_tok,
IN RXGK_CombineOptions *options, IN RXGK_CombineOptions *options,
IN afsUUID destination, IN afsUUID *destination,
OUT RXGK_Data *new_token, OUT RXGK_Data *new_token,
OUT RXGK_TokenInfo *token_info) = TBD; OUT RXGK_TokenInfo *token_info) = TBD;
user_tok: An rxgk token for the vlserver. user_tok: An rxgk token for the vlserver.
cm_tok: Either an rxgk token for the vlserver, or empty (zero- cm_tok: Either an rxgk token for the vlserver, or empty (zero-
length). length).
options: An RXGK_CombineOptions structure containing a list of options: An RXGK_CombineOptions structure containing a list of
enctypes acceptable to the client and a list of security levels enctypes acceptable to the client and a list of security levels
skipping to change at page 11, line 16 skipping to change at page 11, line 32
users (such as a traditional AFS Cache Manager), SHOULD provide both users (such as a traditional AFS Cache Manager), SHOULD provide both
the user's token (as user_tok) and a token generated from an identity the user's token (as user_tok) and a token generated from an identity
that is private to the cache manager (as cm_tok). This prevents a that is private to the cache manager (as cm_tok). This prevents a
user from poisoning the cache for other users. Recommendations on user from poisoning the cache for other users. Recommendations on
keying cache managers are contained in Section 7.1. keying cache managers are contained in Section 7.1.
The output token from AFSCombineTokens is a token specific to the The output token from AFSCombineTokens is a token specific to the
fileserver indicated by the destination argument. As such, it is not fileserver indicated by the destination argument. As such, it is not
a valid input token for a successor AFSCombineTokens operation, as a valid input token for a successor AFSCombineTokens operation, as
the input tokens for AFSCombineTokens must be tokens for the the input tokens for AFSCombineTokens must be tokens for the
vlserver. vlserver. To prevent key-reuse attacks, the token master key in the
output token must be unique per destination file server; the
destination UUID is incorporated into the key derivation procedure to
ensure this property.
Clients using a printed token (see Section 10.1) MUST provide that Clients using a printed token (see Section 10.1) MUST provide that
token as user_tok. cm_tok MUST be empty. token as user_tok. cm_tok MUST be empty.
The server uses a zero-length new_token to indicate that the The server uses a zero-length new_token to indicate that the
generation of rxgk tokens for the specified fileserver cannot work at generation of rxgk tokens for the specified fileserver cannot work at
the present time. Upon receipt of such a zero-length new_token, the the present time. Upon receipt of such a zero-length new_token, the
client MAY fall back to using a different authentication mechanism client MAY fall back to using a different authentication mechanism
for that server. An rxgk capable client operating within an rxgk for that server. An rxgk capable client operating within an rxgk
enabled cell MUST NOT downgrade its choice of security layer in any enabled cell MUST NOT downgrade its choice of security layer in any
other situation. other situation. (Such a client may still not attempt to use rxgk at
all for an AFS cell if it has determined that there is no suitable
GSS acceptor identity to be used for that cell.)
In other cases where the server is unable to perform the In other cases where the server is unable to perform the
AFSCombineTokens operation with the given arguments, a nonzero value AFSCombineTokens operation with the given arguments, a nonzero value
is returned. Clients MUST NOT use such an error as an indication to is returned. Clients MUST NOT use such an error as an indication to
fall back to to a different security class. fall back to to a different security class.
The 'identities' list from user_tok is copied to the 'identities' The 'identities' list from user_tok is copied to the 'identities'
field of the new_token. The 'identities' list from cm_tok is field of the new_token. The 'identities' list from cm_tok is
discarded unused. discarded unused.
Other aspects of the operation of AFSCombineTokens, including the Other aspects of the operation of AFSCombineTokens, including the
combination of keys and tokens, are largely the same as the combination of keys and tokens, are largely the same as the
CombineTokens RPC, documented in [I-D.wilkinson-afs3-rxgk] and CombineTokens RPC, documented in [I-D.wilkinson-afs3-rxgk] and
Section 8. The only differences pertain to the case where the Section 8. However, the AFSCombineTokens operation needs to include
supplied cm_tok is empty. In this case, there is only one input the destination file server's UUID in the key combination process to
token master key, so the KRB-FX-CF2() algorithm is not applicable; ensure that the resulting key is unique for each file server (and
instead, the master key K0 from user_tok is reused unchanged for the different from the key in the input tokens); AFSCombineTokens must
output token. The enctype of that K0 MUST be present in the also handle the case where the supplied cm_tok is absent (empty). In
'enctypes' array of the 'options' parameter; if it is absent, the the two-token case, the KRB-FX-CF2 operation is still used, but the
server MUST fail the AFSCombineTokens RPC. pepper1 and pepper 2 inputs will both include the destination UUID:
pepper1 := "AFS" || 00 || destination || enctype
pepper2 := "rxgk" || 00 || destination || enctype
where the strings "AFS" and "rxgk" exclude the NUL terminator; 00 is
a NUL octet; destination is the XDR-encoding of the destination
afsUUID; enctype is the enctype selected by the server and returned
in the enctype field of token_info, encoded as a 32-bit integer in
network byte order; and || is the concatenation operator. In the
one-token case,
Kn := random-to-key(PRF+(K0, pepper0))
pepper0 := "rxgkAFS" || 00 || destination || enctype
where the string "rxgkAFS" excludes the NUL terminator. Note that
the PRF+ function here is the one used in the KRB-FX-CF2 operation
specified in [RFC6113], which differs from the PRF+ function
specified in [RFC4402] and used elsewhere in this document. random-
to-key is the function specified by the RFC3961 profile of the
selected enctype.
10. Server to Server Communication 10. Server to Server Communication
A number of portions of the AFS protocol require that servers A number of portions of the AFS-3 protocol require that servers
communicate amongst themselves. To name a limited subset of communicate amongst themselves. To name a limited subset of
examples, file servers must register their location (IP addresses) examples, file servers must register their location (IP addresses)
with the vldb, and must query the prdb when serving data; moving with the vldb, and must query the prdb when serving data; moving
volumes from one file server to another requires that the file volumes from one file server to another requires that the file
servers communicate with each other directly. servers communicate with each other directly.
A server with the cell-wide shared key can forge a token for its use A server with the cell-wide shared key can forge a token for its use
in server-to-server communication, which we refer to as "token in server-to-server communication, which we refer to as "token
printing". Printed tokens take on a special form (Section 10.1) and printing". Printed tokens take on a special form (Section 10.1) and
are limited in that they cannot be combined with any other token. are limited in that they cannot be combined with any other token.
However, file servers with a server-specific key (that is, without However, file servers with a server-specific key (that is, without
the cell-wide shared key), can only print a token to themselves. the cell-wide shared key), can only print a token to themselves.
Such tokens are not usable to communicate with database servers or Such tokens are not usable to communicate with database servers or
other file servers. As such, file servers with a per-server key will other file servers. As such, file servers with a per-server key will
need GSS credentials in order to function. These credentials can be need GSS credentials (but, as with keyed clients, not necessarily
used to acquire an rxgk token, allowing queries to the database entries in the protection database) in order to function. These
servers. They can also be used to register the file server in the credentials can be used to acquire an rxgk token, allowing queries to
vldb, and to create and update the file server's server-specific key the database servers. They can also be used to register the file
in the vldb. server in the vldb, and to create and update the file server's
server-specific key in the vldb.
10.1. Token Printing 10.1. Token Printing
A server with access to the cell-wide pre-shared key may print its A server with access to the cell-wide pre-shared key may print its
own tokens for server-to-server access. To do so, it should own tokens for server-to-server access. To do so, it should
construct a database server token with suitable values. The list of construct a database server token with suitable values. The list of
identities in such a token MUST be empty. It can then encrypt this identities in such a token MUST be empty. It can then encrypt this
token using the pre-shared key, place it in an RXGK_TokenContainer token using the pre-shared key, place it in an RXGK_TokenContainer
describing the key used to perform the encryption, and use it in the describing the key used to perform the encryption, and use it in the
same way as a normal rxgk token. The receiving server can identify same way as a normal rxgk token. The receiving server can identify
it is a printed token by the empty identity list. it as a printed token by the empty identity list.
The session key within a printed database server token MUST use the The session key within a printed database server token MUST use the
same encryption type as the pre-shared key. When connecting to a same encryption type as the pre-shared key. When connecting to a
fileserver starting from a printed token, a client MUST use the fileserver starting from a printed token, a client MUST use the
AFSCombineTokens service as discussed above to ensure that they are AFSCombineTokens service as discussed above to ensure that they are
using the correct key for the fileserver. using the correct key for the fileserver.
File servers with per-server keys may also print tokens, though these File servers with per-server keys may also print tokens, though these
tokens are in general of limited utility. (Being file server tokens, tokens are in general of limited utility. (Being file server tokens,
they are not valid inputs to AFSCombineTokens, etc..) they are not valid inputs to AFSCombineTokens, etc..)
skipping to change at page 13, line 34 skipping to change at page 14, line 22
VL_RegisterAddrs and VL_RegisterAddrsAndKey from a printed token, an VL_RegisterAddrs and VL_RegisterAddrsAndKey from a printed token, an
administrator, or the identity registered for the fileserver using a administrator, or the identity registered for the fileserver using a
prior call to VL_RegisterAddrsandKey. prior call to VL_RegisterAddrsandKey.
There are two tracks for registering a file server as being rxgk- There are two tracks for registering a file server as being rxgk-
enabled; one for file servers with the cell-wide key, and another for enabled; one for file servers with the cell-wide key, and another for
file servers with per-server keys. file servers with per-server keys.
10.2.1. File Servers With the Cell-Wide Key 10.2.1. File Servers With the Cell-Wide Key
When a file server which will use the cell-wide key is registered as When a file server that will use the cell-wide key is registered as
rxgk-capable, there is no need to register a new key for that server rxgk-capable, there is no need to register a new key for that server
(and in fact it would be actively harmful!), so there is no need to (and in fact it would be actively harmful!), so there is no need to
use VL_RegisterAddrsAndKey. In this case, VL_RegisterAddrs is use VL_RegisterAddrsAndKey. In this case, VL_RegisterAddrs is
sufficient, and using a printed token for the rxgk connection for sufficient, and using a printed token for the rxgk connection for
VL_RegisterAddrs indicates that the file server possesses the cell- VL_RegisterAddrs indicates that the file server possesses the cell-
wide key. Since the file server has the cell-wide shared key, it wide key. Since the file server has the cell-wide shared key, it
will need get its key updated when the cell-wide key is updated, and will get its key updated when the cell-wide key is updated, and does
does not need to update its own key separately. As such, it will not need to update its own key separately. As such, it will never
never need to call VL_RegisterAddrsAndKey. need to call VL_RegisterAddrsAndKey.
10.2.2. File Servers With Per-Server Keys 10.2.2. File Servers With Per-Server Keys
This section describes the case when the automated keying mechanism This section describes the case when the automated keying mechanism
described in Section 10.3 is used. If the record of per-server keys described in Section 10.3 is used. If the record of per-server keys
in the vldb is being manually maintained, cell administrators should in the vldb is being manually maintained, cell administrators should
manually register the file servers in the vldb using VL_RegisterAddrs manually register the file servers in the vldb using VL_RegisterAddrs
instead. instead.
Since the goal is to establish a per-server key, Since the goal is to establish a per-server key,
skipping to change at page 14, line 22 skipping to change at page 15, line 10
since only a printed token would be able to perform a subsequent since only a printed token would be able to perform a subsequent
call. The printed token would require the cell-wide shared key, call. The printed token would require the cell-wide shared key,
eliminating any benefit from having a server-specific key. As such, eliminating any benefit from having a server-specific key. As such,
a regular (non-printed) token is required for the initial call to a regular (non-printed) token is required for the initial call to
VL_RegisterAddrsAndKey. A cell administrator's token could be used, VL_RegisterAddrsAndKey. A cell administrator's token could be used,
but it is advantageous to allow file servers with per-server keys to but it is advantageous to allow file servers with per-server keys to
operate without intervention by the central cell administrators (so operate without intervention by the central cell administrators (so
that these file servers could be run solely by a local administrator that these file servers could be run solely by a local administrator
without need for central administrator intervention). without need for central administrator intervention).
Thus, is is expected that a file server with a per-server key will Thus, it is expected that a file server with a per-server key will
have a dedicated GSS identity and credentials that it will use for have a dedicated GSS identity and credentials that it will use for
registering with the vldb (VL_RegisterAddrsAndKey) and that will also registering with the vldb (VL_RegisterAddrsAndKey) and that will also
be used for securing the file server's regular connections to the be used for securing the file server's regular connections to the
database servers during normal operation. The vlserver will store in database servers during normal operation. The vlserver will store in
the vldb what GSS identity is used to perform VL_RegisterAddrsAndKey the vldb what GSS identity is used to perform VL_RegisterAddrsAndKey
for a given file server UUID, and allow that identity to perform for a given file server UUID, and allow that identity to perform
successor calls to VL_RegisterAddrsAndKey for that UUID. successor calls to VL_RegisterAddrsAndKey and VL_RegisterAddrs for
that UUID.
Is is RECOMMENDED that GSS identities created solely for use on file Is is RECOMMENDED that GSS identities created solely for use on file
servers with per-server keys be of the form servers with per-server keys be of the form
afs3-fileserver@<hostname> of name type GSS_C_NT_HOSTBASED_SERVICE. afs3-fileserver@<hostname> of name type GSS_C_NT_HOSTBASED_SERVICE.
10.3. Registering Per Server Keys 10.3. Registering Per Server Keys
The provisioning of file servers with their own keys, rather than the The provisioning of file servers with their own keys, rather than the
cell-wide master key, requires the ability to maintain a directory of cell-wide master key, requires the ability to maintain a directory of
these keys in the vldb, so that the AFSCombineTokens RPC can encrypt these keys in the vldb, so that the AFSCombineTokens RPC can encrypt
the outgoing token with the correct key. The manner in which this the outgoing token with the correct key. The manner in which this
directory is maintained is left to the implementor, who MAY decide to directory is maintained is left to the implementor, who MAY decide to
use a manual, or out of band, key management system. Otherwise, the use a manual, out of band, key management system. Otherwise, the
automated keying mechanism described as follows will be used. automated keying mechanism described as follows will be used.
Implementations supporting automatic key management through the AFS-3 Implementations supporting automatic key management through the AFS-3
protocol MUST provide the VL_RegisterAddrsAndKey RPC (similar to the protocol MUST provide the VL_RegisterAddrsAndKey RPC (similar to the
VL_RegisterAddrs RPC). This RPC is called by a fileserver to VL_RegisterAddrs RPC). This RPC is called by a fileserver to
register itself with the VLDB; it MUST be called over a secure register itself with the VLDB; it MUST be called over a secure
connection that provides confidentiality protection. connection that provides confidentiality protection.
For the purpose of this RPC, the fileserver acts as the client and For the purpose of this RPC, the fileserver acts as the client and
the vlserver as the server. Once the RPC completes, both peers of the vlserver as the server. Once the RPC completes, both peers of
the RPC call can generate a key to be used as the fileserver's long- the RPC call can generate a key to be used as the fileserver's long-
term server key. term server key.
vlservers MUST NOT permit calls to VL_RegisterAddrsAndKey for vlservers SHOULD NOT permit calls to VL_RegisterAddrsAndKey for
fileserver UUIDs which already exist within the vldb, unless that fileserver UUIDs which already exist within the vldb, unless that
UUID already has a server-specific key registered. UUID already has a server-specific key registered. Requiring the
separation facilitates a workflow wherein existing servers retain the
cell-wide key, and new file servers are created with per-server keys.
Data volumes can then be gradually migrated to the new file servers,
and old file servers decommissioned. Permitting file servers to
convert from cell-wide key to per-server keys would involve
complicated access checking and update logic for which it is
difficult to ensure correctness of implementation.
The VL_RegisterAddrsAndKey RPC is described by the following RPC-L: The VL_RegisterAddrsAndKey RPC is described by the following RPC-L:
struct RXGK_ServerKeyDataRequest { struct RXGK_ServerKeyDataRequest {
afs_int32 enctypes<>; afs_int32 enctypes<>;
opaque nonce1[20]; opaque nonce1[20];
}; };
struct RXGK_ServerKeyDataResponse { struct RXGK_ServerKeyDataResponse {
afs_int32 enctype; afs_int32 enctype;
afs_int32 kvno; afs_uint32 kvno;
opaque nonce2[20]; opaque nonce2[20];
}; };
const RXGK_MAXKEYDATAREQUEST = 16384; const RXGK_MAXKEYDATAREQUEST = 16384;
const RXGK_MAXKEYDATARESPONSE = 16384; const RXGK_MAXKEYDATARESPONSE = 16384;
typedef opaque keyDataRequest<RXGK_MAXKEYDATAREQUEST>; typedef opaque keyDataRequest<RXGK_MAXKEYDATAREQUEST>;
typedef opaque keyDataResponse<RXGK_MAXKEYDATARESPONSE>; typedef opaque keyDataResponse<RXGK_MAXKEYDATARESPONSE>;
VL_RegisterAddrsAndKey( VL_RegisterAddrsAndKey(
IN afsUUID *uuidp, IN afsUUID *uuidp,
IN afs_int32 spare1, IN afs_int32 spare1,
skipping to change at page 16, line 16 skipping to change at page 17, line 12
mechanism defined by secIndex. For rxgk, it is the XDR-encoded mechanism defined by secIndex. For rxgk, it is the XDR-encoded
representation of an RXGK_ServerDataResponse structure. representation of an RXGK_ServerDataResponse structure.
The client provides, in the RXGK_ServerKeyDataRequest structure, a The client provides, in the RXGK_ServerKeyDataRequest structure, a
list of the RFC3961 encryption types that it will accept as a server list of the RFC3961 encryption types that it will accept as a server
key. It also provides a nonce containing 20 random data bytes. key. It also provides a nonce containing 20 random data bytes.
The server selects an encryption type shared by it and the client, The server selects an encryption type shared by it and the client,
and returns that, along with 20 bytes of random data that it has and returns that, along with 20 bytes of random data that it has
generated, in RXGK_ServerKeyDataResponse. If there is no common generated, in RXGK_ServerKeyDataResponse. If there is no common
encryption type, then the server MUST fail the request. encryption type, then the server MUST fail the request. The kvno
field of the RXGK_ServerKeyDataResponse is used to indicate to the
client what key version number it should use for the key it will
compute using these nonces. The kvno will be used in the
RXGK_TokenContainer bearing file server tokens for this file server,
to indicate which key was used to encrypt the RXGK_Token.
The vlserver MUST store the identity list from the token used to make The vlserver MUST store the identity list from the token used to make
this connection. The vlserver MUST only permit subsequent calls to this connection. The vlserver MUST only permit subsequent calls to
VL_RegisterAddrsAndKey for this UUID when they come over a connection VL_RegisterAddrsAndKey for this UUID when they come over a connection
authenticated with that same identity list, an administrator's token, authenticated with that same identity list, an administrator's token,
or a printed token. Such subsequent calls using an administrator's or a printed token. Such subsequent calls using an administrator's
token or a printed token do not update the identity list associated token or a printed token do not update the identity list associated
with this UUID's key. New fileserver UUIDs register themselves with with this UUID's key. New fileserver UUIDs register themselves with
the vldb in a "leap of faith", binding a GSSAPI identity to the the vldb in a "leap of faith", binding a GSSAPI identity to the
fileserver UUID for future authenticated operations. Fileservers fileserver UUID for future authenticated operations. Fileservers
SHOULD use VL_RegisterAddrsAndKey to rekey themselves periodically, SHOULD use VL_RegisterAddrsAndKey to rekey themselves periodically,
in accordance with key lifetime best practices. in accordance with key lifetime best practices.
For rxgk, the file server key can then be derived by both client and For rxgk, the file server key can then be derived by both client and
server using server using
random-to-key(PRF+(K0, K, nonce1 || nonce2)); random-to-key(PRF+(K0, K,
pepper || 00 || nonce1 || nonce2 || enctype));
random-to-key is the function specified by the RFC3961 profile of the random-to-key is the function specified by the RFC3961 profile of the
encryption type chosen by the server and returned in enctype. encryption type chosen by the server and returned in enctype.
PRF+ is the function of that name specified by [RFC4402]. PRF+ is the function of that name specified by [RFC4402].
[[The PRF+ function defined in RFC 4402 specifies that the values of [[The PRF+ function defined in RFC 4402 specifies that the values of
the counter 'n' should begin at 1, for T1, T2, ... Tn. However, the counter 'n' should begin at 1, for T1, T2, ... Tn. However,
implementations of that PRF+ function for the gss_pseudo_random() implementations of that PRF+ function for the gss_pseudo_random()
implementation for the krb5 mechanism have disregarded that implementation for the krb5 mechanism have disregarded that
skipping to change at page 16, line 49 skipping to change at page 18, line 4
[[The PRF+ function defined in RFC 4402 specifies that the values of [[The PRF+ function defined in RFC 4402 specifies that the values of
the counter 'n' should begin at 1, for T1, T2, ... Tn. However, the counter 'n' should begin at 1, for T1, T2, ... Tn. However,
implementations of that PRF+ function for the gss_pseudo_random() implementations of that PRF+ function for the gss_pseudo_random()
implementation for the krb5 mechanism have disregarded that implementation for the krb5 mechanism have disregarded that
specification and started the counter 'n' from 0. Since there is no specification and started the counter 'n' from 0. Since there is no
interoperability concern between krb5 gss_pseudo_random() and rxgk interoperability concern between krb5 gss_pseudo_random() and rxgk
key derivation, implementations of the RFC 4402 PRF+ function for key derivation, implementations of the RFC 4402 PRF+ function for
rxgk key derivation should use the RFC 4402 version as specified, rxgk key derivation should use the RFC 4402 version as specified,
that is, with the counter 'n' beginning at 1.]] that is, with the counter 'n' beginning at 1.]]
K0 is the master key of the current rxgk session, e.g., as originally K0 is the master key of the current rxgk session, e.g., as originally
determined by the GSSNegotiate call. determined by the GSSNegotiate call.
K is the key generation seed length as specified in enctype's RFC3961 K is the key generation seed length as specified in enctype's RFC3961
profile. profile.
pepper is the ASCII string "RXGKRegisterAddrsAndKey" (without
trailing NUL).
00 is a NUL octet.
enctype is the selected enctype, encoded as a 32-bit integer in
network byte order.
|| is the concatenation operation. || is the concatenation operation.
11. Securing the Callback Channel 11. Securing the Callback Channel
AFS has traditionally had an unprotected callback channel. However, AFS has traditionally had an unprotected callback channel. However,
extended callbacks [I-D.benjamin-extendedcallbackinfo] require a extended callbacks [I-D.benjamin-extendedcallbackinfo] require a
mechanism for ensuring that callback breaks and, critically, data mechanism for ensuring that callback breaks and, critically, data
updates, are protected. This requires that there is a strong updates, are protected. This requires that there is a strong
connection between the key material used initially to perform the connection between the key material used initially to perform the
RPC, and that which is used to protect any resulting callback. We RPC, and that which is used to protect any resulting callback. We
skipping to change at page 17, line 44 skipping to change at page 19, line 6
It may be reasonable for a cache manager to only ever use one key for It may be reasonable for a cache manager to only ever use one key for
secure callbacks (until the cache manager is restarted), such as in a secure callbacks (until the cache manager is restarted), such as in a
cell where all fileservers have the cell-wide shared key or where all cell where all fileservers have the cell-wide shared key or where all
fileservers are equally trusted. Alternately, a cache manager may fileservers are equally trusted. Alternately, a cache manager may
use just one callback key per fileserver. In either case, which key use just one callback key per fileserver. In either case, which key
to use for incoming callback connections is known just from the to use for incoming callback connections is known just from the
context of the connection, so there is no need to provide a callback context of the connection, so there is no need to provide a callback
token in the authenticator. token in the authenticator.
In all cases, both cache manager and file server must retain the In all cases, both cache manager and file server must retain the
callback key until all callbacks using that key are expired. The key callback key until all callbacks using that key are expired.
should be cached in the server's per-connection private data, to
ensure that the callback key is only used for callbacks created as a
result of calls on the connection to which the key is bound.
Only RPCs issued over an rxgk protected connection should receive Only RPCs issued over an rxgk protected connection should receive
rxgk protected callbacks. rxgk protected callbacks.
12. IANA Considerations 12. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
13. AFS-3 Registry Considerations 13. AFS-3 Registry Considerations
skipping to change at page 19, line 33 skipping to change at page 20, line 38
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
Kerberos V Generic Security Service Application Program Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006. Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011.
Appendix A. Acknowledgements Appendix A. Acknowledgements
rxgk has been the work of many contributors over the years. A rxgk has been the work of many contributors over the years. A
partial list is contained in the [I-D.wilkinson-afs3-rxgk]. All partial list is contained in the [I-D.wilkinson-afs3-rxgk]. All
errors and omissions are, however, mine. errors and omissions are, however, mine.
Appendix B. Changes Appendix B. Changes
B.1. Since 00 B.1. Since 00
Add references to RX and XDR specifications. Add references to RX and XDR specifications.
Add introductory material on AFS. Add introductory material on AFS.
Change expirationTime to be expressed using the rxgkTime type. Change expirationTime to be expressed using the rxgkTime type.
Document how encryption types are chosen for printed tokens, and how Document how encryption types are chosen for printed tokens, and how
they are used against fileservers. they are used against fileservers.
skipping to change at page 21, line 35 skipping to change at page 22, line 47
While here, add the server UUID into the appdata as well as the While here, add the server UUID into the appdata as well as the
client UUID, to prevent some possible routes to data corruption. client UUID, to prevent some possible routes to data corruption.
B.7. Since 06 B.7. Since 06
General edits for clarity. General edits for clarity.
Use afs_uint32 for token lifetimes, to match the core spec. Use afs_uint32 for token lifetimes, to match the core spec.
B.8. Since 07
Incorporate the destination UUID and target enctype into
AFSCombineTokens key generation.
Add (fixed) pepper strings for AFSCombineTokens and
RegisterAddrsAndKey key generation.
General editing for clarity.
Use unsigned types for kvnos.
Use a pointer type for afsUUID RPC arguments.
Authors' Addresses Authors' Addresses
Simon Wilkinson Simon Wilkinson
Your File System Inc Your File System Inc
Email: simon@sxw.org.uk Email: simon@sxw.org.uk
Benjamin Kaduk Benjamin Kaduk
MIT Kerberos Consortium MIT Kerberos Consortium
 End of changes. 41 change blocks. 
85 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/