Subject: RE: [TLS] GSS-API extension draft available

From: Peter Williams <[email-masked]>
Date: Tue, 19 Dec 2006 10:11:43 -0800

I much rather see the usul negotiation of the GSSAPI ciphersuite, and then a custom-GSS client protocol 
handshake occur, before the master keying occurs. This would naturally occur after serverkeyexchange, which 
could be used to signal the GSS mechanism and payload exchange process sub-states to the client.
 
Like ChangeCipherSuite messages, the GSS mechanism oid exchanges should not be classified 
as a handshake message.  Arguably, the GSS payloads should: trouble is ...they would have to be opaques, under
the conventional formalism.
 
I don't like the idea of GSS mechanisms having any possibility of influencing the sessionid resumption processes. 
Thus im not in favor of the binding to the hello process. 
 
Interesting that yet another proposal is once again all about PRFs, and controlling master keying. Its not 
OBVIOUSLY a spec about adding GSS API mechanisms to the portfolio of techniques, or fixing
kerbersos ciphersuites, per the marketing!
Did occur to me to wonder, from the design, whether there is an intend to be assigning to the GSS provider's 
selected mechanism now the  management/control of the session resumption process. This is interesting, if 
its an intent; particularly if its in the first packet (being bound to clienthello)

> From: [email-masked]> To: [email-masked]> Date: Tue, 19 Dec 2006 16:31:39 +0000> CC: [email-masked]; [email-masked]> Subject: [TLS] GSS-API extension draft available> > A first version of the GSS-API draft is available from:> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt> > The title of this draft is wrong. Please ignore that error. A new draft 01 with a correct title has been submitted today.> > I request on behalf of the editors that the TLS WG adopt this as a WG document.> > > > Stefan Santesson> Senior Program Manager> Windows Security, Standards> > > > > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Check the weather nationwide with MSN Search: Try it now!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Dec 2006 14:16:31 -0500

Peter:

In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as
the pre-master secret.  This mechanism has severe problems because it
means that each and every TLS session that is created for as long as the
Kerberos service ticket is valid will use the same pre-master secret.

What this proposal does is replace RFC 2712 with a generic GSS-API
method of generating a unique pre-master secret when used with the GSS
Kerberos5 mechanism.  GSS-API does not provide a method to extract key
data from the underlying mechanism because doing so would result in a
mechanism specific dependency and violate the GSS-API abstraction.

The GSS-API PRF was implemented specifically to support higher level
protocols (and applications) that require access to random data on both
sides of the connection for use in generating keys.  The GSS-API PRF is
a mechanism independent abstraction.

This proposal is a replacement for the RFC 2712.  It also provides
applications that use the GSS Kerberos5 mechanism support for credential
delegation.

I do not believe that the TLS GSS-API extension for negotiating GSS
mechanisms should influence the Session resumption process.

Jeffrey Altman

Peter Williams wrote:
> I don't like the idea of GSS mechanisms having any possibility of
> influencing the sessionid resumption processes.
> ------------------------------------------------------------------------
> 
>> From: [email-masked]
>> To: [email-masked]
>> Date: Tue, 19 Dec 2006 16:31:39 +0000
>> CC: [email-masked]; [email-masked]
>> Subject: [TLS] GSS-API extension draft available
>>
>> A first version of the GSS-API draft is available from:
>> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt
>>
>> The title of this draft is wrong. Please ignore that error. A new
> draft 01 with a correct title has been submitted today.
>>
>> I request on behalf of the editors that the TLS WG adopt this as a WG
> document.
>>
>>
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>>
>>
>>
>>
> ------------------------------------------------------------------------
> Check the weather nationwide with MSN Search Try it now!
> <http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG>
> 
> 
> ------------------------------------------------------------------------
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Dec 2006 21:26:10 +0100 (MET)

> Kerberos service ticket is valid will use the same pre-master secret.

This looks like an extremely poor choice to me, given the (lack of)
entropy in Kerberos sessions keys, in particular of the installed base
and the predominant interorable enctype when rfc2712 was issued.

> mechanism specific dependency and violate the GSS-API abstraction.

Using the entropy from the GSS-API prf is fine.  Completly ignoring
additional randomness that is available through the regular TLS
handshake looks somewhat strange to me.

I would have expected that one would XOR a GSS-API supplied entropy
for the pre-master secret with a traditional TLS-generated entropy.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Dec 2006 15:32:51 -0500

> for the pre-master secret with a traditional TLS-generated entropy.

In other words, you would prefer an anonymous-DH exchange in addition
to the GSS-API PRF?

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Dec 2006 22:33:13 +0100 (MET)

> In other words, you would prefer an anonymous-DH exchange in addition

Ooops, sorry -- I had only looked at the new draft, not rfc2712,
and was not aware that this completely removed the server certificate
from the TLS handshake.  This might be a challenge for client-side UIs,
which may not be prepared to deal with server identities not based
on X.509 certs, i.e. plug'n'play this into a TLS mechanism probably
does not work.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Dec 2006 16:42:39 -0500

> on X.509 certs, i.e. plug'n'play this into a TLS mechanism probably

RFC 2712 is currently supported by both Java and OpenSSL.
I do not expect the new protocol to have additional challenges from a UI
perspective.

Jeffrey Altman

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 20 Dec 2006 13:26:16 +0100

> Using the entropy from the GSS-API prf is fine.  [...]

In terms of entropy, the RFC 2712 approach does not have a problem.
While the premaster secret is fixed for a given Kerberos ticket, any
master secret will also depend on the client hello and server hello
randomness of the specific connection and thus, for practical
purposes, be unique.  This is similar to the fixed DH ciphersuites for
TLS (which no-one uses, though), in which the premaster secret is fixed
for any given client certificate/server certificate combination.

However, it is not entropy in general that counts.  While the client
hello and server hello do provide entropy, this is public entropy and
thus cannot contribute much to long-term encryption security.  What you
can do to obtain better security with the RFC 2712 Kerberos ciphersuites
is immediate renegotiation using an anonymous DH (or ECDH) ciphersuite:
then Kerberos is relied upon for authentication, and the DH key exchange
(which happens in an authenticated context) is relied upon for obtaining
the symmetric keys that will be used for the actual application data.
I don't think any RFC 2712 implementation has been designed with this in
mind, but it would be a quite reasonable approach to use the protocol.

It appears to me that when we use the GSS-API PRF for Kerberos V 
(RFC 4402) as suggested in draft-santesson-tls-gssapi-01.txt, we have
solved the wrong problem.  Using the PRF will give use a unique
premaster secret for each session, which we don't really need.  Using
the PRF will not include any additional *secret* entropy, which is what
we actually need -- at least if the main worry is the lack of entropy in
the Kerberos session key.

I may have misunderstood what the proposed GSS-API based handshake would
be doing in the Kerberos V case.  But if it works the way I think it
works (without mixing in secret entropy from a key exchange such as
DH/ECDH), then to improve the level of security compared with RFC 2712
as apparently is desired, we'd still have to perform an immediate
renegotiation to benefit from an appropriate key exchange mechanism.

Bodo

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Dec 2006 07:45:33 -0500

> renegotiation to benefit from an appropriate key exchange mechanism.

Currently the input to the GSS PRF would be:

OM_uint32  minor_status;
gss_ctx_id_t  gss_context;
gss_buffer_t  prf_in;
gss_buffer_t  prf_out;
ssize_t       output_len = sizeof(pre-master-secret);

GSS_Pseudo_random( &minor_status,
  		   gss_context,
		   GSS_C_PRF_KEY_FULL,
		   prf_in,
	           output_len,
                   prf_out);
		
where prf_in is the concatenation of all of the previous TLS messages
in the exchange up until the completion of the GSS handshake:

  prf_in = ClientHello || ServerHello || ....

What I hear you saying is that we should add an ephemeral-ephemeral DH
exchange in which case the prf_in will become:

  prf_in = g^xy mod p || ClientHello || ServerHello || ....

where g^xy mod p is the DH key.

Correct?

Jeffrey Altman

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 20 Dec 2006 14:48:56 +0100

>   prf_in = ClientHello || ServerHello || ....

I see.  This is something that I had not managed to gather from
draft-santesson-tls-gssapi-01.txt.  (Why not use just
ClientHello.random and ServerHello.random instead of the complete TLS
handshake data collected so far?)

> where g^xy mod p is the DH key.

Yes, this looks much better -- at least when the key exchange
mechanism is used with Kerberos V.  For other GSS-API mechanisms,
the DH computation might just be overhead.

The renegotiation approach, while appearing somewhat ad-hoc, has some
advantages in terms of flexibility at the cost of some extra protocol
rounds (but little extra computational effort): It can accomodate DH
and ECDH and any other key exchanges.  For GSS-API mechanisms for
which an additional key exchange is not necessary, there simply
wouldn't have to be a second handshake.  (Of course, to ensure
interoperability, the specification would have to provide appropriate
instructions.)

Still it probably would be the best to integrate all components of the
key exchange into a single TLS handshake.  I am just not sure what the
best protocol design would be: Have separate ciphersuites without 
a ServerKeyExchange, with DH, with ECDH?  Or use some additional
negotiation mechanism (based on TLS extensions) to choose if and how
ServerKeyExchange (and ClientKeyExchange) should be used?

Bodo