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 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: stefans@xxxxxxxxxxxxx >> To: tls@xxxxxxxx >> Date: Tue, 19 Dec 2006 16:31:39 +0000 >> CC: arimed@xxxxxxxxxxxxxxxxxxxxx; pasi.eronen@xxxxxxxxx >> 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 >> TLS@xxxxxxxxxxxxxx >> 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 > TLS@xxxxxxxxxxxxxx > https://www1.ietf.org/mailman/listinfo/tls
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls