Hi Again, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Stefan Winter > Sent: Tuesday, August 12, 2008 6:45 AM > To: emu@ietf.org > Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 2 of 2 > > (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. > [Joe] I'm not sure this would be desirable.
> 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. > [Joe] So yes in some systems you either know what hash to send or ok can send a message telling the client that you need to salt with X and hash with y. However, there are systems where you only have access to a verifier which takes the password as input and gives you a result. This includes some OTP systems, but also includes systems based on static passwords. So in these systems there is no way around it. > 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, " > [Joe] I disagree, this is true. However, I agree that database may not be the right word here an may be the source of the issue. We can change this to verifier. > 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? > [Joe] Interesting, This needs to be discussed. > 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. > [Joe] I wouldn't assume that just because the tunnel supports i18n that the inner method does. I think it would be worthwhile to keep this 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). > [Joe] Maybe, the meta data needs to be associated with the methods though... Need to think about this. > 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. > [Joe]OK > 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? > [Joe] Yes some of this was discussed on a separate thread, I think we should add text that is a MUST for data external to the tunnel that gives an attacker an advantage if they can modify it, this may not be the entire header. > 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
