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

Hi bernard,

after a quick review, I think I understand your concerns.
I really think that the point is not to make any assumption on the method-specific ID that could be used in EAP-Response.
I think we can update the text to make it clear.

To sum-up, I would say that the intention of the draft is to:

- clarify that the EAP-Response can be used for routing
- When it is the case, two consequences:
    -  it may be needed to use different ids to reach different EAp servers, when a single EAP server cannot be used to support all the methods supported by the peer.
    - a specific encoding of the id encapsulated in the EAP-Response is required to ensure a correct use over RADIUS/Diameter

Do we agree?

Lionel

-----Message d'origine-----
De : Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Envoyé : lundi 20 juillet 2015 14:17
À : MORAND Lionel IMT/OLN
Cc : Sam Hartman; radext@ietf.org
Objet : 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.
> 

_________________________________________________________________________________________________________________________

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.