Network Working Group R. Van Rein Internet-Draft ARPA2.net Intended status: Standards Track October 1, 2015 Expires: April 3, 2016 TLS-KDH: Kerberos + Diffie-Hellman in TLS draft-vanrein-tls-kdh-00 Abstract This specification extends TLS with a Kerberos-based method of mutual authentication, and binds in Diffie-Hellman to achieve Perfect Forward Secrecy for the session. 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 April 3, 2016. Copyright Notice Copyright (c) 2015 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 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. Van Rein Expires April 3, 2016 [Page 1] Internet-Draft TLS-KDH October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Relations to Prior Work . . . . . . . . . . . . . . . . . . . 3 3. CipherSuites for Kerberos with Forward Secrecy . . . . . . . 4 4. ClientHello: TLS-KDH CipherSuites . . . . . . . . . . . . . . 4 4.1. Indicating the Server Name . . . . . . . . . . . . . . . 5 5. ServerHello: Selecting a TLS-KDH CipherSuite . . . . . . . . 6 6. No ServerCertificate . . . . . . . . . . . . . . . . . . . . 6 7. ServerKeyExchange: Ephemeral Diffie-Hellman . . . . . . . . . 6 7.1. TicketRequestFlags . . . . . . . . . . . . . . . . . . . 7 8. Obtaining a Service Ticket on the Client . . . . . . . . . . 9 9. ClientKeyExchange: Kerberos ticket with Diffie-Hellman . . . 10 9.1. Impact of Anonymous Client Tickets . . . . . . . . . . . 11 10. Master Secret Calculation . . . . . . . . . . . . . . . . . . 12 11. Finished: Mutual Validation . . . . . . . . . . . . . . . . . 12 12. Freshness of Diffie-Hellman Keys . . . . . . . . . . . . . . 13 12.1. Managing a Pool of Fresh Keys . . . . . . . . . . . . . 14 12.2. Impact on Replay Attacks . . . . . . . . . . . . . . . . 15 12.3. Impact on Denial-Of-Service Attacks . . . . . . . . . . 16 13. TLS Connection Expiration . . . . . . . . . . . . . . . . . . 17 14. Mandatody CipherSuites . . . . . . . . . . . . . . . . . . . 18 15. Comparison to Earlier Work . . . . . . . . . . . . . . . . . 18 16. Efficiency Considerations . . . . . . . . . . . . . . . . . . 19 17. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 18. Security Considerations . . . . . . . . . . . . . . . . . . . 20 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 20.1. Normative References . . . . . . . . . . . . . . . . . . 24 20.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Kerberos lends itself well to infrastructure-supported mutual authentication, and can even be used to crossover between realms. A downside of this infrastructure is that a crack of one key can lead to a cascade of reverse-engineered keys. Diffie-Hellman key exchange can be used to incorporate the desirable property of Perfect Forward Secrecy, but its vulnerability for man-in-the-middle attacks must then be overcome by cryptographically binding it to an authentication mechanism. The protocol described in this specification forms a cryptographic binding between Kerberos and Diffie-Hellman, leading to the combined advantages of infrastructure-supported mutual authentication and Perfect Forward Secrecy. Van Rein Expires April 3, 2016 [Page 2] Internet-Draft TLS-KDH October 2015 The flow of the TLS-KDH protocol is informally presented in the following chart: Client Server ClientHello --------> ServerHello ServerKeyExchange <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * Indicates optional or situation-dependent messages that are not always sent. [] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not actually a TLS handshake message. 2. Relations to Prior Work Prior work exists for Kerberos authentication within TLS [RFC2712]. This work has a few drawbacks that are addressed in this new specification. Specifically, it is useful to combine Kerberos mutual authentication with the Perfect Forward Secrecy of Diffie-Hellman. Specifically for the HTTP and HTTPS protocols, the Negotiate header [RFC4559] can provide Kerberos authentication, but its use is not considered a strong security practice. Applications that currently rely on this mechanism can strengthen their security by moving to HTTP over TLS-KDH. Note that this provides an alternative for Kerberos, not to SPNEGO and not for general GSS-API protocols. This restriction of TLS-KDH to Kerberos, rather than a more general GSS- API protocol, is a result of the limited number of message exchanges available within TLS. Many other protocols incorporate Kerberos through GSS-API, usually via SASL. This is considered secure, but has the disadvantage of separating encryption and authentication layers, and quite possibly also the identities involved in these layers. Furthermore, encryption through SASL is not commonly used. In situations where Kerberos is used for GSS-API over SASL, TLS-KDH offers a comparable but more efficient and tighter-coupled mechanism for encryption and mutual authentication, in a way that also lends itself for non-SASL applications. Specifically useful in this respect is that there is Van Rein Expires April 3, 2016 [Page 3] Internet-Draft TLS-KDH October 2015 no longer a requirement to setup X.509 certificates plus infrastructure and validation mechanisms, just to satisfy encryption requirements with their own authentication infrastructure. In applications that use SASL, the EXTERNAL mechanism [RFC4422] can be used to extract the remote identity from a Kerberos ticket, and make it available to the application layer; SASL EXTERNAL is also used when TLS authenticates peers through X.509 certificates. The following paragraph is an informational suggestion: When a SASL EXTERNAL mechanism is used to communicate an identity between the application and the TLS stack, then a good alignment with X.509 certificates is possible when both aim to derive a Network Access Identifier [RFC4282] and/or a domain name. In the case of a Kerberos principal name, this would involve translation between case-sensitive realm names to DNS names whose case is not reliably [Section 4.1 of [RFC4343]] reproduced; this may be done by ignoring or lowering the case of the realm name while upholding the requirement that no two realm names may differ only in their case [Section 7.2.3.1 of [RFC4120]]. 3. CipherSuites for Kerberos with Forward Secrecy This specification extends TLS [RFC5246] with a number of CiperSuites that subject ephemeral Diffie-Hellman key exchange to Kerberos mutual authentication. The names of the new CipherSuites are listed under IANA Considerations, and will collectively be referred to as TLS-KDH CipherSuites in this specification. The variants of the TLS protocol variants following one of these CipherSuites will be informally referred to as TLS-KDH in this specification. The names of the TLS-KDH CipherSuites can be split into DHE_KRB and ECDHE_KRB variants; their names start with TLS_DHE_KRB_ and TLS_ECDHE_KRB_, respectively; the corresponding KeyExchangeAlgorithm tags will be dhe_krb and ecdhe_krb, respectively. The cipher and hash algorithm for each of the TLS-KDH CipherSuites are easily determined by examining the name; this follows the same regime that is commonly used in other TLS specifications. The only thing that this specification adds to the CipherSuites is a new authenticated key exchange mechanism. 4. ClientHello: TLS-KDH CipherSuites A client willing to employ Kerberos authentication offers one or more of the TLS-KDH CipherSuites in its ClientHello message. Offering these is no guarantee that a token has already been found for the server, but it expresses a willingness to look for one. Van Rein Expires April 3, 2016 [Page 4] Internet-Draft TLS-KDH October 2015 Whether a client is willing to employ Kerberos authentication MAY depend on its context. Following is an informative example of situations that could be considered, with a rising level of willingness: 1. Kerberos software is available on the client system 2. The client context holds a Ticket Granting Ticket that is currently valid 3. The client context holds a Ticket Granting Ticket that may have expired 4. The client context will go through Kerberos signup if need be The last two options may require interaction with the user, and are not suitable for all kinds of applications. The first and last options are too extreme to be defaults, but depending on the ability to interact, the middle two can be useful as defaults that may be modified by users if they want to. TLS defines a gmt_unix_time field in the Random substructure of a ClientHello. This field is not always used. With Kerberos however, time is very important and upfront hints of a peer's time can be helpful. For this reason, the gmt_unix_time field in a ClientHello MUST always be filled if TLS-KDH is being requested. 4.1. Indicating the Server Name If the ClientHello includes the server_name extension [RFC6066], and if that extension includes the HostName variant, then this will be the default domain or host name that the client would use when requesting for a service ticket. The Kerberos protocol name is considered to be provided by the application level. The realm name used should either be clear from the context (such as the login realm or static configuration) or it can be found in secure DNS records [KREALM] by either the Kerberos client or its KDC. The server_name extension is optional, but recommended for all uses of TLS-KDH because it provides useful hints to the server about assumptions made in the client. Aside from its current use in other parts of TLS, the server_name extension can be used by the server as a hint towards desired Kerberos configuration settings; such settings can then be different for different host names, as per the server-side configuration. A server MAY fall back to a default Kerberos configuration for clients that provide no server_name extension, and this default configuration Van Rein Expires April 3, 2016 [Page 5] Internet-Draft TLS-KDH October 2015 MAY be less functional when insufficient information is available for optimal support of the client. 5. ServerHello: Selecting a TLS-KDH CipherSuite After the client has offered one or more TLS-KDH CipherSuites, the TLS-KDH server configures its schemas of authentication and encryption by choosing one of these CipherSuites. The server MUST NOT choose a TLS-KDH CipherSuite if it knows that it cannot process a Kerberos principal ticket for the requested service under any realm. When the service_name is processed to select a Kerberos configuration, then this specialised information MUST be taken into account in making this decision. When constructing the ServerHello, the TLS-KDH server fills the gmt_unix_time field in the Random substructure. When the difference between the client and server time setting digresses to far, a server MAY also choose to reject a client's proposed TLS-KDH CipherSuites. There are more subtle possibilities too; a server may queue clients in a way that gradually disadvantages clients more as their gmt_unix_time digresses farther from that of the server. Specifically, sending a Diffie-Hellman public key may get deferred by such a policy. Section Section 12.2 describes a use case that could benefit from this approach. 6. No ServerCertificate The ServerCertificate message MUST NOT be included in TLS-KDH. The Kerberos exchanges implemented by TLS-KDH provide mutual authentication. As a result, there is no need for additional proof of server authenticity through X.509 certificates. 7. ServerKeyExchange: Ephemeral Diffie-Hellman When one of the TLS-KDH CipherSuites is selected, the ServerKeyExchange MUST include an ephemeral Diffie-Hellman offer. This is done through an extension of the ServerKeyExchange structure: Van Rein Expires April 3, 2016 [Page 6] Internet-Draft TLS-KDH October 2015 struct { select (KeyExchangeAlgorithm) { /* existing cases defined elsewhere */ case dhe_krb: TicketRequestFlags ticket_request_flags; ServerDHParams params; case ecdhe_krb: TicketRequestFlags ec_ticket_request_flags; ServerECDHParams ec_params; }; } ServerKeyExchange; DISCUSS: Consider removing the dhe_krb case, leaving just ecdhe_krb Note that the new structure variations are not signed; instead of using an X.509 server certificate the Kerberos extension relies on the session key that Kerberos establishes for a session between a client and server, and from which a proof of authenticity will be derived. The ticket_request_flags and ec_ticket_request_flags field perform the same function for different key exchange algorithms. They express flags that hint at properties for acceptable service tickets. 7.1. TicketRequestFlags DISCUSS: Do we want this? Not having it would mean that a client can have a local policy that defaults to anonymous credentials, and leave it to the server how to deal with it. OTOH, a flag indicating a unique identity for the client, perhaps in a service-specific pseudonymic identity, could be useful to all parties involved. This structure is an extensible list of flag values that indicate constraints on the ticket that the client should supply. These should be seen as hints how the client should present its identity, as the server can always decide to reject a client on grounds that are or are not expressible in this form. Flag values defined in this specification are: VisibleClientRealm (flag number 0) requests that the client's realm name is revealed in the service ticket. With the flag not set, the server MUST NOT reject the well-known anonymous realm name WELLKNOWN:ANONYMOUS [Section 3 of [RFC6112]] in the client realm name. LocalRealmService (flag number 1) indicates that the client SHOULD NOT perform realm crossover, but instead look for a service Van Rein Expires April 3, 2016 [Page 7] Internet-Draft TLS-KDH October 2015 ticket in its local realm. When this flag is set, the client may choose whether canonicalization [RFC6806] is useful; when this flag is not set, the client SHOULD use canonicalization to help it crossover to all realms that the KDC can reach. When this flag is not set, the server MUST NOT expect the client realm to match one of the server realms. UniqueClientIdentity (flag number 2) requests that the client presents a unique identity, even if it is a pseudonym that is specific to this service. Some services can make good use of identities that are also presented over other protocols, which is why the choice to share such an identity SHOULD be made during an interaction with the user, if possible. The user MAY determine to use only a short-lived identity. When this flag is not set, the server MUST NOT reject the client principal name WELLKNOWN/ANONYMOUS of type KRB_NT_WELLKNOWN [Section 3 of [RFC6112]]. Regardless of this flag, it is RECOMMENDED for the server to be open to as many forms of client principal name [Section 6.2 of [RFC4120]] as possible. Additional flag bit values are reserved through the publication of an RFC. (TODO: IANA's Kerberos registry?) Future specifications of flag values may state that a flag is an alternative to another flag, including to the ones specified above. When flag A is an alternative to flag B then the fulfillment of the requirements for A suffice to ignore flag B. It is possible for flags to cyclically refer to each other as alternatives; also in this case one flag's requirements can be fulfilled to skip the responsibilities for the flags to which it is an alternative. What that means precisely depends on the pattern of reference. The structure holding TicketRequestFlags is a sequence of 32-bit integers. The lower 5 bits of a flag number indicate the bit within a 32-bit integer, and the higher bits indicate the integer's index in the list. Servers MUST send unknown flags with value 0 and clients MUST NOT act on flags they don't know. struct { uint32 flags<0..2^16-1> } TicketRequestFlags; Integers that are not present in the flags array MUST be considered to have value 0. The last 32-bit integer MUST NOT contain all 0 bits. Note that this implies that the TicketRequestFlags can be an array of zero integers, namely when all flag values are 0. Van Rein Expires April 3, 2016 [Page 8] Internet-Draft TLS-KDH October 2015 8. Obtaining a Service Ticket on the Client The client may have locally configured realms, and/or it may lookup realm specifications in secure DNS [KREALM]. Combined with the service protocol and server name, this helps the client to form one or more service principal names. These can be used in ticket requests. Before obtaining a Kerberos ticket, several considerations could be taken into account by the TLS-KDH client to select and/or order suitability of principal names for a desired ticket: o Local policy could specify a service principal name to always use for a particular service protocol and/or server name and/or realm name; o Local policy could specify a client principal name to always use for a particular service protocol and/or server name and/or realm name; o A realm name match with a principal ticket's realm could suggest using that; o Prior availability of a service ticket could suggest using the service principal name in that ticket; o Prior availability of a service ticket could suggest using the client principal name in that ticket; o Prior availability of a ticket granting ticket could suggest using that. In addition to this choice in service name to request, the client may wish to modify its own name, perhaps to a group name or a pseudonym, according to local policy and/or historic choices made. Such mechanisms need not be standardised, as they are a local matter to the client-side Kerberos solution. One default procedure is however RECOMMENDED, namely to send an anonymous ticket [RFC6112] when the server has not sent the UniqueClientIdentity flag; but to instead use a non-anonymous ticket when the anonymous ticket includes the anonymous realm name while the sever has sent the VisibleClientRealm flag. The client SHOULD interact with the user to request permission for releasing the identifying information if possible, but the mechanism MAY store choices for future use in similar situations. Finally, the client-side Kerberos solution MAY obtain a pseudonymous name such as one based on NT-UID principal names [Section 6.2 of [RFC4120]] when the server has sent the UniqueClientIdentity flag; it Van Rein Expires April 3, 2016 [Page 9] Internet-Draft TLS-KDH October 2015 is up the client whether this is a short-lived or long-lived identity. Given the options that are now available, the TLS client SHOULD proceed in attempts to obtain a service ticket, until either a ticket is assigned or all options for obtaining one have been exhausted. When no ticket can be obtained, the TLS client MUST send a TLS Alert and shut down the connection. The client might reconnect without offering TLS-KDH CipherSuites in response to a temporary local cache holding the negative result on a prior attempt. 9. ClientKeyExchange: Kerberos ticket with Diffie-Hellman When the TLS-KDH client finds a suitable Kerberos service ticket, it sends a ClientKeyExchange messaging holding both that ticket and a Kerberos-styled authenticator constructed by the TLS-KDH client. This authenticator is freshly created for each submission. The message format holding these two parts is formally specified as: struct { select (KeyExchangeAlgorithm) { /* definitions from other RFCs */ case dhe_krb: opaque krb_ticket<0..2^16-1>; opaque authenticator_with_dh_ad<0..2^16-1>; case ecdhe_krb: opaque krb_ticket<0..2^16-1>; opaque authenticator_with_ecdh_ad<0..2^16-1>; } exchange_keys; } ClientKeyExchange; The selected krb_ticket byte string field MUST hold the literal bytes of a Kerberos Ticket structure [Section 5.3 of [RFC4120]]. When selected, the authenticator_with_dh_ad field MUST contain an Authenticator [Section 5.5.1 of [RFC4120] encrypted with the session key that is presented to the service through the ticket in the krb_ticket field. This Authenticator's AuthorizationData MUST contain an element with ad-type AD-DH-PUBKEY [KRB5-KDH] and ad-data holding a BITSTRING containing a DHPubkey [KRB5-KDH]. This supplies the same dh_Yc value that is supplied in the ClientDiffieHellmanPublic structure [RFC5246] as part of other CipherSuites whose names start with TLS_DHE_. When selected, the authenticator_with_ecdh_ad field MUST contain an Authenticator [Section 5.5.1 of [RFC4120]] encrypted with the session key that is presented to the service through the ticket in the krb_ticket field. This Authenticator's AuthorizationData MUST Van Rein Expires April 3, 2016 [Page 10] Internet-Draft TLS-KDH October 2015 contain an element with ad-type AD-ECDH-PUBKEY [KRB5-KDH] and ad-data holding a BITSTRING containing an ECDHPubkey [KRB5-KDH]. This supplies the same ecdh_Yc value that is supplied in the ClientECDiffieHellmanPublic structure [RFC4492] as part of other CipherSuites whose name starts with TLS_ECDHE_. The values of the authorization data types are: AD-DH-PUBKEY (TBD) AD-ECDH-PUBKEY (TBD) 9.1. Impact of Anonymous Client Tickets When sending the ClientKeyExchange, a ticket is always provided. It is possible however, to use an anonymous ticket [Section 3 of [RFC6112]], Section 3] that conceals the client principal name (the cname field in the ticket) and possibly also the client realm name (the crealm field in the ticket). It is RECOMMENDED to use this kind of service ticket inasfar as it is permitted by the TicketRequestFlags that the server sent. The impact of using an anonymous ticket is that the server cannot establish the identity of the client, except perhaps that the same service ticket may be used repeatedly during its short period of validity. This means that the ability to trace the client is limited for both server and client. Under X.509 authentication, the customary interpretation of not sending the CertificateRequest is that the server does not care for the client identity; anonymous tickets provide a mechanism for achieving a similar pattern under TLS-KDH. The presence of a ticket enables the server to conclude that the client has procured a ticket through the formal pathways of Kerberos, ending in the server-side realm; the reason this can be assumed is that the ticket holds an encrypted part that the server can decrypt and thereby validate with its own key, as setup in its KDC for sharing in service tickets. In other words, even an anonymous ticket establishes that the server may trust that the client was checked along the way to the service. As a result, the Diffie-Hellman key exchange to follow, is known to be protected by a suitable ticket. Briefly put, we can speak of mutual authentication in this specification, even when the client uses an anonymous ticket. The thing that is missing under an anonymous ticket is simply a validated (unique) identity for the client. Van Rein Expires April 3, 2016 [Page 11] Internet-Draft TLS-KDH October 2015 10. Master Secret Calculation The Kerberos ticket holds a session key, which the KDC only makes available to a pair of authentic principals; we follow the Kerberos assumption of trust in the KDC (or path of KDCs) connecting the TLS- KDH client and the TLS-KDH server. Using the standard Diffie-Hellman procedures for TLS [Section 8.1.2 of [RFC5246]] [Section 5.10 of [RFC4492]], a shared secret SHALL be calculated independently on the TLS-KDH client and the TLS-KDH server. The shared secret value (Z) is used as the pre-master secret, after stripping all leading bytes that contain only zero bits. The master secret is then determined as is customary for TLS. 11. Finished: Mutual Validation The security of TLS-KDH relies more heavily on the Finished messages than Diffie-Hellman under Kerberos [KRB5-KDH]; TLS-KDH has an analogue for AP-REQ but not for AP-REP, so the client must still verify the server's proper use of the session key, or something decoded with it, as a proof of its authenticity. Furthermore, the server-sent Diffie-Hellman public key, as sent in the ServerKeyExchange, has not been authenticated yet. The use of the master secret based on the outcome of the key exchange, hashed together with the preceding handshake that includes the server-sent public key, and relying on the server's ability to decode the client- sent public key, together prove the server's authenticity to the client, and all this is arranged by the Finished message in TLS-KDH. The security of TLS-KDH also relies more heavily on the Finished messages than other TLS CipherSuites; the lack of a server signature on the ServerKeyExchange means that its authenticity can only be established once it has proven its ability to decrypt the authenticator holding the other half of the key exchange, and this verification is taken care of in the Finished exchange. The TLS specification is strict about verification of the verify_data contained in Finished messages, but leaves room for shorter verification data than cryptographically desirable for TLS-KDH. A "good size" for the verify_data_length is twice the bitsize of the key used in the symmetric algorithm, rounded up to an integer number of bytes; in the case of TLS-KDH, that would be based on the symmetric key algorithm specified as part of the CipherSuite. For TLS_DHE_KRB_WITH_ARIA_256_GCM_SHA384 it would be 64 bytes and for TLS_DHE_KRB_WITH_3DES_EDE_CBC_SHA it would be 42 bytes. Van Rein Expires April 3, 2016 [Page 12] Internet-Draft TLS-KDH October 2015 TODO: twice follows http://www.keylength.com/en/4/ -- is it necessary here? Negotiable values for verify_data_length were introduced in TLS 1.2; in earlier versions, the value was fixed to 12 bytes and TLS 1.2 still uses 12 bytes as a default size. Because of this, TLS-KDH authentication SHOULD NOT be implemented for any SSL version, nor for TLS versions up to and including TLS 1.1. When a TLS-KDH CipherSuite is selected on TLS 1.2 and later versions, the value of verify_data_length is defined to be the CipherSuite- dependent "good size" of the previous paragraph, although it is still possible to explicitly negotiate another value. In general, implementations SHOULD NOT accept values of verify_data_length below the "good size" for the applicable CipherSuite. Furthermore, specific mechanisms may fall under a lowest threshold that an administrator would like to enforce in their software; a client could prevent rejection on those grounds by proposing a higher verify_data_length and a server could enforce it while selecting the CipherSuite to use. Both parties SHOULD be willing to support twice the "good size" for the given CipherSuite. 12. Freshness of Diffie-Hellman Keys This specification refers to the use of "fresh" Diffie-Hellman keys. This section defines when such keys are considered fresh, and what operational impact this definition has. In some cases, there is no need to use a fresh Diffie-Hellman key; servers may reuse a Diffie-Hellman key use in the same TLS connection when it undergoes secure renegotation [RFC5746]. Diffie-Hellman keys MUST NOT be reused by TLS-KDH clients. In line with commonly accepted TLS procedures, the server dictates the Diffie-Hellman key parameters, without negotiation options for the client, except the choice between TLS_DHE_KRB_ and TLS_ECDHE_KRB_ variations. The client's sole prerogative is to reject an offered Diffie-Hellman public key if something about it (size, blacklistedness) is not considered agreeable. It is generally assumed that a TLS server is setup to provide sufficiently secure Diffie-Hellman exchanges. It should be noted that the security is additionally protected by the KDC-supplied session key, and that the only danger is that this is replaced with a Diffie-Hellman key of a lesser size. For that reason, servers MUST supply Diffie-Hellman public keys that generate session keys of at least the number of bytes (rounded down) as the number of bytes (rounded up) in the symmetric key of the selected CipherSuite. Van Rein Expires April 3, 2016 [Page 13] Internet-Draft TLS-KDH October 2015 12.1. Managing a Pool of Fresh Keys Any newly generated Diffie-Hellman key is considered fresh; this includes pregenerated keys that may have been stored in a pool of fresh keys. The remainder of this section details when half-used keys may be recycled to this pool. It is quite possible for such a pool of fresh keys to be shared between application instances (such as virtual hosts) and even between different application protocols that rely on TLS for security. It is not recommended however, to share the pool of fresh keys between redundant or even distributed server machines, as that would introduce communication delays and usually not have any benefit. For a client, a key can never become fresh after it has been used in a ClientKeyExchange. Had this been any different, then two servers might get hold of the same Diffie-Hellman public key, in which case they might be in a position to tap traffic, or mount a man-in-the- middle attack. For a server, some reuse of keys is possible. This is largely due to the fact that the Diffie-Hellman public key is visible in plaintext, and should therefore be considered something that is easily shared with any players, rogue ones included. TLS connections might terminate before the handshake is complete, including as a result of time-outs caused by unresponsive clients. When no ClientKeyExchange has been received over such a connection, then the server's Diffie-Hellman public key can be returned to the pool of fresh keys after the connection has been completely shut down. When a ClientKeyExchange has been received, but the contained Kerberos ticket failed on account of authentication, access control or anything else that avoids completing the Diffie-Hellman key exchange, then the server's public key has not been put to use, and there is no risk of reuse. The one thing to care for is that Kerberos authentication uses a time stamp, which the server accepts within a certain time window. Upon failure to authenticate a ticket, the server's public key must not be returned to the pool of fresh keys until the full duration of this server-side time window has passed. Anytime this specification calls for a fresh Diffie-Hellman key, it may be taken from this pool of fresh keys, even if that involves reuse of previously failed keys. Van Rein Expires April 3, 2016 [Page 14] Internet-Draft TLS-KDH October 2015 12.2. Impact on Replay Attacks Kerberos authentication is valid over a certain period starting and ending at a time stamp embedded in the Authenticator that is attached to the ticket. The server verifies these times, usually tolerating a small time window to deal with clock skew. This is the normal procedure for handling a ticket in a successful TLS-KDH flow. One of the attacks of which a Kerberos system must be aware, is replay. This is the situation where a rogue party taps the ticket and authenticator, and resends it as part of its own communication. It is especially useful in protocols that only check the Kerberos login but make no further use of the keys contained in it, or in protocols that are susceptible to other clever attacks. The traditional solution to this is to permit a time window around the server's current time, to compensate for clock skew between machines, and demand that the timestamp in the Authenticator falls within that window. During this period, the server must not accept the same Authenticator, which is usually arranged by caching it during the window time. In TLS-KDH however, the Authenticator contains a Diffie-Hellman public key which is paired with that of the server to form the master secret used in all of TLS, so as long as the server sends another Diffie-Hellman public key the result will be another master secret. This is why it is not good to reinsert a server's public key in the pool of fresh keys until the entire window period has passed; which never applies when authentication succeeds, but it might when it fails. The client's timestamp might have been in the beginning of the clock skew window, leaving room for rogue resubmissions until the end of the window. By keeping the server's public key out of circulation until the entire clock skew window has passed, this has been mitigated with certainty. The previous paragraph assumed that the Authenticator does not contain a timestamp that lies (far) in the future, which was assumed because it is not in the client's interest to lie. It is possible to tighten the signature check beyond the clock skew window, by observing the difference between the gmt_unix_time fields in ClientHello and ServerHello. After correcting for this initial skew, the remaining clock skew is limited to the effects of communication delays, clock drift and relativistic effects. The check on the remaining clock skew can be made within a much tighter time window than before, without disadvantaging clients that function normally. Van Rein Expires April 3, 2016 [Page 15] Internet-Draft TLS-KDH October 2015 When applying this tighter check, the total window period to compensate for clock skew still includes the acceptable time difference between the gmt_unix_time fields, so this does not get tighter. What this tighter check does however, is that it forces attackers to modify the gmt_unix_time that they send in a ClientHello, and as explained in Section Section 5, this can be used to the disadvantage of such clients. 12.3. Impact on Denial-Of-Service Attacks The TLS-KDH CipherSuites enable fast authentication of clients, based on symmetric key cryptography. Only for the assurance of Perfect Forward Secrecy is there a need to use some public key cryptography. Since public key operations impose a higher computational load on a system than symmetric key operations, they are attractive targets for denial-of-service attacks. Within TLS-KDH, the willingness to provide different Diffie-Hellman public keys to each client, without having authenticated them, opens an opportunity of attack. The suggested use of a pool of fresh keys can help to thwart this attack. Especially the ability to recycle keys into fresh keys drastically limits the impact of a denial-of-service attack through the computational complexity of public-key operations. Note that recycling is always possible for clients that failed to authenticate; which is a suitable criterium to distinguish rogue clients from normal ones. The pool size may either prepare for denial-of-service attacks by filling up to a size that can withstand the constant bashing of the attack, and doing little more than the Kerberos authentication computations; or a pool may be adaptively sized and fill up, thus reducing the responsiveness of the server in the beginning of an attack, but returning to full service soon after the start of the attack. Note that it is helpful in this respect that the pool can be shared among the various application instances and application protocols on a system. Furhter concerns that help with the mitigation of an attack including reduction of the timeout after which a client connection is torn down. This may be approached through timing, or by timing out the most stagnated client connections when the pool of fresh keys runs empty. One of the ways to implement this operationally could be to sidetrack traffic with the patterns of an attack to a service that is setup especially to deal with denial-of-service attacks. Based on normal behaviour, and especially focussing on successful authentications, it should be possible to find a probability distribution for timeouts that can help to separate proper clients Van Rein Expires April 3, 2016 [Page 16] Internet-Draft TLS-KDH October 2015 from those who are trying to drain the pool of fresh keys. It is very likely that a cut-off of the slow tail of proper authentications would only disadvantage clients that need to interact with their KDC or human user, while it would drastically reduce the effect of pool drainage. The clients that are cut off because they need interaction time are setting up a new connection to a new service, and a simple reconnection attempt should help them to quickly use the information that would be cached by then. Under a denial-of-service attack, this appears to be an acceptable condition. As explained in Section Section 12.2, it is possible to force a rogue client to offset its time in the ClientHello message, and this can be used to delay such rogue servers as explained in Section Section 5; this is especially important when an attack is mounted on the capacity for producing fresh Diffie-Hellman public keys, and the ability to immediately have a suspicion of which clients might be rogue really helps in getting proper traffic to pass through. 13. TLS Connection Expiration TLS-KDH connections expire when their authenticating Kerberos tickets expire. This is not a reason for termination of the TLS connection, but instead it is a trigger for refreshing the ticket. Such a refresh should be executed by the TLS-KDH client, where it may trigger user interaction. Note that Kerberos' facility of ticket renewal [Section 2.3 of [RFC4120]] may provide some relief from such user interaction. When the TLS-KDH connection expires, neither side will send any further data records, and upon receiving any data records, each side will trigger a TLS Alert. The other records are still accepted, to permit re-issuance of session keys. This mode of operation is intended to block data communication until authentication has been refreshed. Implementations MAY choose to initiate re-authentication some time before the actual expiration. This can remedy clock skew between the TLS-KDH client and server, which might otherwise lead to undesired connection reset. Note that this facility can form a potent combination with DTLS [RFC6347] by using UDP or SCTP to carry sessions that are dormant for long periods, with occasional bursts of data. Such sessions are pre- validated, carrying data bursts that share the same credentials, that behave as though they were cached. Only for reasons of session key expiration must such credentials be occasionally refreshed. Van Rein Expires April 3, 2016 [Page 17] Internet-Draft TLS-KDH October 2015 14. Mandatody CipherSuites TLS and Kerberos have long been independent infrastructures for secure connectivity; with the introduction of the TLS-KDH CipherSuites in this specification, the worlds can merge elegantly. The newly introduced CipherSuites are expected to integrate relatively straightforwardly with any TLS stack. Just like the TLS-KDH CipherSuites are optimal to implement in TLS stacks, TLS-KDH should not force all Kerberos applications to process the full potential of TLS, especially not public key cryptography and the complexity of proper validation of X.509 certificates. Some applications simply want to use Kerberos in a standardised protocol, without any added CipherSuites. For such applications, we hereby introduce a TLS application profile under which such applications can stand on their own: o Based on TLS 1.2 or newer; o Negotiating a verify_data_size as suggested above; o Supporting the TLS-KDH CipherSuites; o Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA CipherSuite that is mandatory in the default TLS application profile [Section 9 of [RFC5246]]; o This application profile will be known as the "TLS-KDH Application Profile". The TLS-KDH CipherSuites can be used with any TLS application profile; that includes, but is not limited to, the one specified above and the default application profile. 15. Comparison to Earlier Work An older specification [RFC2712] introduces Kerberos into TLS. This specification improves on that work in a number of ways: o The pre-master secret is no longer sent to the server under encryption with the KDC-provided session key; instead, Perfect Forward Secrecy is supported through a Diffie-Hellman key exchange; o The authenticator following the Kerberos ticket is made obligatory, as it is an intrinsic part of the mutual authentication between TLS client and TLS server to protect all in-transit application data; Van Rein Expires April 3, 2016 [Page 18] Internet-Draft TLS-KDH October 2015 o The mutual authentication of TLS client and TLS server is established by TLS-KDH CipherSuites that define a stronger Finished message size; o The service name is not statically set to the literal "host", but both the TLS client and TLS service assume an application context to provide the service name to be used; o Support for modern TLS CipherSuites has been added as TLS-KDH CipherSuites, and support for ones that are currently considered deprecated or insecure have been removed; o There is no need to implement a replay cache, which means that more efficient implementation is possible, certainly on highly active and/or replicated TLS-KDH server systems. 16. Efficiency Considerations The efficiency of the mechanism described here compares favourably with the more common approach of authentication through X.509 certificates. The Kerberos mechanism is founded on symmetric cryptography, making it much more efficient than the asymmetric algorithms that are used with X.509 certificates. Furthermore, Kerberos' identity statements are short-lived, which is generally accepted to evade the need for withdrawal mechanisms based on chains of trust, CRLs [RFC3280], OCSP [RFC6960], DANE [RFC6698] and perhaps other mechanisms. As a result, the validity of a Kerberos ticket can be checked with relatively modest computational effort. The inclusion of ephemeral Diffie-Hellman is a relatively expensive asymmetric operation, but the same introduction is needed when Perfect Forward Secrecy is introduced alongside X.509-based authentication. The one thing that is costly about Kerberos is its reliance on a replay cache. Such caches store recent authentication attempts to avoid that they are being replayed; an accurate clock helps to release entries, but some care for clock skew between TLS-KDH client and server must be resolved with these caches. Their volatile nature makes them a particularly difficult problem in highly active and/or replicated and/or distributed Kerberos services. A replay cache is not required for TLS-KDH, because this specification requires that the server uses a fresh Diffie-Hellman public key for every connection. This is of particular use to redundant (and possibly distributed) server farms, where sharing the Van Rein Expires April 3, 2016 [Page 19] Internet-Draft TLS-KDH October 2015 time-critical information of the replay cache is a performance bottle neck. Since this is a new specification, there is no need to implement backward compatibility with older mechanisms for which a replay cache might be needed. 17. Privacy Considerations The information that is publicly shown in the TLS-KDH protocol consists of: o Supported protocol versions, TLS extensions and CipherSuites o The server's principal name, host name and service name A Kerberos ticket transmits less information in plaintext than an X.509 client certificate; furthermore, DNS may have to reveal the realm name(s) of server-trusted KDC(s) but neither the TLS-KDH server nor any KDC publishes long-lasting key material for TLS or Kerberos, so parties looking for a cracking challenge are constrained to a very brief period of attack on keys. TODO: In classical Kerberos setups, the ticket must provide a few handles in plaintext to be able to locate the service key for decrypting the KDC-encrypted ticket parts. However, given that we usually provide a Server Name Indiction, it might be possible to remove the realm and sname parts from the ticket. That data, or other ways to reference the service key, could be incorporated into the server configuration. This does not bring much, since (specifically) the realm will often be configured in DNS. However, for access to local services using the client's own realm, this might be useful. Note that the protocol is somewhat linked to the port being accessed, so that too isn't much of a leak. When it is done within the same TLS connection and uses secure renegotiation [RFC5746], it should not pose a privacy problem if only the server reuses a Diffie-Hellman public key during the renegotiation within the same TLS connection into a TLS-KDH connection. 18. Security Considerations To mutually prove authenticity, the client and server must encrypt respectively decrypt the authenticator attached to the Kerberos ticket. These operations require access to the session key that is provided to client and server in a form that only they can unpack. The Finished messages verify that the two parties have performed the same derivations, which is only possible when it is based on the same Diffie-Hellman shared secret, which in turn can only be found when Van Rein Expires April 3, 2016 [Page 20] Internet-Draft TLS-KDH October 2015 they were provided with the same session key by the KDC. In terms of Kerberos, this implements mutual authentication. Note that TLS-KDH uses the KDC-supplied session key only for encryption on the client, and only for decryption on the server, but since the encryption algorithms are symmetric, these are comparable and there is no need to also encrypt on the server or to decrypt on the client as part of the mutual authentication procedure. In Kerberos, all key material is supplied by the KDC. This is a central point in each realm that is usually guarded well enough, but it is nonetheless a critical point in any infrastructure founded on Kerberos. When client and server are in different realms, but have cross-signed directly or through a chain of KDC's, then all intermediate KDC's are potential places where the session key could be detected. The weakest KDC in the chain then defines the security of the entire chain. Kerberos has introduced numerous refinements that are highly practical in daily use. One worth noting is S4U2Proxy, under which a service can upgrade a received ticket to one with which it can be a client using a new service ticket in the client's name. Such provisions are usually limited in the KDC through Constrained Delegation, but nonetheless it introduces an extra degree of freedom for attackers. Especially dangerous is the combination with S4U2Self, which allows a service to obtain a client ticket without proving (in the Kerberos sense) that the client has actually authenticated to, or even contacted the server. Kerberos requires accurate clocks in order to operate securely; without them, once-used and since-forgotten credentials could be replayed by an attacker that has been able to recover an old service ticket's session key. This problem is worsened in cross-realm scenario's where clock synchronisation is hard to realise. This is however resolved by TLS-KDH, which uses fresh Diffie-Hellman keys for every connection, thus forcing new master secrets on each connection and removing the need for a replay buffer. Note however, that ticket validity times must still be checked, and the use of accurate clocks reduces problems as a result of clock skew. TLS makes use of cryptographic algorithms that tend to be efficient to exploit in a denial-of-service attack. This is indeed a known problem in the operation of TLS. With TLS-KDH, the most-used algorithms are much lighter in weight, and when using a pool of fresh keys, it is possible to recycle the most computationally expensive keys and be left with only relatively lightweight, symmetric computations. Van Rein Expires April 3, 2016 [Page 21] Internet-Draft TLS-KDH October 2015 Basic Kerberos security hinges on the secrecy of the user's password; if this password is guessed, then all captured traffic can be decoded, even in retrospect. This means that it is highly advisable to combine Kerberos with Diffie-Hellman for Perfect Forward Secrecy. TLS-KDH implies this desirable property in all its CipherSuites. 19. IANA Considerations This specification defines a number of CipherSuites that use Kerberos with Diffie-Hellman subkeys as their authentication mechanism. These define the initial list of what is referred to as "TLS-KDH CipherSuites" in this specification: +------+----------------------------------+----------------+--------+ | Valu | CipherSuite description | verify_data_le | DTLS- | | e | | ngth | OK | +------+----------------------------------+----------------+--------+ | TBD | TLS_DHE_KRB_WITH_IDEA_CBC_SHA | 16 | Y | | TBD | TLS_DHE_KRB_WITH_AES_128_CBC_SHA | 16 | Y | | TBD | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32 | Y | | TBD | TLS_DHE_KRB_WITH_AES_128_CBC_SHA | 16 | Y | | | 256 | | | | TBD | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32 | Y | | | 384 | | | | TBD | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32 | Y | | | 256 | | | | TBD | TLS_DHE_KRB_WITH_AES_128_GCM_SHA | 16 | Y | | | 256 | | | | TBD | TLS_DHE_KRB_WITH_AES_256_GCM_SHA | 32 | Y | | | 384 | | | | TBD | TLS_DHE_KRB_WITH_CAMELLIA_128_CB | 16 | Y | | | C_SHA | | | | TBD | TLS_DHE_KRB_WITH_CAMELLIA_256_CB | 32 | Y | | | C_SHA | | | | TBD | TLS_DHE_KRB_WITH_CAMELLIA_128_CB | 16 | Y | | | C_SHA256 | | | | TBD | TLS_DHE_KRB_WITH_CAMELLIA_256_CB | 32 | Y | | | C_SHA256 | | | | TBD | TLS_DHE_KRB_WITH_ARIA_128_CBC_SH | 16 | Y | | | A256 | | | | TBD | TLS_DHE_KRB_WITH_ARIA_256_CBC_SH | 32 | Y | | | A384 | | | | TBD | TLS_DHE_KRB_WITH_ARIA_128_GCM_SH | 16 | Y | | | A256 | | | | TBD | TLS_DHE_KRB_WITH_ARIA_256_GCM_SH | 32 | Y | | | A384 | | | | TBD | TLS_DHE_KRB_WITH_AES_128_CCM | 16 | Y | | TBD | TLS_DHE_KRB_WITH_AES_256_CCM | 32 | Y | Van Rein Expires April 3, 2016 [Page 22] Internet-Draft TLS-KDH October 2015 | TBD | TLS_DHE_KRB_WITH_AES_128_CCM_8 | 16 | Y | | TBD | TLS_DHE_KRB_WITH_AES_256_CCM_8 | 32 | Y | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16 | Y | | | GCM_SHA256 | | | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32 | Y | | | GCM_SHA384 | | | | TBD | TLS_ECDHE_KRB_WITH_AES_128_CCM | 16 | Y | | TBD | TLS_ECDHE_KRB_WITH_AES_256_CCM | 32 | Y | | TBD | TLS_ECDHE_KRB_WITH_AES_128_CCM_8 | 16 | Y | | TBD | TLS_ECDHE_KRB_WITH_AES_256_CCM_8 | 32 | Y | | TBD | TLS_ECDHE_KRB_WITH_AES_128_GCM_S | 16 | Y | | | HA256 | | | | TBD | TLS_ECDHE_KRB_WITH_AES_256_GCM_S | 32 | Y | | | HA384 | | | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16 | Y | | | CBC_SHA | | | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32 | Y | | | CBC_SHA | | | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16 | Y | | | CBC_SHA256 | | | | TBD | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32 | Y | | | CBC_SHA256 | | | | TBD | TLS_ECDHE_KRB_WITH_ARIA_128_CBC_ | 16 | Y | | | SHA256 | | | | TBD | TLS_ECDHE_KRB_WITH_ARIA_256_CBC_ | 32 | Y | | | SHA384 | | | | TBD | TLS_ECDHE_KRB_WITH_ARIA_128_GCM_ | 16 | Y | | | SHA256 | | | | TBD | TLS_ECDHE_KRB_WITH_ARIA_256_GCM_ | 32 | Y | | | SHA384 | | | +------+----------------------------------+----------------+--------+ [TODO: 3DES_EDE_CBC is not included anymore] [TODO: SEED does not seem to get updates, so it is not included here] [TODO: Should we still define 160-bit _SHA CipherSuites?] [TODO: Should we still define CBC encryption modes? They'll probably be removed in TLS 1.3 anyway. BEAST attacks TLS < 1.1 so that is not an issue here; Lucky 13 probably applies.] [TODO: MIT suggests dropping DHE and just to support ECDHE in [KRB5-KDH]; the same would apply here.] Van Rein Expires April 3, 2016 [Page 23] Internet-Draft TLS-KDH October 2015 20. References 20.1. Normative References [KRB5-KDH] Van Rein, R., "KRB5-KDH: Cryptographically binding Kerberos with Diffie-Hellman", October 2014. [KREALM] Van Rein, R., "Kerberos Realm Descriptors in DNS (KREALM)", September 2015. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, . [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/ RFC4343, January 2006, . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos Principal Name Canonicalization and Cross-Realm Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, . Van Rein Expires April 3, 2016 [Page 24] Internet-Draft TLS-KDH October 2015 [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011, . 20.2. Informative References [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, DOI 10.17487/RFC2712, October 1999, . [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, DOI 10.17487/RFC3280, April 2002, . [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, DOI 10.17487/ RFC4282, December 2005, . [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . Van Rein Expires April 3, 2016 [Page 25] Internet-Draft TLS-KDH October 2015 Appendix A. Acknowledgements Thanks go to Simo Sorce for useful discussions during the creation of this document. Author's Address Rick van Rein ARPA2.net Haarlebrink 5 Enschede, Overijssel 7544 WP The Netherlands Email: rick@openfortress.nl Van Rein Expires April 3, 2016 [Page 26]