Subject: [TLS] draft-nir-tls-eap-03

From: Alfred Hönes <[email-masked]>
Date: Thu, 24 Apr 2008 20:42:07 +0200 (MESZ)

Hello,
I would like to submit a few comments on your Internet-Draft,
draft-nir-tls-eap-03.

(1)  Section 1

Section 1 IMHO is too silent about the benefits obtained from
this proposal.

Arguably, there's too much stuff in the Abstract that at least
should be restated or elaborated upon early in Section 1, e.g.,
near the end of the second paragraph there.

(2)  Section 2

The second paragraph of Section 2 says:

                                    [...].  Typically the AAA server
   communicates using the RADIUS protocol with EAP ([RADIUS] and
   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).

It should better say:

                                    [...].  Typically the AAA server
|  communicates using the RADIUS protocol with EAP extensions ([RADIUS]
                                                   ^^^^^^^^^^^
   and [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).

(3)  Section 3.1

The TLS extension framework now is part of rfc4346bis (already
being operated upon by the RFC Editor), whereas 4366bis only
specifies a few useful TLS Extensions using this framework.

When it comes to updating the references, this makes things a bit
complicated.  Perhaps the draft should clearly distinguish TLS 1.1
and TLS 1.2 -- or it should restrict its scope to TLS 1.2.

(4)  Section 3.4

The assignment operator is missing in the formula for `verify_data`;
it should be:

     verify_data = PRF (MSK, ...) [0..11] ;
                 ^

The second-to-next paragraph apparently also should refer to this
field:
       vvvvvvvvvvvvvvvvvv
|  The handshake_messages field, unlike regular TLS, does not sign all
   the data in the handshake.  [...]
---    vvvvvvvvvvv
|  The verify_data field, unlike regular TLS, does not sign all the data
   in the handshake.  [...]

Also, at the end of that paragraph,    s/[TLS]and/[TLS] and/  .
                                                       ^
(5)   Section 4.3, alternative 2.

Doesn't this variant suffer from a MITM vulnerability?
This would totally invalidate the most significant contribution
of this proposal, ID protection !
If I do not err w.r.t. this threat, the draft should further
elaborate on this issue.

(6)  Section 10

(6a)  s/reviewrs/reviewers/     (2x)

(6b)  Re "Finished" / "EapFinished" / "InterimAuth"
 
A possible alternative would have been to amend the Finished
message format with an optional field indicating the nature /
semantics of the particular instance of the message, and
formally use the same handshake message for both purposes
(subject to successful negotiation of tee_supported),
but this variant would perhaps have been more complicated
to specify within the extensibility rules of TLS; since
there's no danger of namespace exhaustion for handshake
message types, the selected design seems to be reasonable.

(6c)  Re EAP exported keying material

Don't make things overly complicated.

The subject of the extension is TLS client authentication.
Hence, the expected output is Boolean -- ok to proceed, or
abort the TLS handshake.

(6d)  Re identity protection

That's a feature that will become even more important in the
future.   There are already so many leaks for information
passed around in the internet, and information privacy is
one of the most valuable assets we have, that identity
protection will be necessary more and more, and it's well
worth a single additional round-trip!

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Apr 2008 16:19:51 +0300

Hello,

Thank you for reviewing our draft and for your helpful comments.

With regard to section 1 and the abstract, I agree that the abstract  
is too long and a lot of the stuff that's in the abstract would be  
more appropriate in section 1. We will rewrite them along those lines  
in the next iteration.

Regarding section 3, we will make the distinction in the text between  
TLS 1.1 and 1.2. We certainly do not wish to restrict our draft to TLS  
1.2.

Regarding section 4.2 (comment (5)) I also believe that identity  
protection is important, but that belief is not universally shared.  
For example, the TLS-PSK protocol does not provide it. I'm not sure  
what I can do to elaborate more on this, except to say (as we have)  
that "we believe that identity protection is a worthy enough goal, so  
as to justify the extra round-trip.".  Can you suggest anything  
stronger?

In comment (6) you seem to agree with the choices we have made so  
far.  We will also of course fix the typos that you have pointed out.

Thanks again for taking the time to review our draft.

Yoav

On Apr 24, 2008, at 9:42 PM, Alfred HÎnes wrote:

>  Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>
>
> Scanned by Check Point Total Security Gateway.
>