(continuing from 4.2.2 on)
4.3 Tunnel payload reqs
----------------------------------
The criteria in this section seem to make it impossible to use the
described tunnel method as an inner payload itself (i.e. prevents
stacking of the method defined in this document above each other). I'm
not sure if there's a use case for doing so, but seems like it's
restricting where it wouldn't need to be.
4.5 Carrying U-N and PWs
--------------------------------------
It is true that legacy dbs need the clear text password. They don't
always need to have it transmitted from the client though (if they have
it stored clear-text in the db, they can do with a one-way hash from the
client). The half-sentence "hence they require the peer to send the
clear text user name and password to the EAP server" is wrong. The para
reads as if there is no way around sending the password in clear from
EAP peer to server.
4.5.1 Security
-------------------
Since the precondition in 4.5 above isn't true, the introductory para
needs to be re-worded. Maybe "Due to the fact that some legacy password
databases require the EAP peer to send clear text passwords to enable
the EAP server to authenticate them, "
4.5.1.2 Auth of server
------------------------------
section 3.5 specifies that the tunnel method MAY allow for a bypass of
server authentication. 4.5.1.2 forbids this bypass, meaning the use case
in 3.5 is badly catered by the tunnel method specified in this document,
if this tunnel method is used in conjunction with legacy password
databases. Maybe this is worth mentioning?
4.5.2 i18n
--------------
The MUST/SHOULD pair in the last sentence is already specified as a
tunnel payload req in general in 4.3.6 and doesn't need to be repeated here.
4.5.3 + 4.6.5 Meta-Data
--------------------------------
Meta-data is MUST in both of these sections (i.e. for password-based
auth and EAP auth), identical wording. To avoid duplication, it might
make sense to move this statement into the general requirement section
for tunneled payload (4.3).
6.1 Ciphersuite selection
-----------------------------------
The last para is a nice recitation on why mutually anonymous tunnels are
bad. It does not state the relation of this fact to the requirements
document though. Adding a sentence that this risk has been taken care of
by requiring server auth would tie the paragraph into the document.
6.3 Outer EAP Method Header
-------------------------------------------
This section has good arguments why to protect the header of the message
exchange. Still, this is only a SHOULD in the document. The para here
suggests that it might better be a MUST. What are the reasons for the
SHOULD?
Greetings,
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
