Subject: RE: [TLS] Identity Protection Ciphersuites for TLS

From: Peter Williams <[email-masked]>
Date: Sun, 3 Dec 2006 12:18:10 -0800

I think this is excellent material to contrast architectures - and thus decide what TLS does (that good old simple SASL might not!), and thus form a rationale for what the right protection elements are, within TLS, for handling client id (user, computer, or other layer)
 
We can then ask:-
 
Does it help ...to define whether TLS OUGHT itself to protect client id transfers, or should that be left the designer of the secure "application context" (the set of secuirty protocol, up and down the stack?). We have the admission in the refutation, afterall, that EAP-TTLS does, via decent contextual SP architecture, most of what the proposal sets out to do.
 
SASL
===
 
SASL is only for connection-oriented protocols. It has S5.3 restrictions on multiple authentications, and faciliate "security layers". Its has a generic bag approach to handling security services and mechanism, and can invoke GSSAPI (just like MSFT wanted is proposing for TLS workitem). It already shows how to bind S/KEY directly within the SASL world.  A "client" must initiate the first byte of a handshake.
 
on External, there are some very specific semantics, concerning authorization and authentication: "The server uses information, external to SASL, to determine whether the client is authorized to authenticate as the authorization identity. ". You can try to parse what that means, professionally, as well as I can! If I rewrite that in security target language,  I think it means:"The server uses authentication information, external to SASL, to determine whether the client is authorized to (even) connect to the SASL endpoint".

TLS
===
 
TLS only assumes a reliable byte channel, not a connection-oriented protocol bearer.
TLS does not mandate NCSC RedBook's connection-oriented paradigm, for trusted network design (neither does it deny it)
TLS assumes designers specify ciphersuites, custom ciphersuite negotiation protocols (and other custom protocols) using the TLS "record type" conventionsTLS allows each designer to interleave protocols on the record layer protocol, with application data. Std protocols and custom record types thus both get encapsulated on the same record layer bearer.
TLS allows the stack entity to fragment/reassemble the pdu stream to suit pdu transfer security objectives set by the layer 6 handshake,, including compression goals negotiated in the P-connect.
TLS allows a layer 5 protocol to interactively turn the direction of the SSL relationship: which party issues the "client" certs, that is (and, in SSL2, require the respondent to act as SSL2 session resumption _controller_)Then, if we now take the SKEY issue from the SASL standard, using RSA's worked example instead, to aid in discussing OTP issues in a layered protocol stack context:
 
TLS would expect the one-time password (for a user (hand held OTPs) or a computer (USB OTP devices)) to be encapsulated in a ws-security XML message, be formally bound by that web services's protocol suite to such as https acting as bearer, such that the XML blob eventually gets stuffed (a) in the TLS 1.1 application data, (b) a TLS1.1 extensions, (c) or a custom handshake within a TLS media type. (* refer to the RSA Labs OTPS standards to see how its _actually_ done, professionally, in the EAP world).
Contrast:
 
These are quite different archiectures. One is simple (SASL) and delegates much to GSSAPI, and gets the job done trivially: one is a infrastructure for designers of assured stacks. And don't someone start whining at me about old OSI stacks. The web is as bad now with all its web services XML layers as OSI ever was, rewritten as horrendous strings, these days! 
 
SASL and TLS have different mindsets, clearly. TLS existed MERELY to fill the gap that IPSEC (and IPv6) would eventually fill, with the same quality of architecture (limited to what is possible, given a socket consumer should not be attempting normally control the media via the network adaptor, which IPSEC can). Once Ipv4 and NAT goes away, we may yet be rid of TLS.
 
Client ID protection: users  vs computers
==========================
 
Its still an open question for me, but the actual controversy is now well identified, and we are a better starting point for getting a buyin to the proposed resolution:
 
There are two positions so far:-
 
1. Do we advocate proper layering (EAP-TTLS) for client id protection?
 
2. Or, do we we accept the (high quality) proposition from the I-D - and standardize record layer rules, concerning how the various record types MUST interleave amongst themselves, or be tunneled with the assumed security of a (partial) SSL session setup.

> Date: Sun, 3 Dec 2006 10:40:41 -0800> From: [email-masked]> To: [email-masked]> Subject: Re: [TLS] Identity Protection Ciphersuites for TLS> > > Perhaps, its really just the same as > > the SSL3 concept, and a given handshake's client id shall AMBIGUOUSLY > > represent EITHER the user OR the stack entity (computer). Or, perhaps > > its really quite a different beast.> > There are examples of IETF protocols that use TLS to authenticate the> user. SASL is used in several protocols, such as SMTP, where you can> use the "EXTERNAL" mechanism to ask the server to use the TLS client> credentials for authentication.> > Mike> > _______________________________________________> 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