Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05

From: [email-masked]
Date: Fri, 1 Dec 2006 21:20:45 +0100 (CET)

Dear Joe, Bernard and all,

Section 2.7 describes a way to securely send the client certificate. It
assumes that the client permits renegotiation after the first server
authentication. However, this requires more cryptographic computations
since both entities will encrypt the second TLS session packets and it
augments significantly the number of rounds trips over the wireless link,
which is not always widely available. Moreover, this sensitivity increases
a DoS attack's effectiveness against the authentication server, especially
in the case where the client is not configured to renegotiate a second TLS
session. It is IMHO useful to negotiate identity protection asap.

Hajjeh and I recently submitted a document to add identity protection to
TLS. This solution does not suffer from interoperability issues related to
TLS Extensions, TLS 1.0 and TLS 1.1 implementations. I would like that
EAP-TLS reconsider this document for identity protection implementations.
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,
Badra

> This is a working group last call for draft-simon-emu-rfc2716bis-05.
>
> Please send you comments to the emu list by December 29, 2006.
>
> The document can be accessed here:
> http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
>

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 01 Dec 2006 13:03:07 -0800

>However, this requires more cryptographic computations
>which is not always widely available.

As you point out, the approach described in the document is not optimal; 
rather the goal was to provide functionality that could be most easily 
implemented, and would be "good enough".

The computational load of encrypting additional packets is fairly small 
compared with the initial TLS negotiation, which may involve public key 
computations, so I don't think this is much of a burden.

I believe that the proposed approach adds 1.5 round trips to an initial 
conversation (session resumption is not affected).  As noted in the draft, 
ciphersuite negotiation could eliminate this.  On the other hand, the total 
number of round-trips in EAP-TLS is largely determined by the certificate 
chain size, which is the same whether privacy is supported or not.  So 
adding 1.5 round-trips for an initial exchange will typically not represent 
much of a performance penalty in intranet scenarios.

>EAP-TLS reconsider this document for identity protection implementations.

If and when identity protection ciphersuites are added to TLS, EAP-TLS 
implementations can support it.  I agree that it would be somewhat more 
efficient in terms of round-trips.

However, I don't think we want to require that EAP-TLS implementations 
wishing to implement privacy support identity protection ciphersuites.  For 
example, the set of Identity protection ciphersuites described in the 
document are limited, so that an EAP-TLS implementation might not be able to 
negotiate the ciphersuites that it would prefer along with identity privacy.

---

From: [email-masked]
Date: Fri, 1 Dec 2006 23:45:19 +0100 (CET)

Hi Bernard,

>So

Does the server send no empty certificate_request in each TLS session? If
then it will cost at least 2 more round-trips. Whatever, my concern is
about charging the server, especially when forged clients try to connect.
The authentication server will not be able to detect such an action early.

>the set of Identity protection ciphersuites described in the

Recently, there was a discussion on the TLS mailing list* regarding static
DH implementation, showed that the static DH ciphersuites rarely seems to
be supported, especially with
(http://www1.ietf.org/mail-archive/web/tls/current/msg00856.html)

- The Certicom SSL-C.
- cryptlib (definitely doesn't do static DH).
- PureTLS (hasn't tested static DH).
- OpenSSL

I don't know if TLS implementations of Microsoft support static DH
ciphersuites.

Identity protection ciphersuites supports all ciphersuites except those
based on static DH (static DH may be added, but not a full identity
protection will be therefore provided).

Best regards,
Badra

---

From: Jouni Malinen <[email-masked]>
Date: Thu, 14 Dec 2006 19:52:06 -0800

> This is a working group last call for draft-simon-emu-rfc2716bis-05.  

2.3.  Key Hierarchy

   Session-Id   = 0x0C || client.random || server.random

Isn't Session-Id usually the concatenation of the EAP type and some
session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP
type 13 (0x0D) and I would have expected to see 0x0D || ... here.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 18 Dec 2006 15:53:56 -0800

Thanks for catching this.  Yes, it is a typo.

>From: Jouni Malinen <[email-masked]>
>To: [email-masked]
>Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05
>Date: Thu, 14 Dec 2006 19:52:06 -0800
>