Network Working Group Wilkinson
Internet-Draft YFS
Intended status: Informational January 9, 2010
Expires: July 13, 2010
rxgk: GSSAPI based security class for RX
draft-wilkinson-afs3-rxgk-00
Abstract
rxgk is a security class for the RX RPC protocol. It uses the GSSAPI
framework to provide authentication, confidentiality and integrity
protection. This document provides a general description of rxgk. A
further document will provide details of integration with specific RX
applications.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 13, 2010.
Copyright Notice
Copyright (c) 2010 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
Wilkinson Expires July 13, 2010 [Page 1]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Encryption framework . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key usage values . . . . . . . . . . . . . . . . . . . . . 3
3. Security Levels . . . . . . . . . . . . . . . . . . . . . . . 4
4. Token Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Key negotiation . . . . . . . . . . . . . . . . . . . . . . . 5
6. The combine tokens operation . . . . . . . . . . . . . . . . . 8
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Key combination algorithm . . . . . . . . . . . . . . . . 9
6.3. RPC definition . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Server operation . . . . . . . . . . . . . . . . . . . . . 9
6.5. Client operation . . . . . . . . . . . . . . . . . . . . . 9
7. The rxgk security class . . . . . . . . . . . . . . . . . . . 10
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Key derivation . . . . . . . . . . . . . . . . . . . . . . 10
7.4. The Challenge . . . . . . . . . . . . . . . . . . . . . . 11
7.5. The Response . . . . . . . . . . . . . . . . . . . . . . . 11
7.5.1. The Authenticator . . . . . . . . . . . . . . . . . . 12
7.6. Checking the Reponse . . . . . . . . . . . . . . . . . . . 12
7.7. Packet handling . . . . . . . . . . . . . . . . . . . . . 12
7.7.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
7.7.2. Integrity protection . . . . . . . . . . . . . . . . . 13
7.7.3. Authentication only . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Abort Packets . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Wilkinson Expires July 13, 2010 [Page 2]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
1. Introduction
rxgk is a GSSAPI [RFC2743] based security class for the rx protocol.
It provides authentication, confidentiality and integrity protection
for rx RPC calls, using a security context established using any
GSSAPI mechanism with PRF [RFC4401] support.
Architecturally, rxgk is split into two parts. The rxgk rx security
class provides strong encryption using previously negotiated ciphers
and keys. It builds on the Kerberos crypto framework for its
encryption requirements, but is authentication mechanism independent
- the class itself does not require the use of either Kerberos, or
GSSAPI. The security class simply uses a previously negotiated
encryption type, and master key. The master key is never directly
used, but instead a per connection key is derived for each new secure
connection that is established.
The second portion of rxgk is a service which permits the negotiation
of an encryption algorithm, and the establishment of a master key.
This is done via a separate RPC exchange with a server, prior to the
setup of any rxgk connections. The exchange establishes an rxgk
token, and a master key shared between client and server. This
exchange is protected within a GSSAPI security context.
1.1. Requirements Language
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].
2. Encryption framework
Bulk data encryption within rxgk is performed using the encryption
framework defined by RFC3961 [RFC3961]. Any algorithm which is
defined using this framework and supported by both client and server
may be used.
2.1. Key usage values
In order to avoid using the same key for multiple tasks, key
derivation is employed. The following key usage values are used by
rxgk, their functions are as defined later in this document.
Wilkinson Expires July 13, 2010 [Page 3]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
const RXGK_CLIENT_ENC_PACKET = 1026;
const RXGK_CLIENT_MIC_PACKET = 1027;
const RXGK_SERVER_ENC_PACKET = 1028;
const RXGK_SERVER_MIC_PACKET = 1029;
const RXGK_CLIENT_ENC_RESPONSE = 1030;
const RXGK_CLIENT_COMBINE_ORIG = 1032;
const RXGK_SERVER_COMBINE_NEW = 1034;
const RXGK_SERVER_ENC_TICKET = 1036;
3. Security Levels
rxgk supports the negotiation of a range of different security
levels. These, along with the protocol constant that represents them
during key negotiation, are:
Authentication only (0) Provides only connection authentication,
without either integrity or confidentiality protection. This
mode of operation provides higher throughput, but is vulnerable
to man in the middle attacks. This corresponds to the
traditional 'clear' security level
Integrity (1) Provides integrity protection only. Data is protected
from modification by an attacker, but not against
eavesdropping. This corresponds to the tranditional 'auth'
level.
Encryption (2) Provides both integrity and confidentiality
protection, corresponding to 'crypt'
Bind (3) Connection security is provided by channel bindings with
another layer. This mode of operation is experimental, and
this value is reserved for future expansion.
4. Token Format
An rxgk token is an opaque identifier which is specific to an
particular application's implementation of rxgk. The token is
completely opaque to the client, which just transmits it from server
to server. The token must permit the receiving server to identify
the corresponding user and session key for the incoming connection -
whether that be by encrypting the information within the token, or
making the token a large random identifier which keys a lookup hash
table on the server.
The token MUST NOT expose the session key on the wire. It MUST be
sufficiently random that an attacker cannot predict suitable token
Wilkinson Expires July 13, 2010 [Page 4]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
values by observing other connections. An attacker MUST NOT be able
to forge tokens which convey a particular session key or identity.
5. Key negotiation
rxgk uses an independent RX RPC service for key negotiation. The
location of this service is application dependent. Within a given
application protocol, a client must be able to locate the key
negotiation service, and that service must be able to create tokens
which can be read by the application server. The simplest deployment
has the service running on every server, on the same transport
endpoints, but using a separate, dedicated, rx service id.
The key negotiation RPC is defined by the following XDR
typedef afs_int32 RXGK_Enctypes<>;
struct RXGK_StartParams {
RXGK_Enctypes enctypes;
afs_int32 levels<>;
afs_int32 lifetime;
afs_int32 bytelife;
opaque client_nonce<>;
};
struct RXGK_ClientInfo {
afs_int32 errorcode;
afs_int32 flags;
afs_int32 enctype;
afs_int32 level;
afs_int32 lifetime;
afs_int32 bytelife;
afs_int64 expiration;
opaque mic<>;
RXGK_Ticket_Crypt ticket;
opaque server_nonce<>;
};
package RXGK_
GSSNegotiate(IN RXGK_StartParams *client_start,
IN RXGK_Token *input_token_buffer,
IN RXGK_Token *opaque_in,
OUT RXGK_Token *output_token_buffer,
OUT RXGK_Token *opaque_out,
OUT afs_uint32 *gss_status,
OUT RXGK_Token *rxgk_info) = 1;
Wilkinson Expires July 13, 2010 [Page 5]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
The client populates RXGK_StartParams with lists of its prefered
options. These should be ordered from best to worst, with the
clients favoured option occuring first within the list. The
parameters are:
enctypes: List of encryption types from the Kerberos Encryption Type
Number registry created in RFC3961 and maintained by IANA.
This list indicates the encryption types that the client is
prepared to support.
levels: List of supported rxgk transport encryption levels.
lifetime: The maximum lifetime of the negotiated key, in seconds.
bytelife: The maximum amount of data that the negotiated key should
encrypt before being discared, expressed as log 2 of the number
of bytes. A value of 0 indicates that there is no limit on the
number of bytes that may be transmitted. The byte lifetime is
advisory - a connection that is over its byte lifetime should
be permitted to continue, but clients should attempt to
establish a new context at their earliest convenience.
clientnonce: A client generated string of random bytes, to be used
as input to the key generation.
The client then calls gss_init_sec_context() to obtain an output
token to send to the server. The GSS service name is application
dependent.
The client then calls RXGK_GSSNegotiate, as defined above. This
takes the following parameters
clientparms The client params structure detailed above. This should
remain constant across the negotiation
input_token_buffer The token produced by a call to
gss_init_sec_context
opaque_in An opaque token, which was returned by the server
following a previous call to GSSNegotiate in this negotiation.
If this is the first call, this should be NULL.
output_token_buffer The token output by the server's call to
gss_accept_sec_context
Wilkinson Expires July 13, 2010 [Page 6]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
opaque_out An opaque token, which the server may use to preserve
state information between multiple calls in the same context
negotiate. The client should use this value as opaque_in in
its next call to GSSNegotiate.
gss_status The major status code output by the server's call to
gss_accept_sec_context
rxgk_info If gss_status == GSS_S_COMPLETE this contains an encrypted
block containing the server's response to the client. See
below.
Upon receiving the server's response, the client checks the contents
of gss_status. If this is GSS_S_CONTINUE_NEEDED, the client should
call gss_init_sec_context again with the token provided by the server
in output_token_buffer, followed by a further call to GSSNegotiate,
including the server's previous opaque_out as this call's opaque_in
This process continues until the either the server, or client,
encounters an error, or the server returns GSS_S_COMPLETE in
gss_status.
Upon completion, rxgk_info contains the XDR representation of a
RXGK_ClientInfo structure, encrypted using gss_wrap() with
confidentiality protection. The client should decrypt this structure
using gss_unwrap - ClientInfo contains the following server populated
fields
errorcode A policy (rather than connection establishment) error
code. If non-zero, an error has occured, the resulting key
negotiation has failed, and the rest of the values in this
structure are undefined.
flags
enctype The encryption type selected by the server. This will be
one of the types listed by the client in its StartParams
structure
level The rxgk security level selected by the server.
lifetime The connection lifetime, in seconds, as determined by the
server (this must be less than or equal to the lifetime
proposed by the client)
Wilkinson Expires July 13, 2010 [Page 7]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
bytelife The maximum amount of data (in log 2 bytes) that may be
transfered using this key. This must be less than or equal to
the bytelife proposed by the client
expiration The time, in seconds since the Unix epoch, at which this
token expires
mic The result of calling gss_get_mic over the XDR encoded
representation of the StartParams request received by the
server.
token An rxgk token. This is an opaque blob, as detailed earlier
server_nonce The nonce used by the server to create the K0 used
within the rxgk token
Upon receiving the server's response, the client must verify that the
mic contained within it matches the MIC of the XDR representation of
the StartParams structure it sent to the server (this prevents a man
in the middle from performing a downgrade attack). It should also
verify that the server's selected connection properties match those
it proposed.
The client may then compute K0, by taking the nonce it sent to the
server (client_nonce), and the one it has just received
(server_nonce), combining them together, and passsing them to
gss_psuedo_random, with the GSS_C_PRF_KEY_FULL option
gss_pseudo_random(gssapi_context,
GSS_C_PRF_KEY_FULL,
client_nonce || server_nonce,
K,
*K0);
|| is the concatenation operation
K, the desired output length, is the key generation seed length as
specified in the RFC3961 profile of the negotiated enctype
6. The combine tokens operation
6.1. Overview
A client may elect to combine multiple rxgk tokens in its possession
into a single token. This allows an rx connection to be secured
using a combination of multiple, individually established identities,
which provides additional security for a number of application
Wilkinson Expires July 13, 2010 [Page 8]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
protocols.
Token combination is performed using the CombineTokens RPC call. The
client has two keys - K0 and K1, and two tokens, T0 and T1. It
locally combines the two keys using a defined combination alogrithm
to produce Kn. It then calls the CombineTokens RPC with T0 and T1,
to receive a new token, Tn, which has embeded within it Kn, as
computed by the server.
6.2. Key combination algorithm
Assume that the tokens being combined are T0 and T1, with initial
keys K0 and K1. The new initial key for the combined token, Kn is
computed using the KRB-FX-CF2 operation, described in section 6.1 of
draft-ietf-krb-wg-preauth-framework-14
[I-D.ietf-krb-wg-preauth-framework]. The constants pepper1 and
pepper2 required by this operation are defined as the ASCII strings
"AFS" and "rxgk" respectively.
6.3. RPC definition
The combine keys RPC is defined as
CombineTokens(IN opaque token0,
IN opaque token1,
OUT opaque new_token) = 2;
6.4. Server operation
The server receives both token0 and token1 from the RPC call, and
decrypts these tokens using its private key. Providing this
decryption is successful, it now has copies of the initial key (K0)
from both tokens. It then performs the key combination algorithm
detailed above to obtain a new key, Kn. The server constructs a new
token, where each of the numerical fields are set to the minimum of
the values of each of the original tokens, and the list of identities
is the union of those in the original tokens. This new token
contains the derived key, Kn. The new token is encrypted with the
server's private key, as normal, and returned to the client.
6.5. Client operation
As detailed within the overview, the client calls the CombineTokens
RPC using two tokens, T0 and T1 within its posession. It then
receives a new token, Tn from this call. The client can only make
use of Tn to establish an rxgk protected connection if it can derive
Kn, which it can only do if it already knows K0 and K1.
Wilkinson Expires July 13, 2010 [Page 9]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
7. The rxgk security class
7.1. Overview
When a new connection using rxgk is created by the client, it stores
the current timestamp (as start_time for the rest of this
discussion), and then uses this, along with other connection
information, to derive a transport key from the current user's master
key.
This key is then used to protect the first message the client sends
to the server. The server follows the standard RX security
establishment protocol, and responds to the client with a challenge.
rxgk challenges simply contain some versioning information and a
random nonce selected by the server.
Upon receiving this challenge, the client uses the transport key to
encrypt an authenticator, which contains the server's nonce, and some
other connection information. The client sends this authenticator,
together with start_time and the current user's rxgk token, back to
the server.
The server decrypts the rxgk token to determine the master key in
use, uses this to derive the transport key, which it in turn uses to
decrypt the authenticator, and thus validate the connection.
7.2. Rekeying
As part of connection negotiation, the server and client agree upon a
number of advisory lifetimes (both time, and data, based) for
connection keys. Each connection has a key number, which starts at
0. When a connection exceeds one of its lifetimes, either side may
elect to increment the key number. When the other endpoint sees a
key number increment, it should reset all of its connection counters.
Endpoints should accept packets encrypted with either the current,
previous, or next key number, to allow for resends around the
rekeying process.
The key version number is contained within the 16 bit spare field of
the RX header (used by previous security layers as a checksum field),
and expressed as an unsigned value in network byte order. If
rekeying would cause this value to wrap, then the endpoint perform
the rekey must terminate the connection.
7.3. Key derivation
In order to avoid the sharing of keys between multiple connections,
each connection has its own transport key, TK, which is derived from
Wilkinson Expires July 13, 2010 [Page 10]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
the master key, K0. Derivation is performed using the PRF+ function
defined in RFC4402, combined with the random-to-key function of K0's
encryption type, as defined in RFC3961. The PRF input data is the
concantenation of the rx epoch, connection ID, start_time and key
number, all in network byte order. This gives:
TK = random-to-key(PRF+(K0, L,
epoch || cid || start_time || key_number))
L is the key generation seed length as specified in the RFC3961
profile
Note that start_time is selected by the client when it receives the
server's challenge, and shared with the server as part of its
response. Thus both sides of the negotiation are guaranteed to use
the same value for start_time.
7.4. The Challenge
The rxgk challenge is an XDR encoded structure with the following
signature:
struct RXGK_Challenge {
afs_int32 version;
opaque nonce[20];
};
version: The rxgk version number
nonce: 20 octets of random data
A client receiving a challenge containing an unknown version number
MUST reject that challenge.
7.5. The Response
The rxgk response is an XDR encoded structure, with the following
signature:
struct RXGK_Response {
afs_int32 version;
afs_int64 start_time;
opaque token<>
opaque authenticator<>
};
Wilkinson Expires July 13, 2010 [Page 11]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
version: the rxgk version number
start_time: the number of seconds since the Unix epoch (1970-1-1 00:
00:00Z)
authenticator: the XDR encoded representation of RXGK_Authenticator,
encrypted with the transport key, and key usage
RXGK_CLIENT_ENC_RESPONSE.
7.5.1. The Authenticator
struct RXGK_Authenticator {
opaque nonce[20];
opaque appdata<>
afs_uint32 epoch;
afs_uint32 cid;
afs_int32 maxcalls;
afs_int32 call_numbers<>;
};
nonce: a copy of the nonce from the challenge
appdata: an application specific opaque blob
epoch: the rx connection epoch
cid: the rx connection ID
maxcalls: the highest rx call number in use
call_numbers: the set of current rx call numbers
7.6. Checking the Reponse
To check the validity of an rxgk response, the authenticator should
be decrypted, the nonce compared with that sent in the challenge, and
the connection ID and epoch compared with that of the current
connection. Failure of any of these steps MUST result in the failure
of the security context.
7.7. Packet handling
The way in which the rxgk security class handles packets depends upon
the requested security level. As noted earlier, 3 levels are
currently defined - authentication only, integrity protection and
encryption
Wilkinson Expires July 13, 2010 [Page 12]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
7.7.1. Encryption
Using the encryption security level provides both integrity and
confidentiality protection.
The existing payload is prefixed with a psuedo header, to produce the
following data for encryption.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| call number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| security index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-+-
This plaintext is encrypted using an RFC3961 style encrypt()
function, with the connection's transport key, using key usage
RXGK_CLIENT_ENC_PACKET for messages from client to server, and
RXGK_SERVER_ENC_PACKET for messages from server to client, and the
encrypted block transmitted to the peer.
7.7.2. Integrity protection
The rxgk_auth security level prepends the packet with the same data
block as crypt (as detailed above), and then calls the RFC3961
get_mic operation over the result, using key usage
RXGK_CLIENT_MIC_PACKET for messages from client to server, and
RXGK_SERVER_MIC_PACKET for messages from server to client.
The peer is sent the output from the MIC operation, followed by the
original payload (excluding the additional header which was added for
the MIC step).
Upon receiving a protected packet, the receiver should consult the
RFC3961 profile for the encryption algorithm in use to determine how
many bytes of checksum are contained within the packet. Having split
the data into checksum and payload using this information, the
checksum should be verified using the encryption profile's
verify_mic() operation with the appropriate key derivation.
Wilkinson Expires July 13, 2010 [Page 13]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
Note that the checksum field within the rx packet header itself is
not used, as it is too small to hold a collision proof checksum
value.
7.7.3. Authentication only
When running at the rxgk_clear level, no manipulation of the payload
is performed by the security class.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
9.1. Abort Packets
RX Abort packets are not protected by the security layer. Therefore
caution should be exercised when relying on their results. In
particular, clients MUST NOT use an error from GSSNegotiate or
CombineTokens to determine whether to downgrade to another security
class
10. Normative References
[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.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006.
[I-D.ietf-krb-wg-preauth-framework]
Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication",
draft-ietf-krb-wg-preauth-framework-15 (work in progress),
October 2009.
Wilkinson Expires July 13, 2010 [Page 14]
Internet-Draft rxgk: GSSAPI based security class for RX January 2010
Appendix A. Acknowledgements
rxgk was originally developed over a number of AFS Hackathons. The
editor of this document has assembled the protocol description from a
number of notes taken at these meetings, and from a partial
implementation in the Arla AFS client.
Thanks to Derrick Brashear, Jeffrey Hutzelman, Love Hornquist Astrand
and Chaskiel Grundman for their original design work, and comments on
this document, and apologies for any omissions or misconceptions in
my archaelogical work.
Marcus Watts and Jeffrey Altman provided invaluable feedback on an
earlier version of this document at the 2009 Edinburgh AFS Hackathon.
Author's Address
Simon Wilkinson
Your File System Inc
Email: simon@sxw.org.uk
Wilkinson Expires July 13, 2010 [Page 15]