[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Proposal for client auth
From: Eric Rescorla <ekr () rtfm ! com>
Date: 2015-10-22 17:34:01
Message-ID: CABcZeBMxaKY_Bg_h9PxOsZxiY7H0dikwp5d=uTmtkLPop9RdFQ () mail ! gmail ! com
[Download RAW message or body]
On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:
> On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > At the Seattle interim, we decided to have a small ad hoc design team
> > go and figure out how to harmonize the various forms of client
> > authentication. I've posted a WIP version of the output of that work
> > at:
> >
> > https://github.com/tlswg/tls13-spec/pull/316
> >
> >
> > So, what this draft does is adopt the following three messages.
> >
> > Certificate
> > CertificateVerify
> > Finished
> >
> > As the "TLS Authentication Block" and send them whenever we want to do
> > authentication. [Note that we may eventually merge messages here, but
> > that doesn't affect the logic.]
> >
> > In every case, the input to the block would be:
> >
> > - A session context (SC) which is (generally) the handshake
> > transcript up to this point.
> > - A base key to compute the finished key from (the finished
> > keys are directional, so the client and server keys are
> > different).
> >
> > And then the signature covers: SC + Certificate
> > And the MAC covers SC + Certificate + CertificateVerify
>
> Perhaps I'm reading things wrong, but this change seems to pass
> raw Context+Certificate+Signature to HMAC to compute Finished.
> Due to the way HMAC works, this requires to know the key for
> the MAC before one can start the pipe (I didn't look when it
> becomes available) and requires a separate pipe from ordinary
> transcript hash.
>
> Previously, Finished messages used the same transcript hash
> pipe as everything else using transcript hashing.
I just messed up the editing.
It's the same plan as before. HMAC(key, handshake_hash). So, for
example, the signature from the server would cover all messages
between ClientHello and Certificate (inclusive) and the MAC would
cover all messages from ClientHello and CertificateVerify inclusive.
I'll fix this in the text.
-Ekr
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct \
22, 2015 at 10:26 AM, Ilari Liusvaara <span dir="ltr"><<a \
href="mailto:ilariliusvaara@welho.com" \
target="_blank">ilariliusvaara@welho.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric \
Rescorla wrote:<br> > Folks,<br>
><br>
> At the Seattle interim, we decided to have a small ad hoc design team<br>
> go and figure out how to harmonize the various forms of client<br>
> authentication. I've posted a WIP version of the output of that work<br>
> at:<br>
><br>
> <a href="https://github.com/tlswg/tls13-spec/pull/316" \
rel="noreferrer" target="_blank">https://github.com/tlswg/tls13-spec/pull/316</a><br> \
><br> ><br>
</span><span class="">> So, what this draft does is adopt the following three \
messages.<br> ><br>
> Certificate<br>
> CertificateVerify<br>
> Finished<br>
><br>
> As the "TLS Authentication Block" and send them whenever we want to \
do<br> > authentication. [Note that we may eventually merge messages here, but<br>
> that doesn't affect the logic.]<br>
><br>
> In every case, the input to the block would be:<br>
><br>
> - A session context (SC) which is (generally) the handshake<br>
> transcript up to this point.<br>
> - A base key to compute the finished key from (the finished<br>
> keys are directional, so the client and server keys are<br>
> different).<br>
><br>
> And then the signature covers: SC + Certificate<br>
> And the MAC covers SC + Certificate + CertificateVerify<br>
<br>
</span>Perhaps I'm reading things wrong, but this change seems to pass<br>
raw Context+Certificate+Signature to HMAC to compute Finished.<br>
Due to the way HMAC works, this requires to know the key for<br>
the MAC before one can start the pipe (I didn't look when it<br>
becomes available) and requires a separate pipe from ordinary<br>
transcript hash.<br>
<br>
Previously, Finished messages used the same transcript hash<br>
pipe as everything else using transcript hashing.</blockquote><div><br></div><div>I \
just messed up the editing.</div><div><br></div><div>It's the same plan as \
before. HMAC(key, handshake_hash). So, for</div><div>example, the signature from the \
server would cover all messages</div><div>between ClientHello and Certificate \
(inclusive) and the MAC would</div><div>cover all messages from ClientHello and \
CertificateVerify inclusive.</div><div><br></div><div>I'll fix this in the \
text.</div><div><br></div><div>-Ekr</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic