[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] SPNEGO over TLS - proposed new work item
Stefan Santesson wrote:
>
> 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.
What do you mean by "GSS encrypt" -- gss_wrap?
I don't quite understand what you're proposing, but there might
a problem with this:
At the gss-api level, when SPNEGO is used, then message protection
facilities are *NOT* available until after the security context
establishment has completed successfully, i.e. GSS_C_FLAG_PROT_READY
is incompatible with the use of SPNEGO.
One of the reasons why GSS_C_FLAG_PROT_READY is incompatible with
SPNEGO is the sequencing protection of protected messages in
GSS-API. SPNEGO uses a regular "gss_getmic()" call to create a
MIC for the handshake. The use of message protection facilities
before the handshake is complete would interfere with SPNEGOs
use for the very same facilities to protect the handshake.
-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls