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

[Alfred Hönes <ah@xxxxxxxxx>]

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:  ah@xxxxxxxxx                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls