Re: [Emu] EAP and Fragmentation

[Alan DeKok]

On Mar 15, 2019, at 12:51 PM, slon v sobstvennom palto  
wrote:
> 
> >That is probably the correct behavior to standardize, i.e., something like
> >"Implementations MUST NOT set the L bit in unfragmented messages, but MUST 
> >accept unfragmented messages with and without the L bit set."
> 
> I'm for the strict approach. Anyway some implementations don't adhere it. The 
> sentence above narrows the behaviour to a non-ambiguous while requires to 
> support all kinds of existing behaviours thus it looks like the most exact 
> form of the requirement. 

  I agree.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and Fragmentation

[John Mattsson]

Alan wrote:

>I've done a quick check.  On reception, FreeRADIUS accepts the L bit for any 
>type of message.  It doesn't care >about fragments, just that the length is 
>correct.
>
 >For sending packets, FreeRADIUS sets the L bit only if it is sending 
 >fragments.

That is probably the correct behavior to standardize, i.e., something like

"Implementations MUST NOT set the L bit in unfragmented messages, but MUST 
accept unfragmented messages with and without the L bit set."

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and Fragmentation

[John Mattsson]

 Hi Oleg,

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

I added the following text to draft-ietf-emu-eap-tls13-04:

"EAP-TLS fragmentation support is provided through addition of a flags octet 
within the EAP-Response and EAP-Request packets, as well as a TLS Message 
Length field of four octets.  Unfragmented messages MAY have the L bit set and 
include the length of the message (though this information is redundant)."

I don't know if anything more if needed, but if we add something I think it 
should be "MUST accept" rather than "SHOULD accept".

The other alternative would be to instead write "Unfragmented messages MUST NOT 
have the L bit set and include the length of the message (though this 
information is redundant)."

I think we need to choose one and ensure that implementations following 
draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on 
how many implementations out there set the L bit for unfragmented messages and 
how many implementations do not accept unfragmented messages with the L bit set?

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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] EAP and Fragmentation

[John Mattsson]

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] EAP and Fragmentation

[Dr. Pala]

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, 

Re: [Emu] EAP and Fragmentation

[Dr. Pala]

Hi Alan,

thanks for the answers... aligned with what I thought and they do make 
sense... :D Further considerations inline...


On 2/12/19 11:26 AM, Alan DeKok wrote:

On Feb 12, 2019, at 12:36 PM, Dr. Pala  wrote:
[...]

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) ?

   No.

Too bad... :(

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.

   I suspect that it's difficult to "modify EAP".  However, adding a standard 
fragmentation method would be definitely useful.


I agree that (a) it would be useful and (b) it would be difficult to 
modify EAP :D It seems to me that EAP made a too simple header... :D



[ ... ]

   If it's an EAP type that only appears inside of a TLS tunnel, then don't 
worry too much about fragmentation.

   If the data you're sending will be larger than 64K, you *will* need to provide your 
own fragmentation support.  But that's only because the EAP header has a 16-bit 
"Length" field.

Yep, that is why the AVP/TLVs use the internal 'L' bit and the 32bits 
length field to address that. I think that to keep the method simple, we 
will require that the method is executed as an internal method of a 
Tunneled method that provides (a) authentication of the server (and 
optionally of the client), and (b) secrecy of the transferred data.


This allows us to:

 * Remove the support for Fragmentation (but we need to require that
   the data is appropriately handled by the encapsulating method)
 * Do not have to implement crypto-parameters negotiation for the outer
   tunnel

The draft will require a well-written security section to make sure that 
deployments do not use the method without proper security around it.



Looking forward to some great guidance and advice :D Also, if you would like to 
collaborate/contribute, please let me know!

   I've been known to have opinions.  :)  Plus, it's useful to have credential 
provisioning methods.

... and I've been known to have ears and eyes to listen and read :D That 
works perfectly!


Thanks for the feedback!

Cheers,

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and Fragmentation

[Mohit Sethi M]

Hi Oleg,

You are warmly welcome.

Not all methods use a TLS outer tunnel. For example: EAP-pwd has the following 
text:

EAP-pwd fragmentation support is provided through the addition of
   flags within the EAP-Response and EAP-Request packets, as well as a
   Total-Length field of two octets.  Flags include the Length included
   (L) and More fragments (M) bits.  The L flag is set to indicate the
   presence of the two-octet Total-Length field, and MUST be set for the
   first fragment of a fragmented EAP-pwd message or set of messages.
   The M flag is set on all but the last fragment.  The Total-Length
   field is two octets, and provides the total length of the EAP-pwd
   message or set of messages that is being fragmented; this simplifies
   buffer allocation.

As I said, having a method independent mechanism that could be re-used safely 
would make sense.

And thanks for pointing out L bit ambiguity in EAP-TLS. We should indeed fix 
this.

--Mohit

On 2/14/19 3:27 PM, slon v sobstvennom palto wrote:
Hi all,
These are my first steps in this group so please correct me if I don't follow 
the rules.

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.

~Oleg

On Thu, Feb 14, 2019 at 1:54 PM Mohit Sethi M 
mailto:mohit.m.se...@ericsson.com>> 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


___
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

Re: [Emu] EAP and Fragmentation

[slon v sobstvennom palto]

Hi all,
These are my first steps in this group so please correct me if I don't
follow the rules.

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.

~Oleg

On Thu, Feb 14, 2019 at 1:54 PM 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
> [image: OpenCA Logo]
>
> ___
> Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
>
> ___
> 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

Re: [Emu] EAP and Fragmentation

[Mohit Sethi M]

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and Fragmentation

[Alan DeKok]

On Feb 12, 2019, at 12:36 PM, Dr. Pala  wrote:
> 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. 

  IIRC, EAP was designed to be a protocol to carry other protocols, and nothing 
more than that.  Hence then 5 octet header, followed by (to be non-technical) 
data composed of "Uh... we're not sure... whatever..."  :)

> 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) ?

  No.

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

  I suspect that it's difficult to "modify EAP".  However, adding a standard 
fragmentation method would be definitely useful.

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

  The TLS-based EAP methods do pretty much the same thing:

EAP header
EAP type (TTLS, PEAP, TEAP, FAST)
TLS

  The rest is largely window-dressing.

  Since TLS provides it's own fragmentation layer, the above methods just use 
that.  There is very little method-specific code involved.

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

  EAP-PWD does multi-round authentication, and adds it's own fragmentation 
layer:

https://tools.ietf.org/html/rfc5931#section-4

  The method used is somewhat similar to TLS.

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

  I think so, yes.  Once you have a TLS tunnel set up, TLS largely takes care 
of fragmenting the application data.  So from the point of view of the 
application, it just sends and receives blocks of data, irrespective of the 
outer fragment size.

> Or should the method not have such assumptions and provide support for 
> explicit fragmentation control ?

  I have no idea how that would work.  The inner application data has no real 
way of knowing about the external fragment size, or even how much data is being 
added by the TLS layer.

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

  If it's an EAP type that only appears inside of a TLS tunnel, then don't 
worry too much about fragmentation.

  If the data you're sending will be larger than 64K, you *will* need to 
provide your own fragmentation support.  But that's only because the EAP header 
has a 16-bit "Length" field.

> Looking forward to some great guidance and advice :D Also, if you would like 
> to collaborate/contribute, please let me know!

  I've been known to have opinions.  :)  Plus, it's useful to have credential 
provisioning methods.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu