7Internet Engineering Task Force (IETF) J. Altman
8Request for Comments: 5929 Secure Endpoints
9Category: Standards Track N. Williams
15 Channel Bindings for TLS
19 This document defines three channel binding types for Transport Layer
20 Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
21 telnet, in accordance with RFC 5056 (On Channel Binding).
23 Note that based on implementation experience, this document changes
24 the original definition of 'tls-unique' channel binding type in the
25 channel binding type IANA registry.
29 This is an Internet Standards Track document.
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 Internet Standards is available in Section 2 of RFC 5741.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc5929.
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
58Altman, et al. Standards Track [Page 1]
60RFC 5929 TLS Channel Bindings July 2010
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 2. Conventions Used in This Document ...............................3
79 3. The 'tls-unique' Channel Binding Type ...........................3
80 3.1. Description ................................................3
81 3.2. Registration ...............................................4
82 4. The 'tls-server-end-point' Channel Binding Type .................5
83 4.1. Description ................................................5
84 4.2. Registration ...............................................6
85 5. The 'tls-unique-for-telnet' Channel Binding Type ................6
86 5.1. Description ................................................7
87 5.2. Registration ...............................................7
88 6. Applicability of TLS Channel Binding Types ......................7
89 7. Required Application Programming Interfaces ....................10
90 8. Description of Backwards-Incompatible Changes Made
91 Herein to 'tls-unique' .........................................10
92 9. IANA Considerations ............................................11
93 10. Security Considerations .......................................11
94 10.1. Cryptographic Algorithm Agility ..........................12
95 10.2. On Disclosure of Channel Bindings Data by
96 Authentication Mechanisms ................................12
97 11. References ....................................................13
98 11.1. Normative References .....................................13
99 11.2. Informative References ...................................14
114Altman, et al. Standards Track [Page 2]
116RFC 5929 TLS Channel Bindings July 2010
121 Subsequent to the publication of "On Channel Bindings" [RFC5056],
122 three channel binding types for Transport Layer Security (TLS) were
123 proposed, reviewed, and added to the IANA channel binding type
124 registry, all in accordance with [RFC5056]. Those channel binding
125 types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-
126 telnet'. It has become desirable to have these channel binding types
127 re-registered through an RFC so as to make it easier to reference
128 them, and to correct them to describe actual implementations. This
129 document does just that. The authors of those three channel binding
130 types have transferred, or have indicated that they will transfer,
131 "ownership" of those channel binding types to the IESG.
133 We also provide some advice on the applicability of these channel
134 binding types, as well as advice on when to use which. Additionally,
135 we provide an abstract API that TLS implementors should provide, by
136 which to obtain channel bindings data for a TLS connection.
138 WARNING: it turns out that the first implementor implemented and
139 deployed something rather different than what was described in the
140 IANA registration for 'tls-unique'. Subsequently, it was decided
141 that we should adopt that form of 'tls-unique'. This means that this
142 document makes a backwards-incompatible change to 'tls-unique'. See
143 Section 8 for more details.
1452. Conventions Used in This Document
147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
149 document are to be interpreted as described in [RFC2119].
1513. The 'tls-unique' Channel Binding Type
153 IANA updated the registration of the 'tls-unique' channel binding
154 type to match the description below. There are material and
155 substantial changes from the original registration, both in the
156 description as well as registration meta-data (such as registration
161 Description: The first TLS Finished message sent (note: the Finished
162 struct, not the TLS record layer message containing it) in the most
163 recent TLS handshake of the TLS connection being bound to (note: TLS
164 connection, not session, so that the channel binding is specific to
165 each connection regardless of whether session resumption is used).
166 If TLS renegotiation takes place before the channel binding
170Altman, et al. Standards Track [Page 3]
172RFC 5929 TLS Channel Bindings July 2010
175 operation, then the first TLS Finished message sent of the latest/
176 inner-most TLS connection is used. Note that for full TLS
177 handshakes, the first Finished message is sent by the client, while
178 for abbreviated TLS handshakes (session resumption), the first
179 Finished message is sent by the server.
181 WARNING: The definition, security, and interoperability
182 considerations of this channel binding type have changed since the
183 original registration. Implementors should read the document that
184 last updated this registration for more information.
186 Interoperability note:
188 This definition of 'tls-unique' means that a channel's bindings
189 data may change over time, which in turn creates a synchronization
190 problem should the channel's bindings data change between the time
191 that the client initiates authentication with channel binding and
192 the time that the server begins to process the client's first
193 authentication message. If that happens, the authentication
194 attempt will fail spuriously.
196 Based on the fact that while servers may request TLS
197 renegotiation, only clients may initiate it, this synchronization
198 problem can be avoided by clients and servers as follows: server
199 applications MUST NOT request TLS renegotiation during phases of
200 the application protocol during which application-layer
201 authentication occurs. Client applications SHOULD NOT initiate
202 TLS renegotiation between the start and completion of
205 The rationale for making the server behavior a requirement while
206 the client behavior is only a recommendation is that there
207 typically exist TLS APIs for requesting renegotiation on the
208 server side of a TLS connection, while many client TLS stacks do
209 not provide fine-grained control over when TLS renegotiation
212 Application protocols SHOULD be designed in such a way that a
213 server would never need to request TLS renegotiation immediately
214 before or during application-layer authentication.
218 o Channel binding unique prefix: tls-unique
220 o Channel binding type: unique
222 o Channel type: TLS [RFC5246]
226Altman, et al. Standards Track [Page 4]
228RFC 5929 TLS Channel Bindings July 2010
231 o Published specification: <RFC 5929>
233 o Channel binding is secret: no
235 o Description: <See specification>
237 o Intended usage: COMMON
239 o Person and email address to contact for further information: Larry
240 Zhu (larry.zhu@microsoft.com), Nicolas Williams
241 (Nicolas.Williams@oracle.com).
243 o Owner/Change controller name and email address: IESG.
245 o Expert reviewer name and contact information: IETF TLS WG
246 (tls@ietf.org, failing that, ietf@ietf.org)
248 o Note: see the published specification for advice on the
249 applicability of this channel binding type.
2514. The 'tls-server-end-point' Channel Binding Type
253 IANA updated the registration of the 'tls-server-end-point' channel
254 binding type to match the description below. Note that the only
255 material changes from the original registration are: the "owner" (now
256 the IESG), the contacts, the published specification, and a note
257 indicating that the published specification should be consulted for
258 applicability advice. References were added to the description. All
259 other fields of the registration are copied here for the convenience
264 Description: The hash of the TLS server's certificate [RFC5280] as it
265 appears, octet for octet, in the server's Certificate message. Note
266 that the Certificate message contains a certificate_list, in which
267 the first element is the server's certificate.
269 The hash function is to be selected as follows:
271 o if the certificate's signatureAlgorithm uses a single hash
272 function, and that hash function is either MD5 [RFC1321] or SHA-1
273 [RFC3174], then use SHA-256 [FIPS-180-3];
275 o if the certificate's signatureAlgorithm uses a single hash
276 function and that hash function neither MD5 nor SHA-1, then use
277 the hash function associated with the certificate's
282Altman, et al. Standards Track [Page 5]
284RFC 5929 TLS Channel Bindings July 2010
287 o if the certificate's signatureAlgorithm uses no hash functions or
288 uses multiple hash functions, then this channel binding type's
289 channel bindings are undefined at this time (updates to is channel
290 binding type may occur to address this issue if it ever arises).
292 The reason for using a hash of the certificate is that some
293 implementations need to track the channel binding of a TLS session in
294 kernel-mode memory, which is often at a premium.
298 o Channel binding unique prefix: tls-server-end-point
300 o Channel binding type: end-point
302 o Channel type: TLS [RFC5246]
304 o Published specification: <RFC 5929>
306 o Channel binding is secret: no
308 o Description: <See specification>
310 o Intended usage: COMMON
312 o Person and email address to contact for further information: Larry
313 Zhu (larry.zhu@microsoft.com), Nicolas Williams
314 (Nicolas.Williams@oracle.com).
316 o Owner/Change controller name and email address: IESG.
318 o Expert reviewer name and contact information: IETF TLS WG
319 (tls@ietf.org, failing that, ietf@ietf.org)
321 o Note: see the published specification for advice on the
322 applicability of this channel binding type.
3245. The 'tls-unique-for-telnet' Channel Binding Type
326 IANA updated the registration of the 'tls-unique-for-telnet' channel
327 binding type to match the description below. Note that the only
328 material changes from the original registration are: the "owner" (now
329 the IESG), the contacts, the published specification, and a note
330 indicating that the published specification should be consulted for
331 applicability advice. The description is also clarified. We also
332 moved the security considerations notes to the security
333 considerations section of this document. All other fields of the
334 registration are copied here for the convenience of readers.
338Altman, et al. Standards Track [Page 6]
340RFC 5929 TLS Channel Bindings July 2010
345 Description: There is a proposal for adding a "StartTLS" extension to
346 TELNET, and a channel binding extension for the various TELNET AUTH
347 mechanisms whereby each side sends the other a "checksum" (MAC --
348 message authentication code) of their view of the channel's bindings.
349 The client uses the TLS Finished messages (note: the Finished struct)
350 sent by the client and server, each concatenated in that order and in
351 their clear text form, of the first TLS handshake to which the
352 connection is being bound. The server does the same but in the
353 opposite concatenation order (server, then client).
357 o Channel binding unique prefix: tls-unique-for-telnet
359 o Channel binding type: unique
361 o Channel type: TLS [RFC5246]
363 o Published specification: <RFC 5929>
365 o Channel binding is secret: no
367 o Description: <See specification>
369 o Intended usage: COMMON
371 o Person and email address to contact for further information: Jeff
372 Altman (jaltman@secure-endpoints.com), Nicolas Williams
373 (Nicolas.Williams@oracle.com).
375 o Owner/Change controller name and email address: IESG.
377 o Expert reviewer name and contact information: IETF TLS WG
378 (tls@ietf.org, failing that, ietf@ietf.org)
380 o Note: see the published specification for advice on the
381 applicability of this channel binding type.
3836. Applicability of TLS Channel Binding Types
385 The 'tls-unique-for-telnet' channel binding type is only applicable
386 to TELNET [RFC0854] and is available for all TLS connections.
388 The 'tls-unique' channel binding type is available for all TLS
389 connections, while 'tls-server-end-point' is only available when TLS
390 cipher suites with server certificates are used, specifically: cipher
394Altman, et al. Standards Track [Page 7]
396RFC 5929 TLS Channel Bindings July 2010
399 suites that use the Certificate handshake message, which typically
400 involve the use of PKIX [RFC5280]. For example, 'tls-server-end-
401 point' is available when using TLS ciphers suites such as (this is
402 not an exhaustive list):
412 o TLS_ECDHE_ECDSA_WITH_*
414 o TLS_ECDHE_RSA_WITH_*
416 o TLS_ECDH_ECDSA_WITH_*
418 o TLS_ECDH_RSA_WITH_*
424 o TLS_SRP_SHA_DSS_WITH_*
426 o TLS_SRP_SHA_RSA_WITH_*
428 but is not available when using TLS cipher suites such as (this is
429 not an exhaustive list):
435 o TLS_ECDHE_PSK_WITH_*
437 o TLS_ECDH_anon_WITH_*
450Altman, et al. Standards Track [Page 8]
452RFC 5929 TLS Channel Bindings July 2010
455 'tls-server-end-point' is also not applicable for use with OpenPGP
456 server certificates [RFC5081] [RFC4880] (since these don't use the
457 Certificate handshake message).
459 Therefore, 'tls-unique' is applicable to more contexts than 'tls-
460 server-end-point'. However, 'tls-server-end-point' may be used with
461 existing TLS server-side proxies ("concentrators") without
462 modification to the proxies, whereas 'tls-unique' may require
463 firmware or software updates to server-side proxies. Therefore there
464 may be cases where 'tls-server-end-point' may interoperate but where
465 'tls-unique' may not.
467 Also, authentication mechanisms may arise that depend on channel
468 bindings to contribute entropy, in which case unique channel bindings
469 would always have to be used in preference to end-point channel
470 bindings. At this time there are no such mechanisms, though one such
471 SASL mechanism has been proposed. Whether such mechanisms should be
472 allowed is out of scope for this document.
474 For many applications, there may be two or more potentially
475 applicable TLS channel binding types. Existing security frameworks
476 (such as the GSS-API [RFC2743] or the SASL [RFC4422] GS2 framework
477 [RFC5801]) and security mechanisms generally do not support
478 negotiation of channel binding types. Therefore, application peers
479 need to agree a priori as to what channel binding type to use (or
480 agree to rules for deciding what channel binding type to use).
482 The specifics of whether and how to negotiate channel binding types
483 are beyond the scope of this document. However, it is RECOMMENDED
484 that application protocols making use of TLS channel bindings, use
485 'tls-unique' exclusively, except, perhaps, where server-side proxies
486 are common in deployments of an application protocol. In the latter
487 case an application protocol MAY specify that 'tls-server-end-point'
488 channel bindings must be used when available, with 'tls-unique' being
489 used when 'tls-server-end-point' channel bindings are not available.
490 Alternatively, the application may negotiate which channel binding
491 type to use, or may make the choice of channel binding type
494 Specifically, application protocol specifications MUST indicate at
495 least one mandatory to implement channel binding type, MAY specify a
496 negotiation protocol, MAY allow for out-of-band negotiation or
497 configuration, and SHOULD have a preference for 'tls-unique' over
498 'tls-server-end-point'.
506Altman, et al. Standards Track [Page 9]
508RFC 5929 TLS Channel Bindings July 2010
5117. Required Application Programming Interfaces
513 TLS implementations supporting the use of 'tls-unique' and/or 'tls-
514 unique-for-telnet' channel binding types MUST provide application
515 programming interfaces by which applications (clients and servers
516 both) may obtain the channel bindings for a TLS connection. Such
517 interfaces may be expressed in terms of extracting the channel
518 bindings data for a given connection and channel binding type.
519 Alternatively, the implementor may provide interfaces by which to
520 obtain the initial client Finished message, the initial server
521 Finished message, and/or the server certificate (in a form that
522 matches the description of the 'tls-server-end-point' channel binding
523 type). In the latter case, the application has to have knowledge of
524 the channel binding type descriptions from this document. This
525 document takes no position on which form these application
526 programming interfaces must take.
528 TLS implementations supporting TLS renegotiation SHOULD provide APIs
529 that allow applications to control when renegotiation can take place.
530 For example, a TLS client implementation may provide a "callback"
531 interface to indicate that the server requested renegotiation, but
532 may not start renegotiation until the application calls a function to
533 indicate that now is a good time to renegotiate.
5358. Description of Backwards-Incompatible Changes Made Herein to
538 The original description of 'tls-unique' read as follows:
540 |OLD| Description: The client's TLS Finished message (note: the
541 |OLD| Finished struct) from the first handshake of the connection
542 |OLD| (note: connection, not session, so that the channel binding
543 |OLD| is specific to each connection regardless of whether session
544 |OLD| resumption is used).
546 Original 'tls-unique' description
548 In other words: the client's Finished message from the first
549 handshake of a connection, regardless of whether that handshake was a
550 full or abbreviated handshake, and regardless of how many subsequent
551 handshakes (renegotiations) might have followed.
553 As explained in Section 1, this is no longer the description of 'tls-
554 unique', and the new description is not backwards compatible with the
555 original except in the case of TLS connections where: a) only one
556 handshake has taken place before application-layer authentication,
557 and b) that one handshake was a full handshake.
562Altman, et al. Standards Track [Page 10]
564RFC 5929 TLS Channel Bindings July 2010
567 This change has a number of implications:
569 o Backwards-incompatibility. It is possible that some
570 implementations of the original 'tls-unique' channel binding type
571 have been deployed. We know of at least one TLS implementation
572 that exports 'tls-unique' channel bindings with the original
573 semantics, but we know of no deployed application using the same.
574 Implementations of the original and new 'tls-unique' channel
575 binding type will only interoperate when: a) full TLS handshakes
576 are used, and b) TLS renegotiation is not used.
578 o Security considerations -- see Section 10.
580 o Interoperability considerations. As described in Section 3, the
581 new definition of the 'tls-unique' channel binding type has an
582 interoperability problem that may result in spurious
583 authentication failures unless the application implements one or
584 both of the techniques described in that section.
5869. IANA Considerations
588 IANA updated three existing channel binding type registrations. See
589 the rest of this document.
59110. Security Considerations
593 The Security Considerations sections of [RFC5056], [RFC5246], and
594 [RFC5746] apply to this document.
596 The TLS Finished messages (see Section 7.4.9 of [RFC5246]) are known
597 to both endpoints of a TLS connection and are cryptographically bound
598 to it. For implementations of TLS that correctly handle
599 renegotiation [RFC5746], each handshake on a TLS connection is bound
600 to the preceding handshake, if any. Therefore, the TLS Finished
601 messages can be safely used as a channel binding provided that the
602 authentication mechanism doing the channel binding conforms to the
603 requirements in [RFC5056]. Applications utilizing 'tls-unique'
604 channel binding with TLS implementations without support for secure
605 renegotiation [RFC5746] MUST ensure that ChangeCipherSpec has been
606 used in any and all renegotiations prior to application-layer
607 authentication, and MUST discard any knowledge learned from the
608 server prior to the completion of application-layer authentication.
610 The server certificate, when present, is also cryptographically bound
611 to the TLS connection through its use in key transport and/or
612 authentication of the server (either by dint of its use in key
613 transport, by its use in signing key agreement, or by its use in key
618Altman, et al. Standards Track [Page 11]
620RFC 5929 TLS Channel Bindings July 2010
623 agreement). Therefore, the server certificate is suitable as an end-
624 point channel binding as described in [RFC5056].
62610.1. Cryptographic Algorithm Agility
628 The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do
629 not add any use of cryptography beyond that used by TLS itself.
630 Therefore, these two channel binding types add no considerations with
631 respect to cryptographic algorithm agility.
633 The 'tls-server-end-point' channel binding type consists of a hash of
634 a server certificate. The reason for this is to produce manageably
635 small channel binding data, as some implementations will be using
636 kernel-mode memory (which is typically scarce) to store these. This
637 use of a hash algorithm is above and beyond TLS's use of
638 cryptography, therefore the 'tls-server-end-point' channel binding
639 type has a security consideration with respect to hash algorithm
640 agility. The algorithm to be used, however, is derived from the
641 server certificate's signature algorithm as described in Section 4.1;
642 to recap: use SHA-256 if the certificate signature algorithm uses MD5
643 or SHA-1, else use whatever hash function the certificate uses
644 (unless the signature algorithm uses no hash functions or more than
645 one hash function, in which case 'tls-server-end-point' is
646 undefined). The construction of 'tls-server-end-point' channel
647 bindings is not directly hash-agile (since no negotiation of hash
648 function is provided for), but it is hash-agile nonetheless. The
649 hash agility of 'tls-server-end-point' channel bindings derives from
652 Current proposals for randomized signatures algorithms [RHASH]
653 [NIST-SP.800-106.2009] use hash functions in their construction -- a
654 single hash function in each algorithm. Therefore, the 'tls-server-
655 end-point' channel binding type should be available even in cases
656 where new signatures algorithms are used that are based on current
657 randomized hashing proposals (but we cannot guarantee this, of
66010.2. On Disclosure of Channel Bindings Data by Authentication
663 When these channel binding types were first considered, one issue
664 that some commenters were concerned about was the possible impact on
665 the security of the TLS channel, of disclosure of the channel
666 bindings data by authentication mechanisms. This can happen, for
667 example, when an authentication mechanism transports the channel
668 bindings data, with no confidentiality protection, over other
669 transports (for example, in communicating with a trusted third
670 party), or when the TLS channel provides no confidentiality
674Altman, et al. Standards Track [Page 12]
676RFC 5929 TLS Channel Bindings July 2010
679 protection and the authentication mechanism does not protect the
680 confidentiality of the channel bindings data. This section considers
683 When the TLS connection uses a cipher suite that does not provide
684 confidentiality protection, the TLS Finished messages will be visible
685 to eavesdroppers, regardless of what the authentication mechanism
686 does. The same is true of the server certificate which, in any case,
687 is generally visible to eavesdroppers. Therefore we must consider
688 our choices of TLS channel bindings here to be safe to disclose by
689 definition -- if that were not the case, then TLS with cipher suites
690 that don't provide confidentiality protection would be unsafe.
691 Furthermore, the TLS Finished message construction depends on the
692 security of the TLS PRF, which in turn needs to be resistant to key
693 recovery attacks, and we think that it is, as it is based on HMAC,
694 and the master secret is, well, secret (and the result of key
697 Note too that in the case of an attempted active man-in-the-middle
698 attack, the attacker will already possess knowledge of the TLS
699 Finished messages for both inbound and outbound TLS channels (which
700 will differ, given that the attacker cannot force them to be the
701 same). No additional information is obtained by the attacker from
702 the authentication mechanism's disclosure of channel bindings data --
703 the attacker already has it, even when cipher suites providing
704 confidentiality protection are provided.
706 None of the channel binding types defined herein produce channel
707 bindings data that must be kept secret. Moreover, none of the
708 channel binding types defined herein can be expected to be private
709 (known only to the end-points of the channel), except that the unique
710 TLS channel binding types can be expected to be private when a cipher
711 suite that provides confidentiality protection is used to protect the
712 Finished message exchanges and the application data records
713 containing application-layer authentication messages.
71711.1. Normative References
719 [FIPS-180-3] United States of America, National Institute
720 of Standards and Technology, "Secure Hash
721 Standard", Federal Information Processing
722 Standard (FIPS) 180-3, October 2008.
724 [RFC2119] Bradner, S., "Key words for use in RFCs to
725 Indicate Requirement Levels", BCP 14,
726 RFC 2119, March 1997.
730Altman, et al. Standards Track [Page 13]
732RFC 5929 TLS Channel Bindings July 2010
735 [RFC5056] Williams, N., "On the Use of Channel Bindings
736 to Secure Channels", RFC 5056, November 2007.
738 [RFC5246] Dierks, T. and E. Rescorla, "The Transport
739 Layer Security (TLS) Protocol Version 1.2",
740 RFC 5246, August 2008.
742 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N.
743 Oskov, "Transport Layer Security (TLS)
744 Renegotiation Indication Extension",
745 RFC 5746, February 2010.
74711.2. Informative References
749 [NIST-SP.800-106.2009] National Institute of Standards and
750 Technology, "NIST Special Publication 800-
751 106: Randomized Hashing for Digital
752 Signatures", February 2009.
754 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
755 Specification", STD 8, RFC 854, May 1983.
757 [RFC1321] Rivest, R., "The MD5 Message-Digest
758 Algorithm", RFC 1321, April 1992.
760 [RFC2743] Linn, J., "Generic Security Service
761 Application Program Interface Version 2,
762 Update 1", RFC 2743, January 2000.
764 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash
765 Algorithm 1 (SHA1)", RFC 3174,
768 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed.,
769 "Simple Authentication and Security Layer
770 (SASL)", RFC 4422, June 2006.
772 [RFC4880] Callas, J., Donnerhacke, L., Finney, H.,
773 Shaw, D., and R. Thayer, "OpenPGP Message
774 Format", RFC 4880, November 2007.
776 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys
777 for Transport Layer Security (TLS)
778 Authentication", RFC 5081, November 2007.
786Altman, et al. Standards Track [Page 14]
788RFC 5929 TLS Channel Bindings July 2010
791 [RFC5280] Cooper, D., Santesson, S., Farrell, S.,
792 Boeyen, S., Housley, R., and W. Polk,
793 "Internet X.509 Public Key Infrastructure
794 Certificate and Certificate Revocation List
795 (CRL) Profile", RFC 5280, May 2008.
797 [RFC5801] Josefsson, S. and N. Williams, "Using Generic
798 Security Service Application Program
799 Interface (GSS-API) Mechanisms in Simple
800 Authentication and Security Layer (SASL): The
801 GS2 Mechanism Family", RFC 5801, July 2010.
803 [RHASH] Halevi, S. and H. Krawczyk, "Strengthening
804 Digital Signatures via Randomized Hashing",
805 Work in Progress, October 2007.
815 EMail: jaltman@secure-endpoints.com
824 EMail: Nicolas.Williams@oracle.com
828 Microsoft Corporation
833 EMail: larry.zhu@microsoft.com
842Altman, et al. Standards Track [Page 15]