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,
}

Figure 1: ASN.1 module (with explicit tagging)

4. Other Features

Two other features are supported:

• acceptor name redirection;
• 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 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 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]

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?!).

...

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.

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).

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.]

9. IANA Considerations

This document has no IANA considerations.

10. TODO

• Add references to ASN.1 and DER (X.680 and X.690).

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", Internet-Draft draft-swift-win2k-krb-user2user-03, February 2011.

Authors' Addresses