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

From: Peter Williams <[email-masked]>
Date: Sat, 2 Dec 2006 17:29:28 -0800

I read the i-d (given some prompting), and I dont get the point.  But , then, I'm regularly dumb!
 
If we take EAP over T(unneled)TLS, doesnt that do the same thing as one example application consumer layer exploiting TLS?
 
If you send a SAML extension, where the SAML blob is protected by XML-encryption, per SAML procedures, doesnt that also do it.
 
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"?

Date: Fri, 1 Dec 2006 16:34:51 +0100From: [email-masked]: [email-masked]: [TLS] Identity Protection Ciphersuites for TLS
Dear all,
Identity protection is increasingly required; especially in wireless networks. For example, EAP-TLS proposes renegotiating after the first server authentication. This requires however more cryptographic computations and augments significantly the number of rounds trips. 
 
Consequently, Badra and I have submitted an individual document to add client identity protection to TLS. 
The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt 
Best regards,
Ibrahim
_________________________________________________________________
Use Messenger to talk to your IM friends, even those on Yahoo!
http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked]
Date: Sun, 3 Dec 2006 03:42:27 +0100 (CET)

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