Re: [Emu] EAP and Fragmentation

["Dr. Pala" <[e-mail]>]

Hi Mohit, all,

somehow I skipped this message... :( Sorry ... anyhow - I do not have a 
draft on that, and I am not even sure how this could be structured - 
maybe this could be a BCP ? I actually came across another building 
block that might be useful: an easy way to negotiate a key and an 
encryption algorithm across the two parties.

Today, in the wild, we tend to use EAP-TLS, EAP-TTLS, or other more 
ad-hoc mechanisms to provide channel authentication and encryption 
(e.g., EAP-NOOB). However, also in this case, having a re-usable 
mechanism (possibly more light-weight than  the full TLS stack) to do 
that, would be great. I admit that this might have broader applicability 
rather than "just" EAP, however it definitely fits the need in EAP.

In particular, what I am talking about is a "general" 3-way handshake : 
what fields should be there, what should not be there in  the messages. 
Something on these lines (A = Client, B = Server):

  * [A] { Supported Encryption Algorithms List,
            Supported Key-Exchange Algorithms List,
            Encryption Initialization Data,
            MSG Authentication } -> [B]

  * [B] { Selected Encryption Algorithm and Params,
            Selected Key-Exchange Algorithm and Params,
            Key-Exchange Params (e.g., ECDHE),
            (Optional) Credentials (e.g., Certificate Chain),
            Encryption Initialization Data,
            MSG Authentication } -> [A]

  * [A] { Selected Encryption Algorithm and Params,
            Selected Key-Exchange Params (e.g., ECDHE),
            Key-Exchange Params (e.g., ECDHE),
            (Optional) My Credentials Encrypted (e.g., Certificate Chain),
            MSG Authentication } -> [B]

that could be re-used by developers when they need a secure channel but 
they do not need to support ALL the TLS features (e.g., session 
resumption, key rotation, etc.). Can we have a generic message 
definition that can then be encoded in different formats for different 
environments. For EAP... we would use EAP messages :D In other 
environments this could be encoded with different structures and 
encodings (e.g., DER, JSON, XML, CBOR, etc.)

Maybe we can write a BCP for EAP that includes both building blocks 
(i.e., Fragmentation and Simple Authentication and Encryption) ?

What do you think ?

Cheers,
Max


On 2/14/19 4:54 AM, Mohit Sethi M wrote:
>
> Dear Dr. Pala,
>
> On 2/12/19 7:36 PM, Dr. Pala wrote:
>>
>> Hi all,
>>
>> I am working on a draft for credentials management via EAP. When 
>> looking at the different specifications, it seems a bit weird that 
>> EAP does not provide Fragmentation control and requires each method 
>> to define their own way.
>>
>> /*This, led me to my first question:*/ is there a de-facto "standard" 
>> way to add Fragmentation support we can just use (without having to 
>> re-invent the wheel all the time) ? If we had such a mechanism, then 
>> we could just say "implement the mechanism as defined in ... ". This 
>> would definitely help developers that could safely re-use 
>> code/libraries. The other approach would be to modify EAP to add 
>> Fragmentation support there. The main reason to have a standard 
>> behavior is to have also better management for ack and nak packets. 
>> As far as the solution goes, the main ones I looked at are the ones 
>> mentioned in EAP-TTLS and EAP-TEAP. They are both practically the 
>> same, active ACK-based - are there other methods that have been 
>> implemented ? Has anybody ever looked at how fragmentation is handled 
>> in practice and if there are better solutions than others ?
>>
> No hat: I think having a standard mechanism for supporting large 
> messages and fragmentation independently of any particular EAP method 
> would definitely be something useful. As you said, it would allow 
> developers to safely re-use code. If you have a draft proposal, I 
> would be happy to review it. Perhaps we could start by looking at 
> existing mechanisms used by EAP-Pwd/EAP-TTLS.
>
> --Mohit
>
>> /*Further thinking let me to my second question:*/ the method we are 
>> going to propose requires some form of authentication for the server, 
>> therefore I can see its use mainly as a tunneled method where the 
>> communication with the server is assumed to be already secure. If we 
>> go down the route of requiring the use of an outer method that 
>> provides authenticity and, optionally, confidentiality we would also 
>> not need to provide support for Fragmentation control, since the 
>> records would be encapsulated within the outer-method messages that 
>> already provide fragmentation support. Would this be acceptable ? Or 
>> should the method not have such assumptions and provide support for 
>> explicit fragmentation control ? What would be the preferred path 
>> here ? I personally would like to have a method that could be used 
>> independently, but I would also like to focus on simplicity of 
>> implementation so that if you already have EAP-TTLS/EAP-TEAP support, 
>> adding support for EAP-CREDS would be very simple.
>>
>> Looking forward to some great guidance and advice :D Also, if you 
>> would like to collaborate/contribute, please let me know!
>>
>> -- 
>> Best Regards,
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>> OpenCA Logo
>>
>> _______________________________________________
>> Emu mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/emu
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo