Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

The point is that the document's recommendations are based on using method specific identities to determine the EAP-Response/Identity. This is fundamentally broken because those identities are unrelated and the two identities  need not use the same formats or encodings - and as a result the advice based on this incorrect assumption would result in authentication failures, unacceptable delays and worse.

The document itself points this out - but does not recognize that the problem itself results from a false assumption.

> On Jul 20, 2015, at 14:06, lionel.morand@orange.com wrote:
> 
> Hi Bernard,
> 
> I tend to agree with Sam. I will review again the draft based on your comment. However I understand that the point is WHEN "Identity Response be used primarily for routing purposes ", there is some considerations to take into account to use it as user-name identity in RADIUS and Diameter. Everything else related to method-specific EAP identity (format, use, etc.) is out of scope of this document. At least it is my current understanding.
> 
> Lionel
> 
> -----Message d'origine-----
> De : radext [mailto:radext-bounces@ietf.org] De la part de Sam Hartman
> Envoyé : lundi 20 juillet 2015 13:30
> À : Bernard Aboba
> Cc : radext@ietf.org
> Objet : Re: [radext] Review of draft-winter-radext-populating-eapidentity-01
> 
>>>>>> "Bernard" == Bernard Aboba <bernard_aboba@hotmail.com> writes:
> 
>    Bernard>    One of the fundamental assumptions of this document is
>    Bernard> that the EAP-Response/Identity is somehow determined from
>    Bernard> the method-specific identities.  This is not correct, as
>    Bernard> RFC 3748 Section 5.1 makes clear:
> 
> Hi.  I was very confused to read this paragraph, because we've discussed this issue several times and I think we're all in agreement that the method-specific identities are not directly related to the eap response/identity.  I think that as the text you cite from RFC 3748 points out, the EAP response is often used for routing, so in many deployments there is some relation.
> 
> I stopped reading your review after this first paragraph, because I think that this disconnect colors the entire review.  I'd really appreciate it if you would explain why you think the document is assuming that the eap-response/identity is determined from method identities.
> I know that was not our intent.
> 
> I do think it's true that implementations sometimes derive both the eap response/identity and the method-specific identities from a common principal.
> Other implementations request both identities from the user.
> However, I don't know anything that tries to map back from a method identity to an eap response.
> 
> --Sam
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 