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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
