|
I
would like the TLS group to consider a new work to provide a framework for
GSS-API based authentication and key establishing methods. I have requested a
spot at the TLS meeting to discuss this. In
Microsoft we have investigated many ways to use Kerberos as means of client
authentication and key establishment over TLS but the task offers several
challenges that current specification does not solve. The
most important challenge is to allow a full Kerberos negotiation including
initial AS-request to the KDC server when the client resides outside the local
network of the KDC server. The
proposal is to provide a generic and transparent solution by enabling SPNEGO
(RFC 4178) within a TLS handshake. The
advantage of allowing SPNEGO under TLS is that it provides a lot of flexibility
as new mechanisms can be added under SPNEGO (e.g., WS security), given the
reliance on the SPNEGO for auth package negotiation, without further amendments
to TLS. Deliverables
and highlights:
- Define new ciphersuites that use SPNEGO for key exchange
- Define new TLS client/server extension for agreement upon
which SPNEGO mechanism to use (e.g. Kerberos)
- The server always sends its certificate
- The server never sends certificate request message
- The client never sends its certificate - ClientKeyExchange message: After GSS
initialize Security
context call is done, the client calls GSS encrypt message
to encrypt the premaster secret. NOTE: the ClientKeyExchange
is always protected under the public key obtained from the
Server cert.
- Ideally use Supplementary data messages to carry gss payloads Outline:
Client Server
ClientHello
/* CipherSuite: SPNEGO_AES_SHA256,...
Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ ----->
ServerHello
/* CipherSuite:
SPNEGO_AES_SHA256
Extensions SPNEGO (Kerb) */
Certificate
<-------- ServerHelloDone
<--------- SupplementalData -------->
/* multiple iterations with SPNEGO payload */
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
-------->
[ChangeCipherSpec]
<--------
Finished
Application
Data
<-------> Application Data Challenges: The
SPNEGO negotiation does not have a predefined number of iterations. This
exchange of messages has to be allowed go on until finished. Conventions need
to be defined for how to detect completion as well as success and failure of
this negotiation. Ideally
we would use the Supplemental data handshake message to carry the SPNEGO
payloads. However, it must be determined that it is allowed. Alternative
solutions considered: As
alternative solutions to this proposal we have considered defining Kerberos
specific payloads for transport in TLS extensions and handshake messages as
well as basing a solution on TLS PSK. The
name field in TLS PSK could contain a Kerberos ticket, but it would not provide
the necessary means to provide an initial AS-request. The AS-request has a need
for protection which has to be provided by the TLS handshake, possibly through
double handshake. Such solution is not very generic and double handshake is not
always usable in environments where this could be used, especially in high
latency networks. In
the end, no alternatives considered have in our view been able to provide a
clean and generic solution. Stefan Santesson Senior Program Manager Windows Security, Standards |
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls