| Network Working Group | S. Wilkinson |
| Internet-Draft | YFS |
| Intended status: Informational | B. Kaduk |
| Expires: February 17, 2014 | MIT |
| August 16, 2013 |
Integrating rxgk with AFS
draft-wilkinson-afs3-rxgk-afs-03
This document describes how the new GSSAPI-based rxgk security class for RX is integrated with the AFS application protocol. It describes a number of extensions to the basic rxgk protocol, clarifies a number of implementation issues, and provides values for the application-specific elements of rxgk.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 17, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
rxgk [I-D.wilkinson-afs3-rxgk] is a new GSSAPI-based [RFC2743] security layer for the RX [RX] remote procedure call system. The rxgk specification details how it may be used with a generic RX application. This document provides additional detail specific to integrating rxgk with the AFS-3 distributed file system.
AFS-3 is a global distributed network file system. The system is split into a number of cells, with a cell being the administrative boundary. Typically an organisation will have one (or more) cells, but a cell will not span organisations. Each cell contains a number of fileservers which contain collections of files ("volumes") which they make available to clients using the AFS-3 protocol. Clients access these files using a service known as the cache manager.
In order to determine which server a particular file is located upon, the cache manager looks up the location in the volume location database (vldb) by contacting the vlserver. Each cell has one or more vlservers, which are synchronised using an out-of-band mechanism.
This document describes special integration steps needed to use rxgk with AFS-3 database servers (the PR and VL rx services) and file servers (the RXAFS, RXAFSCB, and AFSVol rx services), as well as specifying application-specific portions of the rxgk specification for use by these services. Other AFS-3 services are not covered by this document; the generic rxgk document applies to them. AFS-3 differs from the standard rxgk implementation in that it does not require GSSAPI negotiation with each server. Instead, a client performs GSSAPI negotiation just once (with the vlserver), receiving a token usable with any server in the cell that has the cell-wide key. Traditional AFS rxkad authentication required that the cell-wide key be distributed to all servers in the cell, both database servers and file servers. rxgk can operate in such a fashion, with the cell-wide key shared amongst all servers.
For more complex cell topologies, rxgk also supports configurations where (some) file servers do not have the cell-wide key, by means of an extended version of the CombineTokens RPC. This new RPC, AFSCombineTokens, takes a server identifier, and will return a token encrypted with a key for a specific server. AFSCombineTokens also provides support for indicating whether a specific server is rxgk capable, allowing cells to securely migrate to rxgk from other security mechanisms.
We also define mechanisms for securing the callback channel that is created between fileserver and client.
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 RFC 2119 [RFC2119].
When used within the AFS protocol, rxgk has an RX securityIndex value of 4.
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 vlservers. The service MUST listen on the same port as the vlserver.
The GSS identity afs-rxgk@_afs.<cellname> of nametype GSS_C_NT_HOSTBASED_SERVICE is the acceptor identity for this service. Where multiple vlservers exist for a single cell, all of these servers must have access to the key material for this identity, which MUST be identical across the cell. Clients MAY use the presence of this identity as an indicator of rxgk support for a particular cell. Clients that wish to support cells using other rx security objects MAY downgrade if this identity is not available.
Tokens returned from the GSSNegotiate call MUST only be used with database servers. Tokens for fileservers MUST be obtained by calling AFSCombineTokens before each server is contacted.
AFSCombineTokens(IN RXGK_Data *token0,
IN RXGK_Data *token1,
IN RXGK_CombineOptions *options,
IN afsUUID destination,
OUT RXGK_Data *new_token,
OUT RXGK_TokenInfo *token_info) = 3;
AFS extends the existing CombineTokens operation to provide a general token manipulation service. This operation takes a user token, an optional cache manager token, options for enctype and security level negotiation with the server, and a destination identifier. It returns a token specific to the specified destination, and a structure containing some cleartext information describing the returned token.
The AFSCombineTokens call MUST only be performed over a secured rxgk connection. AFSCombineTokens MUST NOT be offered over an RXGK_LEVEL_CLEAR connection. Servers MUST reject all attempts to perform this operation over channels that do not offer integrity protection.
Clients which are caching the results of RPCs on behalf of multiple users (such as a traditional AFS Cache Manager), SHOULD provide both the user's token (as token0) and a token generated from an identity that is private to the cache manager (as token1). This prevents a user from poisoning the cache for other users. Recommendations on keying cache managers are contained in Section 6.1.
Clients which are working on behalf of a single user can provide an empty token1, but MUST use AFSCombineTokens to obtain a destination specific token for each fileserver they contact.
Clients using a printed token (see Section 7.1) MUST provide that token as token0. token1 MUST be empty. Printed tokens cannot be combined with any other token, and servers MUST reject attempts to do so.
If the server is unable to perform the AFSCombineTokens operation with the given arguments, a nonzero value is returned. Clients MUST NOT use such an error as an indication to fall back to to a different security class.
If the returned token is zero-length, then the destination does not support rxgk, and the client MAY fall back to using a different authentication mechanism for that server. An rxgk capable client operating within an rxgk enabled cell MUST NOT downgrade its choice of security layer in any other situation.
Other aspects of the operation of AFSCombineTokens, including the combination of keys and tokens, are the same as the CombineTokens RPC, documented in CombineTokens call, documented in [I-D.wilkinson-afs3-rxgk].
struct RXGK_TokenContainer {
afs_int32 kvno;
afs_int32 enctype;
opaque encrypted_token<>;
};
rxgk tokens for AFS take the form of some key management data, followed by an encrypted data blob. The key management data (a version number, followed by an [RFC3961] encryption type) allows the server receiving a token to identify which pre-shared key has been used to encrypt the core token data. [I-D.wilkinson-afs3-rxgk].
Token contents are encrypted using a pre-shared key. rxgk supports both the use of a single cell-wide key and the use of per-server keys. The cell-wide key must be installed on all servers which are capable of accepting cell-wide tokens. Cell-wide keys should be for a selected RFC3961 encryption mechanism that is supported by all servers within the cell that will accept cell-wide tokens. Per-server keys should be for an encryption mechanism that is supported by both the destination server and the negotiation service. The management of per-server keys is discussed in more detail in Section 13.2.
Key rollover is permitted by means of a key version number. When the key is changed, a different key version number MUST be selected. Servers SHOULD accept tokens using old keys until the lifetime of all existing tokens has elapsed.
Encryption is performed over the XDR encoded RXGK_Token structure, using the RFC3961 encrypt operation, with a key usage value of RXGK_SERVER_ENC_TOKEN (defined in [I-D.wilkinson-afs3-rxgk]). The enrypted data is stored in the encryted_token field of the TokenContainer structure described in Section 4.1.
struct RXGK_Token {
afs_int32 enctype;
opaque K0<>;
RXGK_Level level;
rxgkTime start_time;
afs_int32 lifetime;
afs_int32 bytelife;
rxgkTime expirationtime;
struct PrAuthName identities<>;
};
The token itself contains the information expressed by the following RPC-L:
struct RXGK_Authenticator_AFSAppData {
afsUUID uuid;
};
The appdata opaque within the RXGK_Authenticator structure contains the results of XDR encoding the RXGK_Authenticator_AFSAppData structure. The uuid field contains the UUID of the client.
In order to protect users of a multi-user cache manager from each other, it must be impossible for an individual user to determine the key used to protect operations which affect the cache. This requires that the cache manager have key material of its own which can be combined with that of the user. This functionality is provided by the AFSCombineTokens call specified earlier in this document. However, this call requires that a cache manager have access to a token for this purpose.
When a host already has key material for a GSSAPI mechanism supported by rxgk, that material MAY be used to key the client. The client simply calls the rxgk negotiation service using the relevant material, and obtains a token. The client SHOULD frequently regenerate this token, to avoid combined tokens having unnecessarily close expiration times. The client SHOULD NOT regenerate this token so often so as to place excessive load on the vlservers.
It is recommended that identities created specifically for use by a cache manager have the name afs3-callback@<hostname> where <hostname> is the fully qualified domain name of the cache manager.
When a client has no key material, it is possible that an anonymous GSSAPI connection may succeed. Clients MAY attempt to negotiate such a connection by calling GSS_Init_sec_context() with the anon_req_flag [RFC2743] and the default credentials set.
A number of portions of the AFS protocol require that servers communicate amongst themselves. To secure this with rxgk we require both a mechanism of generating tokens for these servers to use, and a definition of which identities are permitted for authorisation purposes. We refer to the process of forging tokens for local use, given access to the cell-wide pre-shared key, as "token printing".
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 construct a token with suitable values. The list of identities in such a token MUST be empty. It can then encrypt this token using the pre-shared key, and use it in the same way as a normal rxgk token. The receiving server can identify it is a printed token by the empty identity list.
The session key within a printed token MUST use the same encryption type as the pre-shared key. When connecting to a fileserver, a client SHOULD use the AFSCombineTokens service as discussed above to ensure that they are using the correct key for the fileserver.
The AFSCombineTokens call has specific behaviour when a destination endpoint does not support rxgk. Implementing this behaviour requires that the vlserver be aware of whether a fileserver supports rxgk.
Fileservers currently register with the vlserver using the VL_RegisterAddrs RPC. Fileservers which support rxgk MUST call this RPC over a rxgk protected connection. The vlserver then infers rxgk support from the rx security layer used in registration. To prevent downgrade attacks, once a fileserver has registered as being rxgk capable, the vlserver MUST NOT remove that registration without administrator intervention.
Once a fileserver has been marked as supporting rxgk, VL_RegisterAddrs calls for that fileserver MUST only be accepted over an rxgk protected connection. vlservers MUST only accept calls to VL_RegisterAddrs from a printed token, an administrator, or the identity registered for the fileserver using a prior call to VL_RegisterAddrsandKey.
The provisioning of servers with their own keys, rather than the cell-wide master key, requires the ability to maintain a directory of these keys on the vlserver, so that the AFSCombineTokens RPC can encrypt the outgoing token with the correct key. The manner in which this directory is maintained is left to the implementor, who MAY decide to use a manual, or out of band, key management system. Otherwise, the automated keying mechanism described as follows will be used.
Implementations supporting automatic key management through the AFS-3 protocol MUST provide the VL_RegisterAddrsAndKey RPC (similar to the VL_RegisterAddrs RPC). This RPC is called by a fileserver to register itself with the VLDB; it MUST be called over a secure connection. In particular, it MUST NOT be called over an rxkad connection.
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 RPC call can generate a key to be used as the fileserver's long-term server key.
vlservers MUST NOT permit calls to VL_RegisterAddrsAndKey for UUIDs which already exist within the vldb, unless that UUID already has a server-specific key registered. When a new fileserver first registers with the vldb using VL_RegisterAddrsAndKey, the vlserver MUST store the identity used to make this connection. The vlserver MUST only permit subsequent calls to VL_RegisterAddrsAndKey for this UUID when they come from this identity, an administrator, or a printed token. New fileserver UUIDs register themselves with the vldb in a "leap of faith", binding a GSSAPI identity to the fileserver UUID for future authenticated operations. Fileservers SHOULD use VL_RegisterAddrsAndKey to rekey themselves periodically, in accordance with key lifetime best practices.
struct RXGK_ServerKeyDataRequest {
afs_int32 enctypes<>;
opaque nonce1[20];
};
struct RXGK_ServerKeyDataResponse {
afs_int32 enctype;
afs_int32 kvno;
opaque nonce2[20];
};
typedef opaque keyDataRequest<>;
typedef opaque keyDataResponse<>;
VL_RegisterAddrsAndKey(
IN afsUUID *uuidp,
IN afs_int32 spare1,
IN bulkaddrs *ipaddr,
IN afs_int32 secIndex,
IN keyDataRequest *request,
OUT keyDataResponse *response) = XXX;
The VL_RegisterAddrsAndKey RPC is described by the following RPC-L:
The client provides, in the RXGK_ServerKeyDataRequest structure, a list of the RFC3961 encryption types that it will accept as a server key. It also provides a nonce containing 20 random data bytes.
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 generated, in RXGK_ServerKeyDataResponse. If there is no common encryption type, then the server MUST fail the request.
random-to-key(PRF+(K0, K, nonce1 || nonce2));
The server key can then be derived by both client and server using
random-to-key is the function specified by the RFC3961 profile of the encryption type chosen by the server and returned in enctype.
PRF+ is the function of that name specified by [RFC4402].
K0 is the master key of the current rxgk session, as originally determined by the GSSNegotiate call.
K is the key generation seed length as specified in enctype's RFC3961 profile.
|| is the concatenation operation.
AFS has traditionally had an unprotected callback channel. However, extended callbacks [I-D.benjamin-extendedcallbackinfo] require a mechanism for ensuring that callback breaks and, critically, data updates, are protected. This requires that there is a strong connection between the key material used initially to perform the RPC, and that which is used to protect any resulting callback. We achieve this using the cache manager token discussed in Section 6.1, which is required in order for a client to accept secure callbacks.
RXAFS_SetCallBackKey(afs_int32 securityIndex,
opaque mech_data<>) = XXX;
struct RXGK_CallBackKeyData {
afs_int32 enctype;
opaque K0<1024>;
RXGK_Level level;
/* no rxgkTime start_time */
afs_int32 lifetime;
afs_int32 bytelife;
/* no rxgkTime expirationtime */
RXGK_Data token;
/* no identities needed */
}
A cache manager may set a key for secure callbacks by issuing the following RPC (in the RXAFS service):
No expiration or start time need be transferred in this RPC (as are included in an RXGK_Token and RXGK_ClientInfo), because the callback connection is implicitly authorized to continue for as long as the client is interested in data from the fileserver.
The RXAFS_SetCallBackKey RPC must be performed over a secure channel. When used to set callback keys for rxgk, this means that the RPC MUST be performed over an rxgk protected connection of security level RXGK_LEVEL_CRYPT. Additionally, the connection MUST have been established using solely the cache manager's token.
The callback channel key is inherently tied to the identity of the cache manager token used to establish it. A fileserver which is providing secure callbacks MUST store the cache manager identity used to establish each callback connection key and associate that identity with the cache manager UUID. A cache manager may make multiple calls to RXAFS_SetCallBackKey, and the fileserver MAY store multiple cache manager identity/callback connection key pairs for a given cache manager UUID. If a fileserver receives an RXAFS_SetCallBackKey call which will cause it to stop storing an identity/key pair (whether because the fileserver only stores one such pair for a given cache manager, or some larger fixed limit is reached), it MUST break all secure callbacks held by that client that are using the old key before the RPC terminates.
Only RPCs issued over an rxgk protected connection should receive rxgk protected callbacks.
The callback connection key is tied to the cache manager identity, and as such, should only be used to protect callbacks relating to data accessed using that identity, whether by itself or as part of a combined token. The fileserver MUST only send rxgk protected callbacks when one of the identities performing the RPC establishing that callback matches the identity associated with that clients callback channel.
This memo includes no request to IANA.
This document requrests that the AFS-3 registry allocate code points for the new RPCs AFSCombineTokens (for the RXGK service), RegisterAddrsAndKey (for the VL service), and SetCallBackKey (for the RXAFS service).
Using the presence of a GSSAPI key to determine a cell's ability to perform rxgk is vulnerable to a downgrade attack, as an attacker may forge error responses. Cells which no longer support rxkad should remove their afs@REALM and afs/cell@REALM Kerberos keys.
The mechanism for automatically registering per-server keys is potentially vulnerable, as it trades a short-lived key (the rxgk session key, which protects the key exchange) for a long-lived one (the server key). There is precedent for this sort of key exchange, such as when using kadmin to extract a new kerberos keytab.
As described in Section 6, combined tokens are used to prevent cache poisoning attacks on multi-user systems. In order for this protection to be effective, cache managers MUST NOT provide user access to keys produced through the combine tokens operation, unless those keys will not be used by the cache manger itself.
| [RX] | Zeldovich, N., "RX protocol specification", October 2002. |
| [I-D.benjamin-extendedcallbackinfo] | Benjamin, M., "AFS Callback Extensions (Draft 14)", Internet-Draft draft-benjamin-extendedcallbackinfo-02, December 2011. |
| [I-D.brashear-afs3-pts-extended-names] | Brashear, D., "Authentication Name Mapping extension for AFS-3 Protection Service", Internet-Draft draft-brashear-afs3-pts-extended-names-09, March 2011. |
| [I-D.wilkinson-afs3-rxgk] | Wilkinson, S., "rxgk: GSSAPI based security class for RX", Internet-Draft draft-wilkinson-afs3-rxgk-00, January 2010. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2743] | Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. |
| [RFC3961] | Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. |
| [RFC4402] | Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006. |
| [RFC4506] | Eisler, M., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006. |
rxgk has been the work of many contributors over the years. A partial list is contained in the [I-D.wilkinson-afs3-rxgk]. All errors and omissions are, however, mine.
Add references to RX and XDR specifications.
Add introductory material on AFS.
Change expirationTime to be expressed using the rxgkTime type.
Document how encryption types are chosen for printed tokens, and how they are used against fileservers.
Expand security considerations section to cover combined tokens.
Rename AFS_SetCallbackKey as RXAFS_SetCallbackKey.
Rename RXAFS_SetCallbackKey to RXAFS_SetCallBackKey.
Add an AFS-3 Registry Considerations section.
Clarify the vlserver/dbserver/fileserver relationship.
AFSCombineTokens prototype changes.
Clarify the scope of the document.
Use a leap of faith for RegisterAddrsAndKey.
Specify the nametype of the acceptor identity.
Deal with fallout of errorcode's removal from RXGK_TokenInfo.
Rework "securing the callback channel".