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

From: Peter Williams <[email-masked]>
Date: Sun, 3 Dec 2006 09:37:47 -0800

The designers *seem* to be advocating a modern position based on fundamental principle that I had assumed to be a _discarded_  SSL3 design precept. This assert[ed] that a SSL3-enhanced socket supports a generic "application" - versus a specific transport level entity in the stack. By seeking to reorder and interleave the the internal TLS protocols to now perform "client identity/identification protection", we need to now be very clear whether we are truly seeking to protect a T-entity, or a non T-entity (e.g. A-entity), when Ethereal flags a client cert in a particular handshake protocol exchange, within the same TLS session.
 
A forcing question,  to better understand this issue, may be as follows. If the ciphersuite is pure kerberos-based, and no X.509 certificates thus exist in the protocol run, would "client identity/identification protection" by appropriate arranging the TLS protocols be protecting the privacy of the computer's kerberos id, or the user's kerberos credentials? In the 802.1x world, where the likes of EAP-TTLS reign, we EXPECT to make the distinction between the computer's and the user's credentials, of course. Are we seeing the implication from the document that TLS session might now have two or more interleaved handshakes ongoing, each with distinct client id protections .. and reasons to interleave the various TLS protocols in different ways, while on the record layer?
 
If TLS has truly made a break from the SSL3 architecture, surely any T-protocol security should protect ONLY T-entities (the computer/process/T-bridge/sslvpn-endpoint), not A-entities ( the user or a human's agent)
 
If my understanding of the modern TLS's wider security architecture holds, would we not now EXPECT any andALL A-entity "Client identity/identification protection" to be handled by its own layer (e.g. SAML2 APDU's borne over TLS or TLS1.1 extensions), or by tunneling processes (e.g. EAP-TTLS) controlled by such applications?
 
My interest in this is really so much to review  the I-D own claims, but the adjudge whether this particular I-D's interesting ideas can be supported within the core standard. Its a useful case to determine whether TLS has made a break from SSL truly, regarding layer separation in its security model. Its possible TLS is just pretending, with all its new fancy definitional constructs! 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.
 
In conclusion, it WOULD be appropriate to "realign" and more carefully interleave the modern TLS protocols to suit his "client id protection idea" if the designers intend the protection to be internal to the T-layer exchange, and do not intend of make upper layer security dependent upon this T-network facility. In crypto-political terms, at IETF we do not want to now repeat the phone company-based design practices, where the voice network is (a) the ONLY security provider for a human user , and (b) is inherently untrustworthy for personal privacy ( in the US anyways) - because of the the way the critical infrastructure policy was set to enable privacy expectations to be compromised, as fitted into the the technical standards by the architecture adopted by the standardization groups. As a postscript, Im worried that you selected a defense citing DoS. I wish TLS was clearer on whether it did or did not scope DoS within the set of issues this WG is designing for. In the SSL2 world, it was a part of the thinking, I can note; though it was not part of SSL3. Ive no idea what was indended for TLS. Given TLS standard still has some ssl2 design relics to consider, I suppose its not unreasonable that TLS is ambiguous on this! Are there any authoritative TLS protection profiles out there to help us determine this issue, by looking at the CC requirements they list? This may help qualify the protection value of the ideas in the I-D, within a clearer TLS architecture.
 
Peter.

> Date: Sun, 3 Dec 2006 03:42:27 +0100> Subject: RE: [TLS] Identity Protection Ciphersuites for TLS> From: [email-masked]> To: [email-masked]> CC: [email-masked]; [email-masked]> > Hi Peter,> > The document describes the protection of the "TLS client" certificate> (i.e. the TLS Certificate message) and not of the user-per-application> identity. In addition, it lists many existing solutions in the> introduction.> > EAP-TTLS (with client based-certificate authentication), which is> equivalent to EAP-TLS with privacy (see section 2.7 of EAP-TLS I-D) is> indirectly listed in the introduction:> > Client identity protection may be also possible, assuming that the> client permits renegotiation after the first server authentication.> However, this requires more cryptographic computations and augments> significantly the number of rounds trips.> > It is true that EAP-TTLS (or EAP-TLS with privacy) provides the same> thing, but:> > -You have to establish "two" TLS sessions with encryption/decryption of> the whole messages of the second session.> -You will not detect a forget client too early. in EAP-TTLS, a forged> client can start a TLS session with only server authentication. The server> will not detect that only after sending its ServerHelloDone of the second> TLS session. This IMHO sensitivity increases the DoS attack's> effectiveness against the server> > > Client auth in a layer 4 protocol entity (supportiung normally a layer 5> > exchange to establish the current direction of the relationship) is> > (unlike in https) a matter of T-entity authentication to another T-entity,> > surely? If we take an SSL/TL Conenct proxy, is not the T-entity the proxy> > id, doing client auth, versus the SAML identifded APDU-issuing user -> > whose identiifcation attributes are protected by the SAML/STS-layer's> > "client identification protection"?> > I didn't entirely got the point here and its relationship to the document.> > Best regards,> Badra
_________________________________________________________________
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

---

From: Mike <[email-masked]>
Date: Sun, 03 Dec 2006 10:40:41 -0800

> 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