One document matched: draft-williams-kitten-krb5-extra-rt-01.txt
Differences from draft-williams-kitten-krb5-extra-rt-00.txt
Network Working Group N. Williams
Internet-Draft Cryptonector
Updates: RFC4121 (if approved) R. Dowdeswell
Intended status: Standards Track Dowdeswell Security Architecture
Expires: August 19, 2013 February 15, 2013
Negotiation of Extra Round Trip for Kerberos V5 Generic Security
Services Mechanism
draft-williams-kitten-krb5-extra-rt-01
Abstract
This Internet-Draft proposes an extension to the Kerberos V5 security
mechanism for the Generic Security Services Application Programming
Interface (GSS-API) for using an extra pair of security context
tokens in order to recover from certain errors. Other benefits
include: user2user authentication, authenticated errors (in some
cases), and more.
Status of this Memo
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 August 19, 2013.
Copyright Notice
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. Code Components extracted from this document must
Williams & Dowdeswell Expires August 19, 2013 [Page 1]
Internet-Draft Kerberos Extra AP February 2013
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Use in Non-GSS Applications . . . . . . . . . . . . . . . 6
2.2. Number of Round Trips . . . . . . . . . . . . . . . . . . 6
3. ASN.1 for New Protocol Elements . . . . . . . . . . . . . 7
4. Other Features . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Acceptor Name Redirection . . . . . . . . . . . . . . . . 10
4.2. Fast Re-Authentication Acceptor Ticket Issuance . . . . . 10
4.3. Replay Cache Avoidance . . . . . . . . . . . . . . . . . . 10
4.4. User-to-User Authentication . . . . . . . . . . . . . . . 11
4.4.1. Negotiation Issues for User-to-User Authentication . . . . 11
5. Other Requirements, Recommendations, and
Non-Requirements . . . . . . . . . . . . . . . . . . . . . 13
6. Application Compatibility Note . . . . . . . . . . . . . . 14
7. Differences from "DCE style" . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 17
10. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 20
Williams & Dowdeswell Expires August 19, 2013 [Page 2]
Internet-Draft Kerberos Extra AP February 2013
1. Introduction
The Kerberos V5 [RFC4120] AP protocol, and therefore the Kerberos V5
GSS mechanism [RFC4121] security context token exchange, is a one-
round-trip protocol. Occasionally there are errors that the protocol
could recover from by using an additional round trip, but until now
there was no way to execute such an additional round trip. For many
application protocols the failure of the Kerberos AP protocol is
fatal, requiring closing TCP connections and starting over; often
there is no automatic recovery. This document proposes a negotiation
of an additional round trip for automatic recovery from certain
errors. This is done in a backwards-compatible way, thus retaining
the existing mechanism OID for the Kerberos V5 GSS mechanism.
Additionally we add support for user2user authentication and
authenticated errors, and provide a way to avoid the need for replay
caching.
1.1. Conventions used in this document
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 [RFC2119].
Williams & Dowdeswell Expires August 19, 2013 [Page 3]
Internet-Draft Kerberos Extra AP February 2013
2. Negotiation
We introduce the following new protocol elements. An ASN.1 module is
given in Section 3, and references to its contents are made below.
o a new ap-options flag for use in the clear-text part of AP-REQs to
indicate the desire for an extra round trip if need be;
o a new Authorization-Data element for use in Authenticators for
quoting back a challenge nonce from the acceptor;
o a new PDU: KRB-ERROR2, with additional fields and support for
authenticated errors.
To use this feature, initiators and acceptors MUST act as follows:
o To request this feature, initiators SHALL add the new ap-options
flag to their AP-REQs.
o Acceptors that wish to request an additional round trip SHOULD do
so when initiators indicate support for it, and do so by returning
a KRB-ERROR2. The encrypted part of the KRB-ERROR2 SHALL be
encrypted in one of the following keys: the sub-session key from
the AP-REQ's Authenticator if it could be decrypted, the session
key from the Ticket, if it could be decrypted, or the null enc-
type and null key. The KRB-ERROR2 in this case SHALL have a the
continue-needed e-flag set. The acceptor SHALL also return
GSS_S_CONTINUE_NEEDED to the application.
o Initiators that request this feature and receive a KRB-ERROR2
SHALL attempt to recover.
o Initiators that request this feature and receive a KRB-ERROR2 with
the ke-continue-needed e-flag set MUST attempt to recover and MUST
produce a token to send to the acceptor: either a KRB-ERROR2 if
the initiator failed to recover, or a new AP-REQ (with the
traditional GSS-API pseudo-ASN.1 mechanism OID header).
* In the successful recovery case the initiator MUST quote the
nonce from the KRB-ERROR2 using an AD-CHALLENGE-RESPONSE-NONCE
(see below) authorization data element, and this MUST NOT be
wrapped in an AD-IF-RELEVANT container.
o Initiators that support this feature and successfully recover from
a KRB-ERROR or KRB-ERROR2 SHALL return GSS_S_CONTINUE_NEEDED.
Otherwise they MUST generate a KRB-ERROR to send to the acceptor
and return an error to the application.
Williams & Dowdeswell Expires August 19, 2013 [Page 4]
Internet-Draft Kerberos Extra AP February 2013
The following Kerberos errors can be recovered from using this
protocol:
o KRB_AP_ERR_TKT_EXPIRED: the initiator should get a new service
ticket
o KRB_AP_ERR_TKT_NYV: the initiator should get a new service ticket
o KRB_AP_ERR_REPEAT: the initiator should build a new AP-REQ
o KRB_AP_ERR_SKEW: the initiator should build a new AP-REQ with time
corrected for the offset between the initiator's and acceptor's
clocks
o KRB_AP_ERR_BADKEYVER: the initiator should get a new service
ticket
o KRB_AP_PATH_NOT_ACCEPTED: the initiator should get a new service
ticket using a different transit path
Error codes that denote PDU corruption (and/or an active attack) can
also be recovered from by attempting a new AP-REQ:
o KRB_AP_ERR_BAD_INTEGRITY
o KRB_AP_ERR_BADVERSION
o KRB_AP_ERR_BADMATCH
o KRB_AP_ERR_MSG_TYPE
o KRB_AP_ERR_MODIFIED
Other error codes that may be recovered from:
o KRB_AP_ERR_BADADDR; the acceptor SHOULD include a list of one or
more client network addresses as reported by the operating system,
but if the acceptor does not then the continue-needed e-flag MUST
NOT be included and the error must be final.
It is also possible for an acceptor to request that the initiator re-
authenticate but to a different service principal, in which case the
error code SHALL be KRB_AP_ERR_NOT_US, the KRB-ERROR2 encrypted part
MUST be encrypted in the sub-session key from the Authenticator, and
the sname and realm fields of the KRB-ERROR2 MUST be present.
Williams & Dowdeswell Expires August 19, 2013 [Page 5]
Internet-Draft Kerberos Extra AP February 2013
2.1. Use in Non-GSS Applications
We only specify multiple round trips for the GSS mechanism and
application case. We believe that some non-GSS Kerberos applications
may also benefit from this extension.
2.2. Number of Round Trips
At most two round trips should be needed in general. Implementations
SHOULD impose a limit of either two or three round trips. An
initiator that rejects an additional round-trip MUST respond with a
KRB-ERROR2.
Note that in the user-to-user cases (see Section 4.4) it's possible
to have up to three round trips under normal conditions if, for
example, the acceptor wishes to avoid the use of replay caches (see
Section 4.3).
Williams & Dowdeswell Expires August 19, 2013 [Page 6]
Internet-Draft Kerberos Extra AP February 2013
3. ASN.1 for New Protocol Elements
An ASN.1 module appears below.
Williams & Dowdeswell Expires August 19, 2013 [Page 7]
Internet-Draft Kerberos Extra AP February 2013
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
-- continue-needed-ok(TBD)
ad-continue-nonce Int32 ::= <TBD>
-- ad-value is challenge nonce from KRB-ERROR2
KrbErrorEncPartFlags ::= KerberosFlags
-- reserved(0) [XXX sounds like cargo cult!]
-- use-initiator-subkey(1)
-- use-ticket-session-key(2)
-- use-null-enctype(3)
KRB-ERROR2 ::= [APPLICATION <TBD>] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (<TBD>),
enc-part-key [2] KrbErrorEncPartFlags,
enc-part [3] EncryptedData -- EncKRBErrorPart
}
ErrorFlags ::= KerberosFlags
-- reserved(0) [XXX sounds like cargo cult!]
-- continue-needed(1)
-- continue-failed(2)
-- use-other-sname(3)
-- user2user(4)
EncAPRepPart ::= [APPLICATION <TBD>] SEQUENCE {
challenge-nonce [0] OCTET STRING (16),
stime [1] KerberosTime,
susec [2] Microseconds,
error-code [3] Int32,
e-flags [4] ErrorFlags,
e-text [5] KerberosString OPTIONAL,
e-data [6] OCTET STRING OPTIONAL,
e-typed-data [7] TYPED-DATA OPTIONAL,
caddrs [8] HostAddresses OPTIONAL,
saddrs [9] HostAddresses OPTIONAL,
tgt [10] Ticket OPTIONAL, -- for user2user
ticket [11] Ticket OPTIONAL, -- fast-re-auth
srealm [12] Realm OPTIONAL, -- service realm
sname [13] PrincipalName OPTIONAL,
redir-srealm [14] Realm OPTIONAL,
redir-sname [15] PrincipalName OPTIONAL,
}
Williams & Dowdeswell Expires August 19, 2013 [Page 8]
Internet-Draft Kerberos Extra AP February 2013
Figure 1: ASN.1 module (with explicit tagging)
Williams & Dowdeswell Expires August 19, 2013 [Page 9]
Internet-Draft Kerberos Extra AP February 2013
4. Other Features
Two other features are supported:
o acceptor name redirection;
o acceptor-issued service ticket (for the same acceptor name)
issuance.
4.1. Acceptor Name Redirection
In some use cases, such as clusters, for example, an acceptor may
wish to ask the initiator to use a different name (and ticket) for
the acceptor. This is indicated by setting the redir-srealm and
redir-sname fields of a continue-needed KRB-ERROR2. The KRB-ERROR2's
enc-part MUST be encrypted in the initiator's sub-session key, and
initiators MUST ignore the redir-srealm and redir-sname fields of any
KRB-ERROR2 where the enc-part is encrypted in the null enc-type.
Because the acceptor's name redirection is authenticated to the
initiator, it is safe for the initiator to get a service ticket for
the new name and re-try authentication with it.
4.2. Fast Re-Authentication Acceptor Ticket Issuance
In view of future extensions where the Kerberos AP protocol may be
extended to use public key agreement protocols -which will likely be
slow-, we provide a field in the KRB-ERROR2 where the acceptor may
include a Ticket for itself, minted by the acceptor using a secret
key of its choosing. This service ticket may be used to speed up
future otherwise-slow AP exchanges.
4.3. Replay Cache Avoidance
By using an additional round trip and a challenge/response nonce,
this protocol is immune to replays of AP-REQ PDUs. Acceptor
implementations MAY not enter Authenticators from extra round trips
into a replay cache when there are no other old implementations on
the same host (and with access to the same acceptor credentials) that
ignore critical authorization data or which don't know to reject
initial AP-REQs that contain a challenge response nonce.
By the same token, acceptors that support this feature MUST reject
initial security context tokens that contain a challenge response
nonce.
Note that in the replay cache avoidance case, but where there's no
actual error (e.g., time skew) the acceptor's KRB-ERROR2 will have
Williams & Dowdeswell Expires August 19, 2013 [Page 10]
Internet-Draft Kerberos Extra AP February 2013
KDC_ERR_NONE as the error code, with the continue-needed e-flag.
4.4. User-to-User Authentication
There are two user2user authentication cases:
1. the KDC only allows a service principal to use user2user
authentication,
2. the service principal does not know its long-term keys or
otherwise wants to use user2user authentication even though the
KDC vended a service ticket.
In the first case the initiator knows this because the KDC returns
KDC_ERR_MUST_USE_USER2USER. The initiator cannot make a valid AP-REQ
in this case, yet it must send an AP-REQ or fail to make even an
initial security context token. For this case we propose that the
initiator make an AP-REQ with invalid ticket (really, the enc-part of
the Ticket will contain some OCTET STRING of length 1 or longer, but
no longer than the minimum cipher-text length for the enc-type listed
in the EncryptedData) and authenticator (an OCTET STRING of length 1
or longer, but no longer than the minimum cipher-text length for some
enc-type supported by the initiator). The acceptor will fail to
process the AP-REQ, of course, both because the Ticket and
Authenticator embedded in it are not valid, and because the acceptor
will likely not possess the key to decrypt a real Ticket. The
acceptor SHOULD respond with a continue-needed KRB-ERROR2 (using the
null enc-type for the enc-part) that includes a TGT for the acceptor.
In the second case the initiator does manage to get a real service
ticket for the acceptor but the acceptor nonetheless wishes to use
user2user authentication. In this case the acceptor responds with a
KRB-ERROR2, using either the null enc-type for the enc-part, or the
initiator's sub-session key, and includes a TGT for itself.
In both cases the initiator then does a TGS request with a second
ticket to get a new, user2user Ticket. Then the initiator makes a
new AP-REQ using the new Ticket, and proceeds.
4.4.1. Negotiation Issues for User-to-User Authentication
Initiator applications that can negotiate security mechanisms and
which have available an existing user-to-user mechanism
[I-D.swift-win2k-krb-user2user] as well as the Kerberos V5 GSS
mechanism with the user-to-user extension defined here will have a
problem: they may end up negotiating the use of the Kerberos V5 GSS
mechanism and fail to establish a security context because the
acceptor does not support the features defined in this document, but
Williams & Dowdeswell Expires August 19, 2013 [Page 11]
Internet-Draft Kerberos Extra AP February 2013
the application might have succeeded if it had selected the user-to-
user mechanism.
[Question: how should we address this? We could say "give priority
to the user-to-user mechanism", but in some cases that might require
changes to the acceptor side. Should we just remove the use of user-
to-user functionality? We could remove half of the user-to-user
functionality, the half that is triggered by
KDC_ERR_MUST_USE_USER2USER KDC errors. -Nico]
Williams & Dowdeswell Expires August 19, 2013 [Page 12]
Internet-Draft Kerberos Extra AP February 2013
5. Other Requirements, Recommendations, and Non-Requirements
All error PDUs in an AP exchange where the AP-REQ has the continue-
needed-ok ap-options flag MUST be KRB-ERROR2 PDUs.
Whenever an acceptor is able to decrypt the Ticket from an AP-REQ and
yet wishes or has to output a KRB-ERROR2, then the enc-part of the
KRB-ERROR2 MUST be encrypted in either the initiator's sub-session
key (from the AP-REQ) or the Ticket's session key (if the acceptor
could not decrypt the Authenticator), and the srealm and sname fields
MUST be set to be the same as the realm and sname fields from the
Ticket.
Whenever an initiator receives a KRB-ERROR2 with enc-part encrypted
in either the initiator's sub-session key or the Ticket's session
key, then the initiator SHOULD check that the srealm and sname fields
of the KRB-ERROR2 encrypted part match the ones used in the
initiator's AP-REQ's Ticket (XXX what should the initiator do if
these don't match?!).
...
Williams & Dowdeswell Expires August 19, 2013 [Page 13]
Internet-Draft Kerberos Extra AP February 2013
6. Application Compatibility Note
Some GSS-API applications assume that no more than one round trip is
required for security context token establishment. Most such
applications will fail safe if GSS_Init_sec_context() or
GSS_Accept_sec_context() return GSS_S_CONTINUE_NEEDED when they
expect GSS_S_COMPLETE -- such applications already should be able to
handle errors in this case. Such applications will fail to interop
when used with initiator and acceptor mechanism implementations that
support these extensions if the acceptor mechanism decides to use
extra round trips. Acceptor mechanism implementors might wish to
provide a configuration option for disabling extra round trips.
Williams & Dowdeswell Expires August 19, 2013 [Page 14]
Internet-Draft Kerberos Extra AP February 2013
7. Differences from "DCE style"
[XXX Add text explaining what DCE style is as well as a reference.]
There are four differences between this protocol extension and "DCE
style", three of which are consequential:
1. DCE style is selected by the initiator _application_ via a
request flag.
2. DCE style is, in practice, mandatory for the acceptor to
implement, else interop fails. Because of difference #4 (see
below), initiators could detect that the acceptor did not
understand the DCE style flag and recover, but in practice they
do not.
3. This extension is a) transparent to applications, b) generic,
allowing for arbitrary round trips for arbitrary purposes.
Indeed, this extension supports a number of additional features
beyond DCE style's replay cache avoidance: error recovery, user-
to-user authentication, and others (see above).
Williams & Dowdeswell Expires August 19, 2013 [Page 15]
Internet-Draft Kerberos Extra AP February 2013
8. Security Considerations
This document deals with security.
[XXX Note the resource using attacks that are feasible when we have
multiple round-trips and note that they are nothing new and nothing
to worry about because services should already have timeouts on pre-
authenticated protocol phases, and even post-authentication.]
Williams & Dowdeswell Expires August 19, 2013 [Page 16]
Internet-Draft Kerberos Extra AP February 2013
9. IANA Considerations
This document has no IANA considerations.
Williams & Dowdeswell Expires August 19, 2013 [Page 17]
Internet-Draft Kerberos Extra AP February 2013
10. TODO
o Add references to ASN.1 and DER (X.680 and X.690).
Williams & Dowdeswell Expires August 19, 2013 [Page 18]
Internet-Draft Kerberos Extra AP February 2013
11. References
11.1. 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.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
11.2. Informative References
[I-D.swift-win2k-krb-user2user]
Swift, M., Brezak, J., and P. Moore, "User to User
Kerberos Authentication using GSS-API",
draft-swift-win2k-krb-user2user-03 (work in progress),
February 2011.
Williams & Dowdeswell Expires August 19, 2013 [Page 19]
Internet-Draft Kerberos Extra AP February 2013
Authors' Addresses
Nicolas Williams
Cryptonector, LLC
Email: nico@cryptonector.com
Roland Charles Dowdeswell
Dowdeswell Security Architecture
Email: elric@imrryr.org
Williams & Dowdeswell Expires August 19, 2013 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 07:35:04 |