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

[Stefan Winter <[e-mail]>]

Hi,

> 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.

The "assumption" comes from observing the implemented reality of a vast
multitude of supplicants, be those fundamentally broken or not. Since
we're aiming at a BCP document, I think we should take reality into account.

Greetings,

Stefan Winter

>
>
>> On Jul 20, 2015, at 14:06, [e-mail] 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:[e-mail]] De la part de Sam Hartman
>> Envoyé : lundi 20 juillet 2015 13:30
>> À : Bernard Aboba
>> Cc : [e-mail]
>> Objet : Re: [radext] Review of draft-winter-radext-populating-eapidentity-01
>>
>>>>>>> "Bernard" == Bernard Aboba <[e-mail]> 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
>> [e-mail]
>> 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.
>>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext