Re: [Emu] EAP and Fragmentation

[slon v sobstvennom palto]

Hi John,

>Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or
do the group want something different?

I remember that some EAP-TLS/PEAP clients rejected not fragmented messages
without L bit set, probably due to their wrong interpretation of EAP-TLS
RFC. Would it worth to say something like "Implementation SHOULD accept
unfragmented messages with and without L bit set" in addition to copying
the sentence above from RFC 5281?

Cheers,
Oleg


On Sun, Mar 10, 2019 at 2:39 PM John Mattsson 
wrote:

> Welcome and thanks for your comments Oleg!
>
> slon v sobstvennom palto ; wrote:
>
> >Per my experience the existing fragmentation method described in EAP-TLS
> >RFC 5216 serves good for all fragmentation needs. The method is reused by
> >PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS RFC
> that
> >doesn't specify whether a not-fragmented message should have the L bit and
> >the 4 octets length field so different peers treat it differently.
> However,
> >for example, EAP-TTLS RFC closed it tightly saying that even a
> >single-fragment message should have it nevertheless on its redundancy.
>
> I cannot find anything in EAP-TTLS (RFC 5281) saying that the L bit should
> be set. As you have noticed, EAP-TLS (RFC 5216) does not say anything about
> the L bit in unfragmented messages and my understanding is that the
> ambiguity is if unfragmented messages can (not should) have the L bit set..
> As far as I can see, EAP-TTLS (RFC 5281) states that unfragmented messages
> MAY set the L bit.
>
> RFC 5281 Section 9.2.2:
>
>“Unfragmented messages MAY have the L bit set and include the
> length of the message (though this information is redundant).”
>
> I looked through the other TLS-based EAP methods (both RFCs and drafts)
> and none of them seems to say anything new about the L bit.
> draft-ietf-emu-eap-tls13 should clarify any ambiguity.
>
> Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or
> do the group want something different?
>
> Cheers,
> John
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Run EAP-NOOB implementation

[Aleksi Peltonen]

Hi Thien Nguyen,

Thank you for your interest in hacking with our group during the 
hackathon, I look forward to working with you!


I'm happy to help you debug this issue, but let's take this separately 
off-the-mailing list. If we find some issues in the spec that need to be 
addressed, we can bring it back to the EMU mailing list.


Best regards,
Aleksi

On 13/03/2019 16:09, Thien Nguyen wrote:


Hello all,

I'm considering enrolling in the Hackathon with EAP-NOOB so I've been 
trying to run the implementation that you have posted at 
https://github.com/tuomaura/eap-noob but I have not succeeded.


I have followed the steps indicated in the README and the EAP 
communication always ends in Failure. The identity n...@eap-noob.net 
 is sent and the EAP-Request message is 
returned with the empty Identity field.


Is there any additional information or any configuration that I need 
to know in order to execute the scenario? Or could you provide sample 
information that needs to be added to the configuration files for 
execution?


I would also like more information on how the client is simulated. 
Does the wpa_auto_run.py script do it? Should I run some other program 
to complete the authentication process or how can I get the OOB code?


I apologize if this is not the right place to send this email.

Thank you very much for your attention.
Greetings,
Thien Nguyen.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC for RFC5448bis

[Mohit Sethi M]

Hi Jari and co-authors,

The WGLC for this document is now complete. Can you please address the minor 
comments provided by John and upload a new version.

The following 2 papers on the AKA protocol were also brought to our attention:
1. https://eprint.iacr.org/2018/1175.pdf
2. 
http://homepage.divms.uiowa.edu/~comarhaider/publications/LTE-torpedo-NDSS19.pdf

It might make sense to mention them in the security considerations section with 
text explaining how they affect AKA, and whether any updates to address them 
would also require changes to EAP-AKA'?

Joe and Mohit

On 2/14/19 3:58 AM, Joseph Salowey wrote:
This is the working group last call for 
draft-ietf-emu-rfc5448bis-04.
  Please send your comments to the list by 3/1/2019.

Thanks,

Joe and Mohit



___
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