Re: [TLS] [sasl] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)

[<[e-mail]>]

A question for SASL: both GS2 and SCRAM are currently in
RFC Editor AUTH48, and they have a normative reference
to the IANA registration page for 'tls-unique'.

Since it appears we're about to change that registration
quite radically, what's the impact on GS2/SCRAM? Have GS2
and/or SCRAM implementors implemented the 'tls-unique'
binding?

And should we publish the RFCs at this time, if we know one
of the normative references is, well, unstable (likely to
change in non-backward-compatible way soon)?

Best regards,
Pasi

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Nicolas Williams
> Sent: 18 March, 2010 01:15
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [sasl] Updates to draft-altman-tls-channel-bindings (PLEASE
> REVIEW)
>
> Now that TLS re-negotiation security (RFC5746) is done we need to
> finish
> draft-altman-tls-channel-bindings.
>
> It's become clear that MSFT implemented and deployed something slightly
> different than the 'tls-unique' binding description that had been
> registered.  They seem to be the only implementors to date; their
> implementation is secure, therefore I propose that we simply modify the
> description of 'tls-unique' and be done.
>
> The differences are:
>
>  - it's not always the client's Finished message, but the _first_
>    Finished message in the relevant handshake (in a session resumption
>    handshake the server sends its Finished message first);
>
>  - the Finished message is taken from the latest/inner-most TLS
>    handshake, rather than the outer-most one
>
> For the most common case, where there's no TLS re-negotiation and no
> TLS
> session resumption, there is no difference.
>
> It's past the I-D submission cut-off, so I can't submit an updated I-D.
> Below are the full diffs from -07 to the -08 to-be.
>
> Please review,
>
> Nico
>
>
> --- altman-tls-channel-bindings-07.unpg       Wed Mar 17 13:32:15 2010
> +++ altman-tls-channel-bindings-08.unpg       Wed Mar 17 13:32:51 2010
> @@ -1,594 +1,603 @@
>
>
>
>  NETWORK WORKING GROUP                                          J.
> Altman
>  Internet-Draft                                          Secure
> Endpoints
>  Intended status: Standards Track                             N.
> Williams
> -Expires: April 4, 2010
> Sun
> +Expires: September 18, 2010
> Oracle
>                                                                    L.
> Zhu
>                                                     Microsoft
> Corporation
> -                                                            October
> 2009
> +                                                          March 17,
> 2010
>
>
>                          Channel Bindings for TLS
> -                draft-altman-tls-channel-bindings-07.txt
> +                draft-altman-tls-channel-bindings-08.txt
>
>  Status of this Memo
>
>     This Internet-Draft is submitted to IETF in full conformance with
> the
>     provisions of BCP 78 and BCP 79.  This document may contain
> material
>     from IETF Documents or IETF Contributions published or made
> publicly
>     available before November 10, 2008.  The person(s) controlling the
>     copyright in some of this material may not have granted the IETF
>     Trust the right to allow modifications of such material outside the
>     IETF Standards Process.  Without obtaining an adequate license from
>     the person(s) controlling the copyright in such materials, this
>     document may not be modified outside the IETF Standards Process,
> and
>     derivative works of it may not be created outside the IETF
> Standards
>     Process, except to format it for publication as an RFC or to
>     translate it into languages other than English.
>
>     Internet-Drafts are working documents of the Internet Engineering
>     Task Force (IETF), its areas, and its working groups.  Note that
>     other groups may also distribute working documents as Internet-
>     Drafts.
>
>     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."
>
>     The list of current Internet-Drafts can be accessed at
>     http://www.ietf.org/ietf/1id-abstracts.txt.
>
>     The list of Internet-Draft Shadow Directories can be accessed at
>     http://www.ietf.org/shadow.html.
>
> -   This Internet-Draft will expire on April 4, 2010.
> +   This Internet-Draft will expire on September 18, 2010.
>
>  Copyright Notice
>
> -   Copyright (c) 2009 IETF Trust and the persons identified as the
> +   Copyright (c) 2010 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 in effect on the date of
>     publication of this document (http://trustee.ietf.org/license-
> info).
>     Please review these documents carefully, as they describe your
> rights
>     and restrictions with respect to this document.
>
>  Abstract
>
>     This document defines three channel binding types for Transport
> Layer
>     Security (TLS), tls-unique, tls-server-end-point, and tls-unique-
> for-
>     telnet, in accordance with RFC 5056 (On Channel Binding).
>
>
>  Table of Contents
>
>     1.    Conventions used in this document
>     2.    Introduction
>     3.    The 'tls-unique' Channel Binding Type
>     3.1.  Description
>     3.2.  Registration
>     4.    The 'tls-server-end-point' Channel Binding Type
>     4.1.  Description
>     4.2.  Registration
>     5.    The 'tls-unique-for-telnet' Channel Binding Type
>     5.1.  Description
>     5.2.  Registration
>     6.    Applicability of TLS Channel Binding Types
>     7.    Required Application Programming Interfaces
>     8.    IANA Considerations
>     9.    Security Considerations
>     9.1.  Cryptographic Algorithm Agility
>     9.2.  On Disclosure of Channel Bindings Data by Authentication
>           Mechanisms
>     10.   References
>     10.1. Normative References
>     10.2. Normative References for 'tls-server-end-point'
>     10.3. Informative References
>           Authors' Addresses
>
>
>  1.  Conventions used in this document
>
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
>     document are to be interpreted as described in [RFC2119].
>
>
>  2.  Introduction
>
>     Subsequent to the publication of "On Channel Bindings" [RFC5246],
>     three channel binding types for Transport Layer Security (TLS) were
>     proposed, reviewed and added to the IANA channel binding type
>     registry, all in accordance with [RFC5246].  Those channel binding
>     types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-
> for-
>     telnet'.  It has become desirable to have these channel binding
> types
>     re-registered through an RFC so as to make it easier to reference
> -   them.  This document does just that.  The authors of those three
> -   channel binding types have, or have indicated that they will,
> -   transferred "ownership" of those channel binding types to the IESG.
> +   them, and to correct them to describe actual implementations.  This
> +   document does just that.  The authors of those three channel
> binding
> +   types have, or have indicated that they will, transferred
> "ownership"
> +   of those channel binding types to the IESG.
>
>     We also provide some advice on the applicability of these channel
>     binding types, as well as advice on when to use which.  And we
>     provide an abstract API that TLS implementors should provide, by
>     which to obtain channel bindings data for a TLS connection.
>
>
>  3.  The 'tls-unique' Channel Binding Type
>
>     IANA is hereby directed to update the registration of the 'tls-
> -   unique' channel binding type to match the following.  Note that the
> -   only material changes from the original registration should be: the
> -   "owner" (now the IESG), contacts, the published specfication, and a
> -   clarification to the description by the addition of a parenthetical
> -   note (that is, the first such note in the descritption is a new
> -   addition).  We also added a note indicating that this specification
> -   contains applicability advice, and we moved security considerations
> -   notes to the security considerations section of this document.  All
> -   other fields of the registration are copied here for the
> convenience
> -   of readers.
> +   unique' channel binding type to match the following.  There are
> +   material changes from the original registration, both in the
> +   description as well as registration meta-data (such as registration
> +   ownership).
>
>  3.1.  Description
>
> -   Description: The client's TLS Finished message (note: the Finished
> -   struct) from the first handshake of the connection (note:
> connection,
> -   not session, so that the channel binding is specific to each
> -   connection regardless of whether session resumption is used).
> +   Description: The first TLS Finished message sent (note: the
> Finished
> +   struct) in the most recent TLS handshake of the TLS connection
> being
> +   bound to (note: TLS connection, not session, so that the channel
> +   binding is specific to each connection regardless of whether
> session
> +   resumption is used).  If TLS re-negotiation takes place before the
> +   channel binding operation, then the first TLS Finished message sent
> +   of the latest/inner-most TLS connection is used.  Note that for
> full
> +   TLS handshakes the first Finished message is sent by the client,
> +   while for abbreviated TLS handshakes the first Finished message is
> +   sent by the server.
>
>  3.2.  Registration
>
>     o  Channel binding unique prefix: tls-unique
>
>     o  Channel binding type: unique
>
>     o  Channel type: TLS [RFC5246]
>
>     o  Published specification: <this document>
>
>     o  Channel binding is secret: no
>
>     o  Description: <See specification>
>
>     o  Intended usage: COMMON
>
>     o  Person and email address to contact for further information:
> Larry
>        Zhu ([e-mail]), Nicolas Williams
>        ([e-mail]).
>
>     o  Owner/Change controller name and email address: IESG.
>
>     o  Expert reviewer name and contact information: IETF TLS WG
>        ([e-mail], failing that, [e-mail])
>
>     o  Note: see the published specification for advice on the
>        applicability of this channel binding type.
>
>
>  4.  The 'tls-server-end-point' Channel Binding Type
>
>     IANA is hereby directed to update the registration of the 'tls-
>     server-end-point' channel binding type to match the following.
> Note
>     that the only material changes from the original registration
> should
>     be: the "owner" (now the IESG), the contacts, the published
>     specfication, and a note indicating that the published
> specification
>     should be consulted for applicability advice.  References were
> added
>     to the description.  All other fields of the registration are
> copied
>     here for the convenience of readers.
>
>  4.1.  Description
>
>     Description: The hash of the TLS server's certificate [RFC5280] as
> it
>     appears, octet for octet, in the server's Certificate message (note
>     that the Certificate message contains a certificate_list, the first
>     element of which is the server's certificate).
>
>     The hash function is to be selected as follows:
>
>     o  if the certificate's signatureAlgorithm uses a single hash
>        function, and that hash function is either MD5 [RFC1321] or SHA-
> 1
>        [RFC3174] then use SHA-256 [FIPS-180-2];
>
>     o  if the certificate's signatureAlgorithm uses a single hash
>        function and that hash function neither MD5 nor SHA-1, then use
>        the hash function associated with the certificate's
>        signatureAlgorithm;
>
>     o  if the certificate's signatureAlgorithm uses no hash functions
> or
>        multiple hash functions, then this channel binding type's
> channel
>        bindings are undefined at this time (updates to is channel
> binding
>        type may occur to address this issue if it ever arises).
>
>     The reason for using a hash of the certificate is that some
>     implementations need to track the channel binding of a TLS session
> in
>     kernel-mode memory, which is often at a premium.
>
>  4.2.  Registration
>
>     o  Channel binding unique prefix: tls-server-end-point
>
>     o  Channel binding type: end-point
>
>     o  Channel type: TLS [RFC5246]
>
>     o  Published specification: <this document>
>
>     o  Channel binding is secret: no
>
>     o  Description: <See specification>
>
>     o  Intended usage: COMMON
>
>     o  Person and email address to contact for further information:
> Larry
>        Zhu ([e-mail]), Nicolas Williams
>        ([e-mail]).
>
>     o  Owner/Change controller name and email address: IESG.
>
>     o  Expert reviewer name and contact information: IETF TLS WG
>        ([e-mail], failing that, [e-mail])
>
>     o  Note: see the published specification for advice on the
>        applicability of this channel binding type.
>
>
>  5.  The 'tls-unique-for-telnet' Channel Binding Type
>
>     IANA is hereby directed to update the registration of the 'tls-
>     unique-for-telnet' channel binding type to match the following.
> Note
>     that the only material changes from the original registration
> should
>     be: the "owner" (now the IESG), the contacts, the published
>     specfication, and a note indicating that the published
> specification
>     should be consulted for applicability advice.  The description is
>     also clarified.  We also moved security considerations notes to the
>     security considerations section of this document.  All other fields
>     of the registration are copied here for the convenience of readers.
>
>  5.1.  Description
>
>     Description: There is a proposal for adding a "StartTLS" extension
> to
>     TELNET, and a channel binding extension for the various TELNET AUTH
>     mechanisms whereby each side sends the other a "checksum" (MAC) of
> -   their view of the channel's bindings.  The client uses the first
> TLS
> -   Finished messages (note: the Finished struct) from the client and
> -   server, each concatenated in that order and in their clear text
> form.
> -   The server does the same but in the opposite concatenation order
> -   (server, then client).
> +   their view of the channel's bindings.  The client uses the TLS
> +   Finished messages (note: the Finished struct) sent by the client
> and
> +   server, each concatenated in that order and in their clear text
> form,
> +   of the first TLS handshake of the connection being bound to.  The
> +   server does the same but in the opposite concatenation order
> (server,
> +   then client).
>
>  5.2.  Registration
>
>     o  Channel binding unique prefix: tls-unique-for-telnet
>
>     o  Channel binding type: unique
>
>     o  Channel type: TLS [RFC5246]
>
>     o  Published specification: <this document>
>
>     o  Channel binding is secret: no
>
>     o  Description: <See specification>
>
>     o  Intended usage: COMMON
>
>     o  Person and email address to contact for further information:
> Jeff
>        Altman ([e-mail]), Nicolas Williams
>        ([e-mail]).
>
>     o  Owner/Change controller name and email address: IESG.
>
>     o  Expert reviewer name and contact information: IETF TLS WG
>        ([e-mail], failing that, [e-mail])
>
>     o  Note: see the published specification for advice on the
>        applicability of this channel binding type.
>
>
>  6.  Applicability of TLS Channel Binding Types
>
>     The 'tls-unique-for-telnet' channel binding type is only applicable
>     to TELNET [RFC0854], and is available for all TLS connections.
>
>     The 'tls-unique' channel binding type is available for all TLS
>     connections, while 'tls-server-end-point' is only available when
> TLS
>     cipher suites with server certificates are used, specifically:
> cipher
>     suites that use the Certificate handshake message, which typically
>     involve the use of PKIX [RFC5280].  For example, 'tls-server-end-
>     point' is available when using TLS ciphers suites such as (this is
>     not an exhaustive list):
>
>     o  TLS_DHE_DSS_WITH_*
>
>     o  TLS_DHE_RSA_WITH_*
>
>     o  TLS_DH_DSS_WITH_*
>
>     o  TLS_DH_RSA_WITH_*
>
>     o  TLS_ECDHE_ECDSA_WITH_*
>
>     o  TLS_ECDHE_RSA_WITH_*
>
>     o  TLS_ECDH_ECDSA_WITH_*
>
>     o  TLS_ECDH_RSA_WITH_*
>
>     o  TLS_RSA_PSK_WITH_*
>
>     o  TLS_RSA_WITH_*
>
>     o  TLS_SRP_SHA_DSS_WITH_*
>
>     o  TLS_SRP_SHA_RSA_WITH_*
>
>     but is not available when using TLS cipher suites such as (this is
>     not an exhaustive list):
>
>     o  TLS_DHE_PSK_WITH_*
>
>     o  TLS_DH_anon_WITH_*
>
>     o  TLS_ECDHE_PSK_WITH_*
>
>     o  TLS_ECDH_anon_WITH_*
>
>     o  TLS_KRB5_WITH_*
>
>     o  TLS_PSK_WITH_*
>
>     o  TLS_SRP_SHA_WITH_*
>
>     Nor is this channel binding type available for use with OpenPGP
>     server certificates [RFC5081] [RFC4880] (since these don't use the
>     Certificate handshake message).
>
>     Therefore 'tls-unique' is generally better than 'tls-server-end-
>     point'.  However, 'tls-server-end-point' may be used with existing
>     TLS server-side proxies ("concentrators") without modification to
> the
>     proxies, whereas 'tls-unique' may require firmware or software
>     updates to server-side proxies.  Therefore there may be cases where
>     'tls-server-end-point' may interoperate but where 'tls-unique' may
>     not.
>
>     Also, authentications mechanisms may arise which depend on channel
>     bindings to contribute entropy, in which case unique channel
> bindings
>     would have to always be used in preference to end-point channel
>     bindings.  At this time there are no such mechanisms, though one
> such
>     SASL mechanism has been proposed.  Whether such mechanisms should
> be
>     allowed is out of scope for this document.
>
>     In other words, for many applications there may be two potentially
>     applicable TLS channel binding types.  Channel binding is all or
>     nothing for the GSS-API [RFC2743], and likely other frameworks.
>     Therefore agreement on the use of channel binding, and a particular
>     channel binding type is necessary.  Such agreement can be obtained
> a
>     priori, by convention, or negotiated.
>
>     The specifics of whether and how to negotiate channel binding types
>     are beyond the scope of this document.  However, it is RECOMMENDED
>     that application protocols making use of TLS channel bindings, use
>     'tls-unique' exclusively, except, perhaps, where server-side
> proxies
>     are common in deployments of an application protocol.  In the
> latter
>     case an application protocol MAY specify that 'tls-server-end-
> point'
>     channel bindings must be used when available, with 'tls-unique'
> being
>     used when 'tls-server-end-point' channel bindings are not
> available.
>     Alternatively, the application may negotiate which channel binding
>     type to use, or may make the choice of channel binding type
>     configurable.
>
>     Specifically, application protocol specifications MUST indicate at
>     least one mandatory to implement channel binding type, MAY specify
> a
>     negotiation protocol, MAY allow for out-of-band negotiation or
>     configuration, and SHOULD have a preference for 'tls-unique' over
>     'tls-server-end-point'.
>
>
>  7.  Required Application Programming Interfaces
>
>     TLS implementations supporting the use of 'tls-unique' and/or 'tls-
>     unique-for-telnet' channel binding types, MUST provide application
>     programming interfaces by which applications (clients and servers
>     both) may obtain the channel bindings for a TLS connection.  Such
>     interfaces may be expressed in terms of extracting the channel
>     bindings data for a given connection and channel binding type.
>     Alternatively the implementor may provide interfaces by which to
>     obtain the initial client Finished message, the initial server
>     Finished message and/or the server certificate (in a form that
>     matches the description of the 'tls-server-end-point' channel
> binding
>     type).  In the latter case the application has to have knowledge of
>     the channel binding type descriptions from this document.  This
>     document takes no position on which form these application
>     programming interfaces must take.
>
>
>  8.  IANA Considerations
>
>     The IANA is hereby directed to update three existing channel
> binding
>     type registrations.  See the rest of this document.
>
>
>  9.  Security Considerations
>
> -   The Security Considerations section of [RFC5056] applies to this
> -   document.
> +   The Security Considerations sections of [RFC5056], [RFC5246] and
> +   [RFC5746] apply to this document.
>
>     The TLS Finished messages (see section 7.4.9 of [RFC5246]) are
> known
>     to both endpoints of a TLS connection, and are cryptographycally
> -   bound to it.  Therefore the TLS Finished messages can be safely
> used
> -   as a channel binding provided that the authentication mechanism
> doing
> -   the channel binding conforms to the requirements in [RFC5056].
> +   bound to it.  For implementations of TLS that correctly handle re-
> +   negotiation [RFC5746] each handshake on a TLS connection is bound
> to
> +   the preceding handshake, if any.  Therefore the TLS Finished
> messages
> +   can be safely used as a channel binding provided that the
> +   authentication mechanism doing the channel binding conforms to the
> +   requirements in [RFC5056].
>
>     The server certificate, when present, is also cryptographically
> bound
>     to the TLS connection through its use in key transport and/or
>     authentication of the server (either by dint of its use in key
>     transport, by its use in signing key agreement, or by its use in
> key
>     agreement).  Therefore the server certificate is suitable as an
> end-
>     point channel binding as described in [RFC5056].
>
>  9.1.  Cryptographic Algorithm Agility
>
>     The 'tls-unique' and 'tls-unique-for-telnet' channel binding types
> do
>     not add any use of cryptography beyond that used by TLS itself.
>     Therefore these two channel binding types add no considerations
> with
>     respect to cryptographic algorithm agility.
>
>     The 'tls-server-end-point' channel binding type consist of a hash
> of
>     a server certificate.  The reason for this is to produce manageably
>     small channel binding data, as some implementations will be using
>     kernel-mode memory (which is typically scarce) to store these.
> This
>     use of a hash algorithm is above and beyond TLS's use of
>     cryptography, therefore the 'tls-server-end-point' channel binding
>     type has a security consideration with respect to hash algorithm
>     agility.  The algorithm to be used, however, is derived from the
>     server certificate's signature algorithm as described in Section
> 4.1;
>     to recap: use SHA-256 if the certificate signature algorithm uses
> MD5
>     or SHA-1, else use whatever hash function the certificate uses
>     (unless the signature algorithm uses no hash functions or more than
>     one hash function, in which case 'tls-server-end-point' is
>     undefined).  This construction automatically makes 'tls-server-end-
>     point' hash algorithm agile, with a dependency on PKIX and TLS for
>     hash agility.
>
>     Current proposals for randomized signatures algorithms
>     [I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in
>     their construction -- a single hash function in each algorithm.
>     Therefore the 'tls-server-end-point' channel binding type should be
>     available even in cases where new signatures algorithms are used
> that
>     are based on current randomized hashing proposals (but we cannot
>     guarantee this, of course).
>
>  9.2.  On Disclosure of Channel Bindings Data by Authentication
>        Mechanisms
>
>     When these channel binding types were first considered, one issue
>     that some commenters were concerned about was the possible impact
> on
>     the security of the TLS channel, of disclosure of the channel
>     bindings data by authentication mechanisms.  This can happen, for
>     example, when an authentication mechanism transports the channel
>     bindings data, with no confidentiality protection, over other
>     transports (for example, in communicating with a trusted third
>     party), or when the TLS channel provides no confidentiality
>     protection and the authentication mechanism does not protect the
>     confidentiality of the channel bindings data.  This section
> considers
>     that concern.
>
>     When the TLS connection uses a cipher suite that does not provide
>     confidentiality protection, the TLS Finished messages will be
> visible
>     to eavesdroppers, regardless of what the authentication mechanism
>     does.  The same is true of the server certificate which, in any
> case,
>     is generally visible to eavesdroppers.  Therefore we must consider
>     our choices of TLS channel bindings here to be safe to disclose by
>     definition -- if that were not the case then TLS with cipher suites
>     that don't provide confidentiality protection would be unsafe.
>     Furthermore, the TLS Finished message construction depends on the
>     security of the TLS PRF, which in turn needs to be resistant to key
>     recovery attacks, and we think that it is, as it is based on HMAC,
>     and the master secret is, well, secret (and the result of key
>     exchange).
>
>     Note too that in the case of an attempted active man-in-the-middle
>     attack, the attacker will already possess knowledge of the TLS
>     finished messages for both inbound and outbound TLS channels (which
>     will differ, given that the attacker cannot force them to be the
>     same).  No additional information is obtained by the attacker from
>     the authentication mechanism's disclosure of channel bindings data
> --
>     the attacker already has it, even when cipher suites providing
>     confidentiality protection are provided.
>
>     None of the channel binding types defined herein produce channel
>     bindings data that must be kept secret.  Moreover, none of the
>     channel binding types defined herein can be expected to be private
>     (known only to the end-points of the channel), except that the
> unique
>     TLS channel binding types can be expected to be private when a
> cipher
>     suite that provides confidentiality protection is used to protect
> the
>     Finished message exchanges and the application data records
>     containing application-layer authentication messages.
>
>
>  10.  References
>
>  10.1.  Normative References
>
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>     [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
>                Channels", RFC 5056, November 2007.
>
>     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer
> Security
>                (TLS) Protocol Version 1.2", RFC 5246, August 2008.
>
> +   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
> +              "Transport Layer Security (TLS) Renegotiation Indication
> +              Extension", RFC 5746, February 2010.
> +
>  10.2.  Normative References for 'tls-server-end-point'
>
>     [FIPS-180-2]
>                United States of America, National Institute of
> Standards
>                and Technology, "Secure Hash Standard (Federal
> Information
>                Processing Standard (FIPS) 180-2".
>
>  10.3.  Informative References
>
>     [I-D.irtf-cfrg-rhash]
>                Halevi, S. and H. Krawczyk, "Strengthening Digital
>                Signatures via Randomized Hashing",
>                draft-irtf-cfrg-rhash-01 (work in progress), October
> 2007.
>
>     [NIST-SP.800-106.2009]
>                National Institute of Standards and Technology, "NIST
>                Special Publication 800-106: Randomized Hashing for
>                Digital Signatures", February 2009.
>
>     [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
>                Specification", STD 8, RFC 854, May 1983.
>
>     [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC
> 1321,
>                April 1992.
>
>     [RFC2743]  Linn, J., "Generic Security Service Application Program
>                Interface Version 2, Update 1", RFC 2743, January 2000.
>
>     [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
>                (SHA1)", RFC 3174, September 2001.
>
>     [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
> R.
>                Thayer, "OpenPGP Message Format", RFC 4880, November
> 2007.
>
>     [RFC5081]  Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
>                Layer Security (TLS) Authentication", RFC 5081,
>                November 2007.
>
>     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
>                Housley, R., and W. Polk, "Internet X.509 Public Key
>                Infrastructure Certificate and Certificate Revocation
> List
>                (CRL) Profile", RFC 5280, May 2008.
>
>
>  Authors' Addresses
>
>     Jeff Altman
>     Secure Endpoints
>     255 W 94TH ST PHB
>     New York, NY  10025
>     US
>
>     Email: [e-mail]
>
>
>     Nicolas Williams
> -   Sun Microsystems
> +   Oracle
>     5300 Riata Trace Ct
>     Austin, TX  78727
>     US
>
> -   Email: [e-mail]
> +   Email: [e-mail]
>
>
>     Larry Zhu
>     Microsoft Corporation
>     One Microsoft Way
>     Redmond, WA  98052
>     US
>
>     Email: [e-mail]
>
> _______________________________________________
> sasl mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sasl