< draft-wilkinson-afs3-rxgk-10.txt   draft-wilkinson-afs3-rxgk-11.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: July 12, 2014 MIT Expires: September 2, 2014 MIT
January 8, 2014 March 1, 2014
rxgk: GSSAPI based security class for RX rxgk: GSSAPI based security class for RX
draft-wilkinson-afs3-rxgk-10 draft-wilkinson-afs3-rxgk-11
Abstract Abstract
rxgk is a security class for the RX RPC protocol. It uses the GSSAPI rxgk is a security class for the RX RPC protocol. It uses the GSSAPI
framework to provide an authentication service that provides framework to provide an authentication service that provides
authentication, confidentiality and integrity protection for the rxgk authentication, confidentiality and integrity protection for the rxgk
security class. This document provides a general description of rxgk security class. This document provides a general description of rxgk
and how to integrate it into generic RX applications. Application and how to integrate it into generic RX applications. Application
specific behaviour will be described, as necessary, in future specific behaviour will be described, as necessary, in future
documents. documents.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 12, 2014. This Internet-Draft will expire on September 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Key Combination Algorithm . . . . . . . . . . . . . . . . 14 7.2. Key Combination Algorithm . . . . . . . . . . . . . . . . 14
7.3. RPC Definition . . . . . . . . . . . . . . . . . . . . . 14 7.3. RPC Definition . . . . . . . . . . . . . . . . . . . . . 14
7.4. Server Operation . . . . . . . . . . . . . . . . . . . . 14 7.4. Server Operation . . . . . . . . . . . . . . . . . . . . 14
7.5. Client Operation . . . . . . . . . . . . . . . . . . . . 15 7.5. Client Operation . . . . . . . . . . . . . . . . . . . . 15
8. The rxgk Security Class . . . . . . . . . . . . . . . . . . . 15 8. The rxgk Security Class . . . . . . . . . . . . . . . . . . . 15
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17 8.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17
8.4. The Challenge . . . . . . . . . . . . . . . . . . . . . . 17 8.4. The Challenge . . . . . . . . . . . . . . . . . . . . . . 17
8.5. The Response . . . . . . . . . . . . . . . . . . . . . . 17 8.5. The Response . . . . . . . . . . . . . . . . . . . . . . 18
8.5.1. The Authenticator . . . . . . . . . . . . . . . . . . 18 8.5.1. The Authenticator . . . . . . . . . . . . . . . . . . 18
8.6. Checking the Response . . . . . . . . . . . . . . . . . . 18 8.6. Checking the Response . . . . . . . . . . . . . . . . . . 19
8.7. Packet Handling . . . . . . . . . . . . . . . . . . . . . 19 8.7. Packet Handling . . . . . . . . . . . . . . . . . . . . . 19
8.7.1. Authentication Only . . . . . . . . . . . . . . . . . 19 8.7.1. Authentication Only . . . . . . . . . . . . . . . . . 19
8.7.2. Integrity Protection . . . . . . . . . . . . . . . . 19 8.7.2. Integrity Protection . . . . . . . . . . . . . . . . 19
8.7.3. Encryption . . . . . . . . . . . . . . . . . . . . . 21 8.7.3. Encryption . . . . . . . . . . . . . . . . . . . . . 21
9. RXGK protocol error codes . . . . . . . . . . . . . . . . . . 21 9. RXGK protocol error codes . . . . . . . . . . . . . . . . . . 21
10. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 23 10. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.1. Abort Packets . . . . . . . . . . . . . . . . . . . . . 24 12.1. Abort Packets . . . . . . . . . . . . . . . . . . . . . 24
12.2. Token Expiry . . . . . . . . . . . . . . . . . . . . . . 24 12.2. Token Expiry . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 17, line 18 skipping to change at page 17, line 18
each connection has its own transport key, TK, which is derived from each connection has its own transport key, TK, which is derived from
the master key, K0. Derivation is performed using the PRF+ function the master key, K0. Derivation is performed using the PRF+ function
defined in [RFC4402], combined with the random-to-key function of defined in [RFC4402], combined with the random-to-key function of
K0's encryption type, as defined in RFC3961. The PRF input data is K0's encryption type, as defined in RFC3961. The PRF input data is
the concatenation of the rx epoch, connection ID, start_time and key the concatenation of the rx epoch, connection ID, start_time and key
number, all in network byte order. This gives: number, all in network byte order. This gives:
TK = random-to-key(PRF+(K0, L, TK = random-to-key(PRF+(K0, L,
epoch || cid || start_time || key_number)) epoch || cid || start_time || key_number))
[[The PRF+ function defined in RFC 4402 specifies that the values of
the counter 'n' should begin at 1, for T1, T2, ... Tn. However,
implementations of that PRF+ function for the gss_pseudo_random()
implementation for the krb5 mechanism have disregarded that
specification and started the counter 'n' from 0. Since there is no
interoperability concern between krb5 gss_pseudo_random() and rxgk
key derivation, implementations of the RFC 4402 PRF+ function for
rxgk key derivation should use the RFC 4402 version as specified,
that is, with the counter 'n' beginning at 1.]]
L is the key generation seed length as specified in the RFC3961 L is the key generation seed length as specified in the RFC3961
profile. profile.
epoch, cid and key_number are passed as 32 bit quantities; start_time epoch, cid and key_number are passed as 32 bit quantities; start_time
is a 64 bit value. is a 64 bit value.
Note that start_time is selected by the client when it creates the Note that start_time is selected by the client when it creates the
connection, and shared with the server as part of its response. Thus connection, and shared with the server as part of its response. Thus
both sides of the negotiation are guaranteed to use the same value both sides of the negotiation are guaranteed to use the same value
for start_time. for start_time.
 End of changes. 6 change blocks. 
6 lines changed or deleted 16 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/