Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt

[Martin Rex <Martin.Rex at sap.com>]

Larry Zhu wrote:
> 
> Martin Rex wrote:
> > In contrast to this, the current ID:
> >  - requires the use of specific ciphersuites
> 
> Hum? Which specific ciphersuites are required?
> 
> >  - defines new ciphersuites
> 
> Where is the definition?

Unless I missed the TLS working groups rough consensus to add
PSK ciphersuites as a mandatory to implement ciphersuite into TLS 1.2
it counts as a new (and specific) ciphersuite for all versions of TLS.
It definitely counts as new for older versions of TLS.

(Was it Nico who used a distinct ciphersuite ID TLS_GSS when talking
 about the current draft?)

Repeating myself, orthogonality to TLS is one of things I'm favouring,
which means that my conceived architecture should fly just fine as
an extension to TLSv1.1, TLSv1.0 and even SSLv3.


> 
> >  - requires a new and optional feature from the gssapi mechanism
>     that close to none of the installed base of mechanism has
>     and that many mechanisms can not easily or not at all provide
> 
> where is the requirement?
> 
> >  - requires SPNEGO for negotiation of mechanism.
> 
> I do not see this requirement either

I'm sorry if I have been jumping to a wrong conclusion too fast.
Nico started the thread "[TLS] Negotiation in draft-santesson-tls-gssapi"
asking for how you intend to select for a common gssapi mechanism
asserting that you would need either SPNEGO or an alternative means.

I may have wrongly interpreted your silence to this question
(incomparison to the two appendix you have posted upon other questions)
as an indication that you didn't want to supply an alternative to SPNEGO.


> 
> >  - requires massive changes to the entire TLS state machine
> 
> Please quantify. FKA-TLS just defines a new way to derive the PSK.

new messages (=states) within the existing TLS handshake?


> 
> >  - inflates the size and processing time of the entire TLS handshake
> 
> Please quantify. On the contrary, we expect the size to be reduced
> because we do not need to send the certificates bags if FKA-TLS is
> negotiated, and the process time will be reduced because Kerberos is a
> lot faster.

I don't know what size your typical certs and cert paths are,
but ALL security context establishment tokens (combined) of the
~20 gssapi mechanism I've seen (except NTLM) beat the typical
server certificate messsage size by at least a factor of 3.

> 
> >  - leaves it completely in the mist how to extort gssapi handles
> >    that TLS will need to perform a gssapi context establishment
> >    durint the TLS hanshake available to the application caller
> >    to make any GSS-API extensions (names,attributes,authorizations)
> >    accessible to the application caller
> 
> Why do we care?

Maybe because of the KISS principle?


> 
> >  - you just came up with yet another pseudo-mechanism in order
> >    to protect the gssapi token exchange
> 
> It is an option to address your concern. It is not required to
> implement. I do not think it is needed. It is there illustrate how the
> protection can be done.

I wouldn't mind if on some questions you would answer:
oh, for this we could just use the following existing protocol
feature, which everyone supports already because it has been
mandatory to implement, and we don't even need to change anything.  ;-)


-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls