Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

[Hubert Kario]

On Wednesday 14 October 2015 16:06:00 Martin Thomson wrote:
> On 14 October 2015 at 15:43, Matt Caswell  wrote:
> > "highly dangerous idea"
> 
> Wrong Martin.  I agree that there is a need for caution, but in
> reality, it's not like you can use renegotiation to hand-off to
> someone else entirely.  The person you are talking to hasn't changed.
> What is dangerous is making assertions about *new* things that the
> renegotiation introduces.

Also, we're talking with a peer that does implement RFC 5746, so we can 
be *sure* that we're talking to the same peer still.

So the problem happens when application is querying the library for 
connection information (certificates mainly) and getting info from new 
connection while still actually receiving application data from the old 
context.

The problem is, that we can verify the handshake only after we receive 
Finished message, until then, the server can present any certificate it 
wants and client has no way of verifying if it (for *DH it can even 
receive information sent by client after its Finished message). For 
server it's nicer, as the certificate can be verified much quicker (in 
the same flight), but the window still exists.

That makes it dangerous when going from low to high security context, 
not so much other way round.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

[Watson Ladd]

On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell  wrote:
>
>
> On 15/10/15 14:00, Martin Rex wrote:
>> Is the particular interop problem that you want to address
>> caused by a necessity to really process application data and
>> handshake data with arbitrary interleave,
>>
>> or is it rather a problem of getting back into half-duplex operation,
>> i.e. a client being able to continue receiving application data
>> up to a ServerHello when it has sent out ClientHello, or a server being
>> able to continue receiving application data up to a ClientHello
>> (or warning level no-renegotiation alert) after the server has sent
>> a ClientHelloRequest?
>
> The former. The existing code should cope with the half-duplex issue. In
> the reported problem we (OpenSSL) are running as a server and we have
> received application data from the Client *after* we have sent our
> ServerHelloDone.

After thinking about this a bit this should be okay so long as you
properly present the authentication state associated with the data.
The hypothetical problem is using this to evade the protection of the
secure renegotiation extension. As a solution the new authentication
state should only be made visible to application code after receiving
a CSS/Finished. This is supposed to have exactly the same semantics as
pretending that the application data was sent before any handshake
data.

Unfortunately I don't know how to verify this. Can miTLS cover this case?
>
> Matt



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

[Hubert Kario]

On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell  
wrote:
> > On 15/10/15 14:00, Martin Rex wrote:
> >> Is the particular interop problem that you want to address
> >> caused by a necessity to really process application data and
> >> handshake data with arbitrary interleave,
> >> 
> >> or is it rather a problem of getting back into half-duplex
> >> operation,
> >> i.e. a client being able to continue receiving application data
> >> up to a ServerHello when it has sent out ClientHello, or a server
> >> being able to continue receiving application data up to a
> >> ClientHello (or warning level no-renegotiation alert) after the
> >> server has sent a ClientHelloRequest?
> > 
> > The former. The existing code should cope with the half-duplex
> > issue. In the reported problem we (OpenSSL) are running as a server
> > and we have received application data from the Client *after* we
> > have sent our ServerHelloDone.
> 
> After thinking about this a bit this should be okay so long as you
> properly present the authentication state associated with the data.
> The hypothetical problem is using this to evade the protection of the
> secure renegotiation extension. As a solution the new authentication
> state should only be made visible to application code after receiving
> a CSS/Finished. This is supposed to have exactly the same semantics as
> pretending that the application data was sent before any handshake
> data.
> 
> Unfortunately I don't know how to verify this. Can miTLS cover this
> case?

you mean, you want an implementation that can insert application data in 
any place of the handshake?

we've been using my project for that: 
https://github.com/tomato42/tlsfuzzer

the specific test cases are:

https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-interleaved-application-data-and-fragmented-handshakes-in-renegotiation.py

https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-interleaved-application-data-in-renegotiation.py

https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-openssl-3712.py

you can run them by:

pip install tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-openssl-3712.py

(they do expect a HTTP server on the other side)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Design Alternatives for Kerberos + DH

[Rick van Rein]

Hello,

Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and 
Kerberos orthogonal.  That simplifies matters enormously.  I can now see a few 
design alternatives.  If you have any response to them, it is kindly 
appreciated!


1) Continue to use KeyExchange

This variation sends a Ticket + Authenticator in the ClientKeyExchange, but
DH is now mentioned in plaintext instead of encrypted in the Authenticator.

PRO: Prior handshake can be taken into account in an Authenticator hash (a.k.a. 
"checksum").

CON: Special case for KeyExchange; doesn't integrate automatically with TLS 1.3.


2) Embed the Ticket + Authenticator in a PSK

This uses the binary blurb of the PSK to wrap the Ticket and Authenticator.

PRO: Client authenticates very early, in the ClientHello.

CON: PSK is untyped, so it requires separate agreement on the contents.  It is 
impossible to incorporate ServerHello information in the exchange.  The server 
has not indicated if it supports Kerberos, so the client must make a leap of 
faith.  PSK replies the selected PSK identifier, rather than send a response 
message; it is not designed for messaging purposes.


3) Similar to OpenPGP: Negotiate cert-type

There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.

PRO: Good integration with TLS: Tickets are transported in the 
ClientCertificate, and an Authenticator is the ClientVerify.  DH is independent 
and can move to the earlier phase for TLS 1.3.

CON: Decision on client credential type must be made in ClientHello, when not 
all data may be available (namely, the sequence of tickets leading to the 
TLS-protected service).  Also impacts the cert-type used in the ServerCert.


4) Define an X.509 embedding for Tickets

Certificates provide an id/key binding with a signature by a trusted party; 
although the AlgorithmIdentifiers used here are new, they do fit in the X.509 
framework.  This is rather out-of-the-box thinking, so I tested the idea, see 
https://github.com/arpa2/kerberos2pkix

PRO: Minimal changes to TLS, since Kerberos is now a signing algorithm.  The 
server can independently authenticate using RSA & co (on top of Kerberos' 
mutual authentication).  Ticket + timestamp-Authenticator go into an X.509 
ClientCertificate, and an Authenticator including the hash over prior TLS 
messages can go into ClientVerify.  CertificateRequest can mix options for 
Kerberos, RSA, and so on, and client selects whatever it can get to locally, 
giving the best user experience.  We can also support user-to-user connections 
and S4U2Proxy a.k.a. "Constrained Delegation".

CON: These certificates are symmetrically keyed, which is uncommon.  
Certificates are not readable to anyone, but only to the remote peer.  
Certificate owner is ideally read from the embedded ticket, rather than from 
the subject field.


My money is on the last two, but option 4. really needs feedback because it is 
a bit wild.  When I get an idea where to go, I will be happy to write a new 
draft version... a much smaller and simpler one this time!

Cheers,
 -Rick

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Paul Wouters]

On Fri, 16 Oct 2015, Rick van Rein wrote:


3) Similar to OpenPGP: Negotiate cert-type

There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.

PRO: Good integration with TLS: Tickets are transported in the 
ClientCertificate, and an Authenticator is the ClientVerify.  DH is independent 
and can move to the earlier phase for TLS 1.3.


How is this type of TLS connection prevented from being MITM'ed by
someone replaying kerberos tickets (which it cannot read itself)

Paul

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Clarification on interleaving app data and handshake records

[Short, Todd]

Hi Matt:

I agree with your interpretation, in that there should be no records of any 
type between the CSS and the Handshake/Finished message, even during 
re-handshake. The full handshake (and subsequent key material) cannot be 
validated until the Handshake/Finished messages has been received and processed.

Any AppData received between a CSS and Handshake/Finished is potentially 
malicious data trying to sneak in before the Handshake is verified; forwarding 
this data to an upper layer would be potentially harmful. A MITM would hope 
that the data would be processed by an application before the TLS layer 
receives and verifies the Handshake/Finished message.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 13, 2015, at 5:12 AM, Matt Caswell 
mailto:fr...@baggins.org>> wrote:

Hello,

Does anyone have any views on the below?

Thanks

Matt

On 30/09/15 11:06, Matt Caswell wrote:
Hi all

I have a question on how to interpret RFC 5246 with regards to the
interleaving of app data and handshake records.

RFC 5246 (and RFC 4346 before it) contains these words:

  Note: Data of different TLS Record layer content types MAY be
  interleaved.  Application data is generally of lower precedence for
  transmission than other content types.  However, records MUST be
  delivered to the network in the same order as they are protected by
  the record layer.  Recipients MUST receive and process interleaved
  application layer traffic during handshakes subsequent to the first
  one on a connection.

This wording seems to place no limits whatsoever on when it is valid to
receive app data in the handshake. By the wording in the RFC it would be
valid for app data to be received *after* the ChangeCipherSpec has been
received but *before* the Finished has been processed.

There is also this wording:

  Note: If a rehandshake occurs while data is flowing on a connection,
  the communicating parties may continue to send data using the old
  CipherSpec.  However, once the ChangeCipherSpec has been sent, the
  new CipherSpec MUST be used.  The first side to send the
  ChangeCipherSpec does not know that the other side has finished
  computing the new keying material (e.g., if it has to perform a
  time-consuming public key operation).  Thus, a small window of time,
  during which the recipient must buffer the data, MAY exist.  In
  practice, with modern machines this interval is likely to be fairly
  short.

I think this means that as soon as the first party sends a CCS, they
must not send any app data until they have received a CCS back - they
must buffer it until the CCS is seen - but on reading it again I'm not
sure! If that were the case then the second party should never expect to
see app data between CCS and Finished. It doesn't tell you anything
about what the first party can expect though, i.e. is the second party
allowed to send app data between the CCS and Finished?

Finally there is also this:

  A Finished message is always sent immediately after a change
  cipher spec message to verify that the key exchange and
  authentication processes were successful.

I suppose this trumps everything else, although as this section is
specifically talking about handshakes you could interpret "immediately"
as applying to the handshake sequence only without saying anything about
interleaved app data records.

I believe the intention is that app data should not be sent between the
CCS and Finished but the RFC wording is not exactly crystal clear. This
is the interpretation I have taken whilst fixing this OpenSSL bug:

https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest

Can some confirm my interpretation is correct?

Thanks

Matt



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Brian Smith]

Karthikeyan Bhargavan  wrote:

> The attack we’re protecting against is the following:
> [snip]
>

The key observation is that downgrade protection in TLS 1.2 (and below)
> relies on the Finished MAC, but the elements that go into computing this
> MAC (DH group, hash algorithm)
> are themselves negotiated within the handshake and may be downgraded. This
> is a fundamental protocol limitation that is addressed by TLS 1.3. Now, our
> goal is to protect TLS 1.3 itself
> from older protocol versions.
>

Thanks for explaining. I think this is a good idea.

Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to
protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
something specific about TLS 1.3 that makes the downgrade worse?


> 2) Looking forward, a number of researchers would like to give a strong
> security theorem for TLS 1.3, but at present we would not be able to
> guarantee security for any TLS 1.3 implementation
> that also implements older protocol versions, because we would then
> also have to prove secure all the ciphersuites used in these old versions
> (some of which are certainly broken from the
> point of view of provable security). For our proofs, we’d like nothing
> better than to be able to assume that older versions of TLS have been
> disabled, but I guess that is unlikely to happen soon.
>

No doubt it is more interesting to work on TLS 1.3. But, I think that it
would also be useful to have such work done, insofar as it is possible, for
at least a subset of TLS 1.2--e.g. the subset that is used in DICE, which
prescribes TLS 1.2. I understand that the people working on proofs for TLS
1.3 may not be the same ones that might undertake the work for TLS 1.2.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Benjamin Kaduk]

On 10/16/2015 01:48 PM, Paul Wouters wrote:
> On Fri, 16 Oct 2015, Rick van Rein wrote:
>
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>> Tickets.
>>
>> PRO: Good integration with TLS: Tickets are transported in the
>> ClientCertificate, and an Authenticator is the ClientVerify.  DH is
>> independent and can move to the earlier phase for TLS 1.3.
>
> How is this type of TLS connection prevented from being MITM'ed by
> someone replaying kerberos tickets (which it cannot read itself)

I think it is not, if the Kerberos and DH parts are completely
orthogonal [and the Kerberos exchange is not mixed into the master
secret other than via the session hash].  Having the authenticator
include the DH public value or mixing the Kerberos session key into the
master secret are two options that come to mind right away.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Martin Thomson]

On 16 October 2015 at 12:22, Brian Smith  wrote:
> Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to
> protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> something specific about TLS 1.3 that makes the downgrade worse?

Given that we can't expect TLS 1.2 servers to implement the hack, I'm
not sure that this is of great utility, but if we can bake a version
number in there, I'm not opposed to the notion.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

[Kurt Roeckx]

On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > Unfortunately I don't know how to verify this. Can miTLS cover this
> > case?
> 
> you mean, you want an implementation that can insert application data in 
> any place of the handshake?

Have you tried running any of your tests against miTLS?


Kurt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Brian Smith]

On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson 
wrote:

> On 16 October 2015 at 12:22, Brian Smith  wrote:
> > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile
> to
> > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> > something specific about TLS 1.3 that makes the downgrade worse?
>
> Given that we can't expect TLS 1.2 servers to implement the hack, I'm
> not sure that this is of great utility, but if we can bake a version
> number in there, I'm not opposed to the notion.
>

I think TLS 1.2 servers would implement the mechanism, if it were
documented in an update to the downgrade-scsv document. I mean, this
mechanism is basically a replacement for the downgrade-scsv mechanism,
because the downgrade-scsv mechanism doesn't (at least, can't be proven) to
work, right? That would be especially true for an implementation that does
False Start for TLS 1.2.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Nikos Mavrogiannopoulos]

- Original Message -
> Hello,
> 3) Similar to OpenPGP: Negotiate cert-type
> 
> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.

> PRO: Good integration with TLS: Tickets are transported in the
> ClientCertificate, and an Authenticator is the ClientVerify.  DH is
> independent and can move to the earlier phase for TLS 1.3.
> CON: Decision on client credential type must be made in ClientHello, when not
> all data may be available (namely, the sequence of tickets leading to the
> TLS-protected service).  Also impacts the cert-type used in the ServerCert.


What messages do you need to transfer for Kerberos? Is it only a ping-pong? In 
that
case, do the supplemental data from RFC4680 provide a solution with PSK in TLS 
1.2?

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Benjamin Kaduk]

On 10/16/2015 04:13 PM, Nikos Mavrogiannopoulos wrote:
> - Original Message -
>> Hello,
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
>> PRO: Good integration with TLS: Tickets are transported in the
>> ClientCertificate, and an Authenticator is the ClientVerify.  DH is
>> independent and can move to the earlier phase for TLS 1.3.
>> CON: Decision on client credential type must be made in ClientHello, when not
>> all data may be available (namely, the sequence of tickets leading to the
>> TLS-protected service).  Also impacts the cert-type used in the ServerCert.
>
> What messages do you need to transfer for Kerberos? Is it only a ping-pong? 
> In that
> case, do the supplemental data from RFC4680 provide a solution with PSK in 
> TLS 1.2?
>

4680 says "[a]ny such data MUST NOT need to be processed by the TLS
protocol.", which seems to disqualify it from applicability here.

In any case, the messages needed for Kerberos vary somewhat depending on
the desired properties.  When using Kerberos solely for client
authentication, the combination of a Ticket and Authenticator is valid
as essentially a bearer token within the clock skew window of five
minutes and subject to replay.  The client (or server, or both) can pick
a subsession key encrypted by the session key in the Ticket, and if
another message is passed that uses a subsession key for
confidentiality/integrity (such as a response from the server to perform
"mutual" (i.e., server) authentication, then there is less need for a
replay cache.  An additional key-confirmation message to validate the
server-selected subsession key (such as actual application traffic being
encrypted in that key) is helpful for the security analysis, but not
always available depending on the constraints of the application protocol.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Martin Thomson]

On 16 October 2015 at 13:39, Brian Smith  wrote:
> That would be especially true for an implementation that does False Start
> for TLS 1.2.

I don't see how false start plays into this.  We could have clients
reject false start if they see this sentinel value.  But don't we want
to just treat this as an attack and abort instead?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Brian Smith]

On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson 
wrote:

> On 16 October 2015 at 13:39, Brian Smith  wrote:
> > That would be especially true for an implementation that does False Start
> > for TLS 1.2.
>
> I don't see how false start plays into this.  We could have clients
> reject false start if they see this sentinel value.  But don't we want
> to just treat this as an attack and abort instead?
>

Yes. The client needs the sentinel to know to abort the connection, if its
willing to false start with TLS 1.2 when it also support TLS 1.3, right?

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan]

Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2
implementations to signal each other about their preferred connection 
parameters.

To make most use of the bytes provided, one could use the sentinel value to 
indicate 
support for an extension, which then carries a signed server configuration of 
arbitrary size. 
The attacker would then be unable to downgrade the connection by deleting this 
extension.

False Start is an interesting use case, because 
(a) it sends data before the server has confirmed the chosen 
version/ciphersuite/etc and 
(b) it already tries to prevent downgrades by whitelisting versions and 
ciphersuites. 
Some downgrade attacks fail because of (b), but others are easier to exploit 
because of (a).
For example, Logjam was easier to mount on False Start clients since the 
attacker could 
collect the False Start data and decrypt it at leisure.  

Extended master secret (EMS) provides some additional protection to False 
Start, because the encryption
keys implicitly include the full handshake transcript and, so if the MitM 
tampers with the connection,
the False Start data would not be accepted by a server. (However, that this 
would not have prevented Logjam.)
Moreover, even the EMS extension can be deleted by a MitM. 
The current proposal could protect EMS from downgrade by indicating support for 
it in the server hello.

To sum up, we’re focusing on TLS 1.3 because we have a chance to bake in strong 
downgrade protection
into its implementations from the very beginning. I think this could be useful 
for older versions too, as an optional
mechanism which protects clients and servers that both implement it, and does 
not affect others.

-Karthik

> On 17 Oct 2015, at 00:34, Brian Smith  wrote:
> 
> On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson  > wrote:
> On 16 October 2015 at 13:39, Brian Smith  > wrote:
> > That would be especially true for an implementation that does False Start
> > for TLS 1.2.
> 
> I don't see how false start plays into this.  We could have clients
> reject false start if they see this sentinel value.  But don't we want
> to just treat this as an attack and abort instead?
> 
> Yes. The client needs the sentinel to know to abort the connection, if its 
> willing to false start with TLS 1.2 when it also support TLS 1.3, right?
> 
> Cheers,
> Brian
> -- 
> https://briansmith.org/ 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Rick van Rein]

Hello Paul,

>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>> Tickets.
>
> How is this type of TLS connection prevented from being MITM'ed by
> someone replaying kerberos tickets (which it cannot read itself)

In Kerberos, the KDC-generated and client-cached Tickets are always sent with 
an additional Authenticator; this is client-signed message that is generated 
while sending and holds a timestamp to the ms level.  The combination is 
rejected when the timestamp is more off than a small clock skew window at the 
server.  Replay is avoided in Kerberos by observing the Authenticator's 
uniqueness within that small window.  This however, has scaling problems, for 
instance in redundant server farms.

An Authenticator can hold a "checksum", which is a hash nowadays.  We can use 
this field to store a hash of the prior TLS messages, including the ECDH 
exchange and ServerRandom.  This is already done by default in the 
ClientVerify, so nothing special needs to be done for that.  The hashes are 
typed, with an IANA registry; unkeyed hashes are possible, though none beyond 
SHA1 appears to have been needed for its current uses, but we can expand that.

Finally, the pre-master secret for all four design alternatives consists of the 
ECDH session key and the session key exchanged by the Ticket.  Replay of ECDH 
is impossible if the server continually refreshes its offers, at least not to 
be repeated within the clock skew window, which has been a major focus point in 
my 00 draft.  Lacking the session key, an attacker that attempts replay of a 
Ticket will not be able to generate the proper Finished messages.  FWIW, I am 
proposing to extend the sizes of those hashes.

Thanks,
 -Rick

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Rick van Rein]

Hello,

>> What messages do you need to transfer for Kerberos? Is it only a ping-pong?

Yes, the plan is to send a Ticket + Authenticator and since the server cannot 
send "pong", to use the (elongated) "Finished" message to replace the 
validating function of the "pong".

> The client (or server, or both) can pick
> a subsession key encrypted by the session key in the Ticket,

Currently, only the client could do this.  We might pile the subsession key 
into the pre-master secret if we decide that it adds to security.

If we really want the server to send one too, it might send a random string of 
the right size, and it could be decrypted to a key.  That's possible with 
symmetric algorithms after all... and after receiving the Ticket, the server 
can do the same to discover its secret subsession key :)

> if
> another message is passed that uses a subsession key for
> confidentiality/integrity (such as a response from the server to perform
> "mutual" (i.e., server) authentication, then there is less need for a
> replay cache.

The key idea in 00 was to not use a subsession key but instead rely on 
Diffie-Hellman for the same function, to avoid replay caches.  Because a replay 
cache would be a devastating part of a TLS infrastructure that could block 
these CipherSuites from being rolled out.

> An additional key-confirmation message to validate the
> server-selected subsession key (such as actual application traffic being
> encrypted in that key) is helpful for the security analysis, but not
> always available depending on the constraints of the application protocol.

It still surprises me, but Kerberos is able to send a message one-way and 
achieve mutual authentication.  The trick is of course that prior key exchanges 
have setup links that make this possible.  That's already been taken care of in 
client apps and libraries, so I'm trying to make good use of it in TLS.

-Rick

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls