Skip to main content

Exported Authenticators in TLS
draft-ietf-tls-exported-authenticator-15

Revision differences

Document history

Date Rev. By Action
2022-05-10
15 (System) RFC Editor state changed to EDIT
2022-05-10
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-05-10
15 (System) Announcement was received by RFC Editor
2022-05-10
15 (System) IANA Action state changed to In Progress
2022-05-10
15 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-05-10
15 Cindy Morgan IESG has approved the document
2022-05-10
15 Cindy Morgan Closed "Approve" ballot
2022-05-10
15 Cindy Morgan Ballot approval text was generated
2022-05-10
15 (System) Removed all action holders (IESG state changed)
2022-05-10
15 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Revised I-D Needed
2022-03-19
15 Roman Danyliw
Two remaining things from the IESG review:
* Francesca Palombini

From Section 4:

  used to send the authenticator request SHOULD use a secure with …
Two remaining things from the IESG review:
* Francesca Palombini

From Section 4:

  used to send the authenticator request SHOULD use a secure with
  equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its


FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED?

* Martin Duke

Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3.
2022-03-19
15 (System) Changed action holders to Nick Sullivan (IESG state changed)
2022-03-19
15 Roman Danyliw IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2022-03-04
15 (System) Removed all action holders (IESG state changed)
2022-03-04
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-03-04
15 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-15.txt
2022-03-04
15 (System) New version accepted (logged-in submitter: Nick Sullivan)
2022-03-04
15 Nick Sullivan Uploaded new revision
2021-11-05
14 Christopher Wood Added to session: IETF-112: tls  Tue-1600
2021-04-08
14 (System) Changed action holders to Nick Sullivan (IESG state changed)
2021-04-08
14 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2021-04-07
14 Murray Kucherawy
[Ballot comment]
Why are the SHOULDs in Section 4 only SHOULDs?  Why might an implementer reasonably not do what this says?

Similarly, the SHOULDs in …
[Ballot comment]
Why are the SHOULDs in Section 4 only SHOULDs?  Why might an implementer reasonably not do what this says?

Similarly, the SHOULDs in Section 7 seem awkward, as they have little to do with interoperability.
2021-04-07
14 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-04-07
14 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-04-06
14 Benjamin Kaduk
[Ballot comment]
I've made some (mostl) editorial suggestions in a github PR:
https://github.com/tlswg/tls-exported-authenticator/pull/73

Despite the overall YES ballot, I do have some substantive comments that …
[Ballot comment]
I've made some (mostl) editorial suggestions in a github PR:
https://github.com/tlswg/tls-exported-authenticator/pull/73

Despite the overall YES ballot, I do have some substantive comments that
may be worth some further consideration.

Do we want to give any insight or examples into how an application might
choose to use the certificate_request_context?

Thanks to Yaron Sheffer for the multiple secdir reviews.  My
understanding is that the intent of this document is to only allow
"server_name" to appear in the ClientCertificateRequest structure that
otherwise uses the "CR" notation in the TLS 1.3 column of the TLS
ExtensionType Values registry, but not to allow for "server_name" in
authenticator CertificateRequests or handshake CertificateRequests.
Assuming that's correct, the easiest way to indicate that would be if
there was a "Comment" column in the registry that could say "only used
in ClientCertificateRequest certificate requests and no other
certificate requests", but there is not such a column in the registry.
I think it could also work to be much more clear in the IANA
considerations of this document as to why the "CR" is being added and
what restrictions there are on its use, even if that's not quite as
clean of a solution.

Section 1

  multiple identities -  Endpoints that are authoritative for multiple
      identities - but do not have a single certificate that includes
      all of the identities - can authenticate additional identities
      over a single connection.

IIUC this is only new functionality for server endpoints, since client
endpoints can use different certificates for subsequent post-handshake
authentication events.

  TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
  to implement the mechanisms described in this document.

Please clarify whether this is a minimum TLS version required for using
EAs, or that this is a binding requirement on implementations of the
named protocol versions.  (If the latter is intended we may have some
discussions about an Updates: tag...)

Section 5.1

Using an exporter value as the handshake context means that any client
authentication from the initial handshake is not cryptographically
digested into the exporter value.  In light of what we ran into with
EAP-TLS1.3, do we want to revisit whether we're still happy with that?
We should in practice still benefit from the implicit confirmation that
anything the server participates in after receiving the Client Finished
means the server properly validated it and did not abort the handshake,
but it's a bit awkward, especially since the RFC 8446 post-handshake
authentication does digest the entire initial handshake transcript.
Would we feel any safer if an exporter variant was available that
digested the entire initial handshake transcript and we could use that?

Section 5.2.1

  Certificates chosen in the Certificate message MUST conform to the
  requirements of a Certificate message in the negotiated version of
  TLS.  In particular, the certificate chain MUST be valid for the
  signature algorithms indicated by the peer in the
  "signature_algorithms" and "signature_algorithms_cert" extension, as
  described in Section 4.2.3 of [TLS13] for TLS 1.3 or the
  "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
  [RFC5246] for TLS 1.2.

This seems awkward.  Do "the requirements of a Certificate message in
the negotiated version of TLS" include the actual message structure?
Because the rest of the document suggests that we always use the TLS 1.3
Certificate, but this line would set us up for using a TLS 1.2
Certificate.

Also, per §1.3 of RFC 8446, "signature_algorithms_cert" also applies to
TLS 1.2, so the last sentence seems incorrect or at least incomplete.

Section 5.2.1

  Otherwise, the Certificate message MUST contain only extensions
  present in the TLS handshake.  Unrecognized extensions in the
  authenticator request MUST be ignored.

At least the first sentence seems redundant with the previous section
(but I did not propose removing this in my editorial PR).  The second
sentence arguably follows from the RFC 8446 requirements, though I don't
mind mentioning it again as much as I do for the first sentence.

Section 5.2.2

  The authenticator transcript is the hash of the concatenated
  Handshake Context, authenticator request (if present), and
  Certificate message:

  Hash(Handshake Context || authenticator request || Certificate)

  Where Hash is the authenticator hash defined in section 4.1.  If the
  authenticator request is not present, it is omitted from this
  construction, i.e., it is zero-length.

This construction is injective, because the handshake messages start
with a message HandshakeType.  Should we say so explicitly in the
document?

  If the party that generates the exported authenticator does so with a
  different connection than the party that is validating it, then the
  Handshake Context will not match, resulting in a CertificateVerify
  message that does not validate.  This includes situations in which
  the application data is sent via TLS-terminating proxy.  Given a
  failed CertificateVerify validation, it may be helpful for the
  application to confirm that both peers share the same connection
  using a value derived from the connection secrets before taking a
  user-visible action.

Is it safe to reuse the Handshake Context itself as the "value derived
from the connection secrets"?

Section 7.4

  It returns the identity, such as the certificate chain and its
  extensions, and a status to indicate whether the authenticator is
  valid or not after applying the function for validating the
  certificate chain to the chain contained in the authenticator.

I strongly recommend not returning the identity in the case when
validation fails.

  The API should return a failure if the certificate_request_context of
  the authenticator was used in a previously validated authenticator.

Is the intent for this to be a "distinct previously validated
authenticator" (i.e., that the API returns the same value when given the
same inputs subsequently)?  That does not seem to be the meaning
conveyed by the current text.

Section 8.2

  IANA is requested to add the following entries to the registry for
  Exporter Labels (defined in [RFC5705]): "EXPORTER-server
  authenticator handshake context", "EXPORTER-client authenticator
  finished key" and "EXPORTER-server authenticator finished key" with

Don't we also need "EXPORTER-client authenticator handshake context"?

Section 9

I think we should more explicitly incorporate the TLS 1.3 security
considerations by reference.

Section 11.1

I don't think [QUIC-TLS] or RFCs 7250 and 7540 are normative references.
2021-04-06
14 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2021-04-06
14 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some …
[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I am trusting the WG and the responsible AD for ensuring that the specific section in references are the correct ones.

-- Section 2 --
Unsure where the "terminology" part is...

Also, should "Client" and "Server" be defined here ? Reading section 3, I am still unsure whether the "client" and "server" are the "TLS client" and "TLS server" ...

In the same vein, a small figure with all parties involved would be welcome by the reader.

== NITS ==

In some places, 'TLS13' is used as an anchor rather than 'RFC8446'.

Sometimes, the document uses 'octet' and sometimes 'bytes'.

-- Section 1 --
Spurious '.' in the last §.

-- Section 4 --
"as its as its" ?
2021-04-06
14 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-04-06
14 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-04-06
14 Warren Kumari [Ballot comment]
Thanks!
2021-04-06
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-04-06
14 Lars Eggert
[Ballot comment]
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. …
[Ballot comment]
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 1, paragraph 9, nit:
-    TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
-                                      -        -
+    TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED
2021-04-06
14 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-04-06
14 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the work on this document. I found it well written and I have minor comments and Nits

Comment :
  * …
[Ballot comment]
Thanks for the work on this document. I found it well written and I have minor comments and Nits

Comment :
  * As this document asked for a IANA registration entry with DTLS-OK, hence this mechanism is OK to be used with DTLS. I understand the heavily references to TLS 1.3 as it relay on the mechanisms described there. However, I found it odd not find any reference to DTLS1.3 (we had it on the last formal IESG telechat, it is quite ready to be referenced). Is this intentional? is it supposed to be that this mechanism defined in this document on can be used with DTLS1.2?

  * Section 7.3 & 7.4: is "active connection" defined somewhere? it would be good if some descriptive texts are added for clarification as done for the other bullets in the same list.

  * For the API considerations I was expecting a API to generate the  certificate_request_context.

Nits:
* Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3
* Section 4 & 5: likely copy paste error -- s/as its as its/as its
2021-04-06
14 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-04-06
14 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the work on this document. I found it well written and I have minor comments and Nits

Comment :
* As …
[Ballot comment]
Thanks for the work on this document. I found it well written and I have minor comments and Nits

Comment :
* As this document asked for a IANA registration entry with DTLS-OK, hence this mechanism is OK to be used with DTLS. I understand the heavily references to TLS 1.3 as it relay on the mechanisms described there. However, I found it odd not find any reference to DTLS1.3 (we had it on the last formal IESG telechat, it is quite ready to be referenced). Is this intentional? is it supposed to be that this mechanism defined in this document on can be used with DTLS1.2?
* Section 7.3 & 7.4: is "active connection" defined somewhere? it would be good if some descriptive texts are added for clarification as done for the other bullets in the same list.
* For the API considerations I as expecting a API to generate the  certificate_request_context.

Nits:
* Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3
* Section 4 & 5: likely copy paste error -- s/as its as its/as its
2021-04-06
14 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-04-05
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-04-05
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-04-04
14 Francesca Palombini
[Ballot comment]
Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments …
[Ballot comment]
Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments below.

Francesca

1. -----

  TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
  to implement the mechanisms described in this document.

FP: Does this mechanism applies to DTLS as well? The sentence above, the normative reference to DTLS 1.2, and the IANA section 8.2 would imply so. However, this is the only time DTLS is mentioned in the body of the document, excluding IANA considerations. I would like it to be made explicit that this mechanism can be used for DTLS (if that's the case) both in the abstract and in the introduction, add any useful considerations about using this mechanism with DTLS vs TLS, and possibly add a sentence in the introduction stating that DTLS 1.X uses what specified for TLS 1.X. Two examples of why that would be useful are the following sentences:

  using an exporter as described in Section 4 of [RFC5705] (for TLS
  1.2) or Section 7.5 of [TLS13] (for TLS 1.3).  For TLS 1.3, the

  "signature_algorithms" and "signature_algorithms_cert" extension, as
  described in Section 4.2.3 of [TLS13] for TLS 1.3 or the
  "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
  [RFC5246] for TLS 1.2.

which makes it clear what applies for TLS but not for DTLS.

2. -----

  used to send the authenticator request SHOULD use a secure with
  equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its


FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED?
nits: missing word "use a secure with" ; remove one of the duplicated "as its".
(Note: this text appears again with the same typos for the authenticator in section 5)

3. -----

      extensions (OCSP, SCT, etc.)

FP: Please consider adding informative references.
2021-04-04
14 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-04-03
14 Erik Kline
[Ballot comment]
[ sections 4 & 5 ]

* "SHOULD use a secure with" ->
  "SHOULD use a secure communications channel with" or
  …
[Ballot comment]
[ sections 4 & 5 ]

* "SHOULD use a secure with" ->
  "SHOULD use a secure communications channel with" or
  "SHOULD use a secure transport with" or something?

* "as its as its" -> "as its"

[ section 5.2.3 ]

* I think the first sentence of the first paragraph may not be a
  grammatically complete sentence?

[ section 7 ]

* "following sections describes APIs" ->
  "following sections describe APIs"
2021-04-03
14 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-04-02
14 Yaron Sheffer Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list.
2021-04-01
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2021-04-01
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2021-03-31
14 Martin Duke
[Ballot comment]
- I come away from this not being entirely sure if this document applies to DTLS or not. There is the one reference …
[Ballot comment]
- I come away from this not being entirely sure if this document applies to DTLS or not. There is the one reference in the intro to DTLS, but it's not in the abstract, nor anywhere else. Assuming that the Sec. 1 reference is not some sort of artifact, the document would benefit from a liberal sprinkling of 's/TLS/(D)TLS' (but this would not apply to every instance)

- If (D)TLS 1.2 is REQUIRED to implement, then does this document not update those RFCs?

NITS:

- Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3.

- Sec 4 and 5. "use a secure with..." ?

- Sec 4. s/messages structures/message structures
2021-03-31
14 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-03-30
14 Amy Vezza Placed on agenda for telechat - 2021-04-08
2021-03-30
14 Roman Danyliw Ballot has been issued
2021-03-30
14 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2021-03-30
14 Roman Danyliw Created "Approve" ballot
2021-03-30
14 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-03-30
14 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2021-03-30
14 Roman Danyliw Ballot writeup was changed
2021-02-25
14 Roman Danyliw Please respond to remaining IETF LC feedback: https://mailarchive.ietf.org/arch/msg/last-call/pL1bBsDDrpwu2gxdcIGQQK98n6s/
2021-01-25
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-01-25
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-01-25
14 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-14.txt
2021-01-25
14 (System) New version approved
2021-01-25
14 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2021-01-25
14 Nick Sullivan Uploaded new revision
2020-11-05
13 Yaron Sheffer Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yaron Sheffer. Sent review to list.
2020-10-28
13 Christer Holmberg Request for Last Call review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list.
2020-10-21
13 Roman Danyliw Please respond to:
-- Last Call Feedback: https://mailarchive.ietf.org/arch/msg/last-call/pL1bBsDDrpwu2gxdcIGQQK98n6s/
-- AD Review: https://mailarchive.ietf.org/arch/msg/tls/zX0aay5kCNDJkpMEImtFupOYPLQ/
2020-10-21
13 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-10-19
13 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2020-10-19
13 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-10-16
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-10-15
13 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2020-10-15
13 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-13. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the existing registration for:

Value: 0
Extension Name: server_name

with have its registration changed so that the "TLS 1.3" column will indicate:

CH, EE, CR

Second, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

three new registrations are to be made as follows:

EXPORTER-server authenticator handshake context
EXPORTER-client authenticator finished key
EXPORTER-server authenticator finished key

As this section requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

For each of these registration requests, IANA suggests that the registration information in Section 8.2 of the current document be expanded to include information to fill out the columns "DTLS-OK" and "Recommended" in the registry.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-10-09
13 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2020-10-09
13 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2020-10-08
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-10-08
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-10-06
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-10-06
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-10-02
13 Amy Vezza
The following Last Call announcement was sent out (ends 2020-10-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: sean@sn3rd.com, rdd@cert.org, …
The following Last Call announcement was sent out (ends 2020-10-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: sean@sn3rd.com, rdd@cert.org, draft-ietf-tls-exported-authenticator@ietf.org, tls@ietf.org, Christopher Wood <christopherwood07@gmail.com>, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com>
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-tls-exported-authenticator-13.txt> (Exported Authenticators in TLS) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Exported Authenticators in TLS'
  <draft-ietf-tls-exported-authenticator-13.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism in Transport Layer Security (TLS)
  for peers to provide a proof of ownership of an identity, such as an
  X.509 certificate.  This proof can be exported by one peer,
  transmitted out-of-band to the other peer, and verified by the
  receiving peer.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/



No IPR declarations have been submitted directly on this I-D.




2020-10-02
13 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-10-02
13 Amy Vezza Last call announcement was generated
2020-10-02
13 Roman Danyliw Last call was requested
2020-10-02
13 Roman Danyliw IESG state changed to Last Call Requested from Publication Requested
2020-10-02
13 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/tls/zX0aay5kCNDJkpMEImtFupOYPLQ/
2020-09-18
13 Benjamin Kaduk Shepherding AD changed to Roman Danyliw
2020-07-02
13 Sean Turner
Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to …
Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00
2020-07-02
13 Sean Turner IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-07-02
13 Sean Turner IESG state changed to Publication Requested from AD is watching
2020-07-02
13 Sean Turner Tag Revised I-D Needed - Issue raised by WG cleared.
2020-07-02
13 Sean Turner IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2020-06-26
13 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-13.txt
2020-06-26
13 (System) New version approved
2020-06-26
13 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2020-06-26
13 Nick Sullivan Uploaded new revision
2020-06-16
12 Sean Turner Tag Revised I-D Needed - Issue raised by WG set.
2020-06-16
12 Sean Turner IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2020-06-03
12 Sean Turner
Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to …
Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00
2020-05-22
12 Sean Turner 3rd WGLC to ensure changes made a result of secdir review are addressed.
2020-05-22
12 Sean Turner IETF WG state changed to In WG Last Call from WG Document
2020-05-21
12 Sean Turner Tag Revised I-D Needed - Issue raised by WG cleared.
2020-05-15
12 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-12.txt
2020-05-15
12 (System) New version approved
2020-05-15
12 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2020-05-15
12 Nick Sullivan Uploaded new revision
2020-04-10
11 Sean Turner Document shepherd changed to Sean Turner
2019-12-18
11 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-11.txt
2019-12-18
11 (System) New version approved
2019-12-18
11 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2019-12-18
11 Nick Sullivan Uploaded new revision
2019-11-21
10 Sean Turner Tag Revised I-D Needed - Issue raised by WG set.
2019-11-21
10 Benjamin Kaduk Moving back to the WG for resolution of issues raised by secdir review; may require defining new TLS message types and re-review.
2019-11-21
10 Benjamin Kaduk Tag Point Raised - writeup needed cleared.
2019-11-21
10 Benjamin Kaduk IETF WG state changed to WG Document from Submitted to IESG for Publication
2019-11-21
10 Benjamin Kaduk IESG state changed to AD is watching::Point Raised - writeup needed from Waiting for Writeup::Point Raised - writeup needed
2019-11-12
10 Benjamin Kaduk IESG state changed to Waiting for Writeup::Point Raised - writeup needed from Waiting for Writeup
2019-11-04
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2019-11-04
10 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-10.txt
2019-11-04
10 (System) New version approved
2019-11-04
10 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2019-11-04
10 Nick Sullivan Uploaded new revision
2019-11-04
09 Sean Turner Changed document URLs from:

[]

to:

repository https://github.com/tlswg/tls-exported-authenticator
2019-08-26
09 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Jon Mitchell was marked no-response
2019-07-16
09 Yaron Sheffer Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list.
2019-07-16
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-07-16
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-09. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

in the existing registration for:

Value: 0
Extension Name: server_name

the entry for TLS 1.3 will be changed from:

CH, EE

to:

CH, EE, CR

As this document requests modifications to existing registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS ExtensionType Values have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

three new registrations are to be made as follows:

Value: EXPORTER-server authenticator handshake context
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

Value: EXPORTER-client authenticator finished key
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

Value: EXPORTER-server authenticator finished key
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

IANA Question --> What should be the entries for DTLS-OK and Recommended for each of these three new registrations?

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Exporter Labels have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-07-16
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-07-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2019-07-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2019-07-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2019-07-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2019-07-07
09 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Christer Holmberg. Sent review to list.
2019-07-03
09 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2019-07-03
09 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2019-07-02
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-07-02
09 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-07-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-tls-exported-authenticator@ietf.org, christopherwood07@gmail.com, …
The following Last Call announcement was sent out (ends 2019-07-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-tls-exported-authenticator@ietf.org, christopherwood07@gmail.com, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com>, Christopher Wood <christopherwood07@gmail.com>, tls@ietf.org, kaduk@mit.edu
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-tls-exported-authenticator-09.txt> (Exported Authenticators in TLS) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Exported Authenticators in TLS'
  <draft-ietf-tls-exported-authenticator-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-07-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism in Transport Layer Security (TLS)
  to provide an exportable proof of ownership of a certificate that can
  be transmitted out of band and verified by the peer.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-07-02
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-07-02
09 Benjamin Kaduk Last call was requested
2019-07-02
09 Benjamin Kaduk Last call announcement was generated
2019-07-02
09 Benjamin Kaduk Ballot approval text was generated
2019-07-02
09 Benjamin Kaduk Ballot writeup was generated
2019-07-02
09 Benjamin Kaduk IESG state changed to Last Call Requested from AD Evaluation
2019-05-03
09 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-09.txt
2019-05-03
09 (System) New version approved
2019-05-03
09 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2019-05-03
09 Nick Sullivan Uploaded new revision
2019-04-18
08 Benjamin Kaduk IESG state changed to AD Evaluation from Publication Requested
2019-01-31
08 Christopher Wood
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to …
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00
2019-01-31
08 Christopher Wood Responsible AD changed to Benjamin Kaduk
2019-01-31
08 Christopher Wood IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-01-31
08 Christopher Wood IESG state changed to Publication Requested from I-D Exists
2019-01-31
08 Christopher Wood IESG process started in state Publication Requested
2019-01-31
08 Christopher Wood
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to …
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00
2019-01-24
08 Christopher Wood
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to …
Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. No browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00
2018-12-03
08 Christopher Wood IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-11-16
08 Christopher Wood Notification list changed to Sean Turner <sean@sn3rd.com>, Christopher Wood <christopherwood07@gmail.com> from Sean Turner <sean@sn3rd.com>
2018-11-16
08 Christopher Wood Document shepherd changed to Christopher A. Wood
2018-11-06
08 Christopher Wood Tag Revised I-D Needed - Issue raised by WGLC cleared.
2018-11-06
08 Christopher Wood IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2018-10-18
08 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-08.txt
2018-10-18
08 (System) New version approved
2018-10-18
08 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2018-10-18
08 Nick Sullivan Uploaded new revision
2018-06-05
07 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-07.txt
2018-06-05
07 (System) New version approved
2018-06-05
07 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2018-06-05
07 Nick Sullivan Uploaded new revision
2018-06-05
07 Nick Sullivan Uploaded new revision
2018-05-29
06 Sean Turner Tag Revised I-D Needed - Issue raised by WGLC set.
2018-05-29
06 Sean Turner IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2018-04-19
06 Sean Turner IETF WG state changed to In WG Last Call from WG Document
2018-04-19
06 Sean Turner Notification list changed to Sean Turner <sean@sn3rd.com>
2018-04-19
06 Sean Turner Document shepherd changed to Sean Turner
2018-03-05
06 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-06.txt
2018-03-05
06 (System) New version approved
2018-03-05
06 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2018-03-05
06 Nick Sullivan Uploaded new revision
2017-12-13
05 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-05.txt
2017-12-13
05 (System) New version approved
2017-12-13
05 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2017-12-13
05 Nick Sullivan Uploaded new revision
2017-11-07
04 Sean Turner Added to session: IETF-100: tls  Thu-0930
2017-10-30
04 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-04.txt
2017-10-30
04 (System) New version approved
2017-10-30
04 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2017-10-30
04 Nick Sullivan Uploaded new revision
2017-07-17
03 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-03.txt
2017-07-17
03 (System) New version approved
2017-07-16
03 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2017-07-16
03 Nick Sullivan Uploaded new revision
2017-06-20
02 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-02.txt
2017-06-20
02 (System) New version approved
2017-06-20
02 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2017-06-20
02 Nick Sullivan Uploaded new revision
2017-06-20
01 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-01.txt
2017-06-20
01 (System) New version approved
2017-06-20
01 (System) Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com>
2017-06-20
01 Nick Sullivan Uploaded new revision
2017-05-18
00 Sean Turner Changed consensus to Yes from Unknown
2017-05-18
00 Sean Turner Intended Status changed to Proposed Standard from None
2017-05-18
00 Sean Turner This document now replaces draft-sullivan-tls-exported-authenticator instead of None
2017-05-18
00 Nick Sullivan New version available: draft-ietf-tls-exported-authenticator-00.txt
2017-05-18
00 (System) New version approved
2017-05-18
00 Nick Sullivan Request for posting confirmation emailed  to submitter and authors: Nick Sullivan <nick@cloudflare.com>
2017-05-18
00 Nick Sullivan Uploaded new revision