Subject: [eap] Presentations from IETF 60

From: Bernard Aboba <[email-masked]>
Date: Fri, 6 Aug 2004 03:50:05 -0700 (PDT)

are available at:
http://www.drizzle.com/~aboba/IETF60/eap/
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 06 Aug 2004 13:47:34 +0200

Dear Aboba, Arkko and all,

In the http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsprocess.ppt, 6th slide you wrote:

"We need High quality contributions (maybe PKS/IKEv2/PAX?)"

As long as I feel, these new contributions will be based on pre shared key instead of the PKI based-certificate. 
If this is the case, I would like to know the objective of the definition of new methods based on pre shared key outside TLS or IKEv2.

Badra

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 6 Aug 2004 18:13:27 +0200

hi badra, 

actually the text should read: 

"We need High quality contributions (maybe PKS/EAP-IKEv2/PAX?)"

i hope that this clarifies things a bit. 

ciao
hannes

> In the 
> http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsproce
> ss.ppt, 6th slide you wrote:
> 
> As long as I feel, these new contributions will be based on 
> pre shared key instead of the PKI based-certificate. 
> If this is the case, I would like to know the objective of 
> the definition of new methods based on pre shared key outside 
> TLS or IKEv2.
> 
> Badra
> 
> 
>

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 06 Aug 2004 18:56:01 +0200

Hi Hannes,

Maybe I wasn't very clear in the last mail. 
When I asked about that, I was thinking about PSK, PAX and other methods use pre shared key. Your draft is different, it proposes to re-use a derivation from IKEv2. My question was: Why we need (the goal) to define new pre shared key methods, that are NOT based on TLS or IKEv2.

badra

-- 
Mohamad Badra
ENST-Paris
Dept. Computer Sciences and Networks

---

From: "T. Charles Clancy" <[email-masked]>
Date: Sat, 7 Aug 2004 10:53:15 -0400 (EDT)

On Fri, 6 Aug 2004, Mohamad Badra wrote:

> My question was: Why we need (the goal) to define new pre shared key
> methods, that are NOT based on TLS or IKEv2.

The primary reason is simplicity.  In particular, there is a lot of
overhead required to establish and use a TLS tunnel.  The goal of PSK is
utmost simplicity, while PAX aims to implement a few more features with
added complexity.  However both protocols are simpler than alternatives
such as MS-CHAP inside TTLS or PEAP.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 07 Aug 2004 18:08:23 +0200

Please treat my comments kindly 

>overhead required to establish and use a TLS tunnel.  
>
>  
>
Let's do a comparison concerning the simplicity. There are also flexibility, compatibility, and maybe... security.

Simplicity:

===========

I have between my hands a trace of TLS-PSK and I computed the necessary

bytes to forme a secure session and the cryptographique operation

needed to calculate the keys and the necessary authentication's

operations. (I don't have to write new code and to analyse the TLS-PSK):

Exchanges:

----------

ClientHello --> 101* octets (include 11 cipher_suites (22
octets) and one compress_methode (1 octet), session_id on 32 octets)

               server_hello (79* octets)

               ChangeCipherSpec (6* octets)

           <--    Finished (37* octets)

ChangeCipherSpec (6* octets)

Finished (37* octets)

*each of these contains already 5 octets for the Record protocol)

In total, we have 260 octets (I guess that it is less than DH parameters), only 1.5 Round Trips.

Crypto calculation:

-------------------

One PFR for the master_secret, one PRF for Key_block, two for each Finished message. in total, six PRFs.

Two symetric encryptions/decryptions and 2 MACs (Maybe I forget something). Neither Deffie-Hellman nor RSA.

call back TLS:

--------------

If the server or the client insists on sending the certificate, a full TLS will be performed.

Key update:

-----------

Not exists, but very easy to add. A simple example: 
(1)replaces the pre_shared_key with PRF(pre_shared_key, "update pre shared key",
ServerHello.random + ClientHello.random)[0..47];

(2)destroy the old pre_shared_key

Usage:

------

extension to EAP-TLS, easely use for EAP-TTLS, EAP-TLS-EAP, EAP-FAST, EAP-Double-TLS, EAP-3GPP2-WLAN (3GGP2 Security WG), etc.

Code:

-----

One day of development

Operating System:

----------------

All the OS known today

>The goal of PSK is
I don't talk about MS-CHAP, I wanted to compare them with TLS-PSK.

I expect the authors of EAP-pre_shared_keys methods to do a comparison with TLS-PSK.

Note: we have today about 4 contributions proposed to TLS WG to use PSK
with TLS, they are all simples. I talked in this mail about
draft-ietf-tls-sharedkeys-02).

Sincerely,

---

From: "T. Charles Clancy" <[email-masked]>
Date: Sun, 8 Aug 2004 16:33:44 -0400 (EDT)

> I expect the authors of EAP-pre_shared_keys methods to do a comparison

Sorry, I didn't realize you were talking about TLS-PSK in your earlier
messages.  When I think of TLS, I automatically think "public key".

If TLS-PSK does indeed only require 1.5 round trips, it would accomplish
something similar to EAP-PSK.  I could argue some other differences, but I
think I'll leave that to Florent.

As far as EAP-PAX goes, it includes features that cannot be accomplished
with just TLS-PSK, including secure provisioning with a weak key and
identity protection.

With respect to simplicity, something that both PSK and PAX try to achieve
is avoid using redundant, extensible APIs.  I'm just waiting for the day
we start doing public-key authentication by tunneling PKINIT over Kerberos
over EAP-GSS over TLS over PEAP over EAP.

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 09 Aug 2004 14:11:01 +0200

>think I'll leave that to Florent.
I wait so :)

>with just TLS-PSK, including secure provisioning with a weak key and
For info, we have today the following contributions for Pre Shared Key with TLS:

  (1) No identity protection, no PFS contributions:

      o [TLS-PSK] no identity protection, no PFS; available at http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt
      o [TLS-SHAREDKEYS] no identity protection, no PFS (expired and available at http://www.ietf.org/proceedings/03nov/I-D/draft-ietf-tls-sharedkeys-02.txt
      o [TLS-EXPRESS] no identity protection, no PFS; available at http://ietfreport.isoc.org/ids/draft-badra-tls-express-00.txt

  (2) Identity proection and PFS contributions:

      o [TLS-SRP] identity protection, PFS, secure provisioning with a weak key; available at http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-07.txt
      o [TLS-KeyExchangeMethod] identity protection, PFS, secure provisioning with a weak key; available at http://www.infres.enst.fr/~badra/draft-badra-cherkaoui-hajjeh-serhrouchni-tls-key-exchange-00.txt (I will send it today to IETF secretariat).

>is avoid using redundant, extensible APIs. 
>
Sorry, but I didn't understand what do you mean by that :s

---

From: "T. Charles Clancy" <[email-masked]>
Date: Tue, 10 Aug 2004 10:48:28 -0400 (EDT)

On Mon, 9 Aug 2004, Mohamad Badra wrote:

>       o [TLS-SRP] identity protection, PFS, secure provisioning with a
> weak key; available at
> http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-07.txt

Doesn't SRP has IP issues?  While its licenses are free, there have been
claims it infringes on the SPEKE patent.  There's also an EAP-SRP, but I
believe it's been abandoned.

>       o [TLS-KeyExchangeMethod] identity protection, PFS, secure
> provisioning with a weak key; available at
> http://www.infres.enst.fr/~badra/draft-badra-cherkaoui-hajjeh-serhrouchni-tls-key-exchange-00.txt
> (I will send it today to IETF secretariat).

Correct me if I'm wrong, but if I'm reading this correctly, the server is
required to have a certificate.  (IMHO, you need an overview section in
this draft that describes in general how your protocol works.)  One of the
advantages of PAX is that a certificate is only used if identity
protection or provisioning is being done.  The rest of the time, it is
purely symmetric.

> Sorry, but I didn't understand what do you mean by that :s

For example, EAP, TLS, and krb5 are all authentication protocols.  They
all allow authentication using a miriad of methods and ciphersuites.  Why
use two or three stacked on top of each other when one is sufficient?
IMHO, for simple, secure methods you only need one layer between the
authentication protocol and the lower levels.  Sure, we could implement
PSK over TLS over EAP, but why overcomplicate things?

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 10 Aug 2004 17:25:10 +0200

>believe it's been abandoned.
I agree that some serious IPR are exist with SRP. 

>required to have a certificate.  
>
Not really, I said the server MAY use a certicate (section 2.6). Let me explain something here: the client and the server authenticate each other via the Finished messages. In fact, these Finished messages are computed using keys derived from the PSK XOR premaster secret. 
So, the server does NOT need a certificate. Now, if we suppose that the client connects to a bogus server, this later will be detectable thank to the Finished message. Instead, I said that the server MAY use a certificate to detecte such attack in the early handshake messages.

>(IMHO, you need an overview section in
>this draft that describes in general how your protocol works.)  
>
I said that it extends the TLS with PSK and in the section 2.6. of the draft, the handshake phase is briefly described.
But why not, the draft is a -00 version and I can add some text inside :)

>One of the
Yes, you are right in that. But In [TLS-KeyExchangeMethod], identity protection SHOULD be done without any certificate. However, an asymetric operation is needed. 
On the other hand, even if you want to use the "no identity proection and no PFS contributions" cited above, you can extend these contributions for EAP authentication or for other use. For example, with a simple pseudonym management mechanism, you can obtain PFS and identity protection using these contributions.

Badra

---

From: Florent Bersani <[email-masked]>
Date: Mon, 16 Aug 2004 16:20:17 +0200

Dear Mohammed,

Sorry to catch up late on this one!

I am glad you asked your question: "I would like to know the objective 
of the definition of new methods based on pre-shared key outside TLS or 
IKEv2. "

As you surely have noticed in the presentation I gave at IETF 60 
(available under the name ietf60_eap_pskv2.ppt in the bundle 
http://www.drizzle.com/~aboba/IETF60/eap.zip), half of the slides where 
devoted to general discussion on Pre-Shared Key methods (while the 
remaining half was on EAP-PSK). Moreover, in the first slide, among the 
possible pre-shared key methods, I quoted TLS with PSK and EAP-IKEv2...

Thus, I am utterly convinced that before bringing up something new 
(e.g., an EAP method), one should first state clearly its design goals 
and second compare the new proposal to the existing work - I have 
humbly  attempted to do so in the EAP-PSK draft (see 
http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html 
section 1.1 "design goals" and section 1.6 "related work"). But I 
wholeheartedly agree that more work, at least one section 1.6, would do 
no harm ;-)

Before I get into some tentative explanations and comments, could I 
broaden your question? I'd rather have it as: "what should be the goals 
of a pre-shared key EAP methods". Indeed, the question why we would need 
EAP-TLS with pre-shared key support and could not be simply satisfied 
with EAP-IKEv2 also deserves, IMHO, an answer ;-)

I am unfortunately not yet very familiar with the precise goals of 
TLS/IKEv2 reuse for EAP... which kind of precludes a thorough apples to 
apples comparison with other Pre-Shared Key EAP methods (e.g., with 
EAP-PSK). These goals could be:

--------------

1) Reuse of the underlying cryptography.

While I totally support IKEv2 and its very nice cryptography mainly 
based on H. Krawczyk's work SigMa 
(http://www.ee.technion.ac.il/~hugo/sigma.html), I am less convinced by 
TLS.

This comes from:
a) the difficulties for formally analyzing TLS (to quote E. Rescorla's, 
D. Boneh's and H. Shacham's "Client Side Caching for TLS" paper - 
available at http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf - 
section 3.6 "Unfortunately, a formal argument about the security of 
fast-track as a handshake protocol is extremely difficult, especially in 
the absence of a comprehensive formal analysis of TLS"), which was not 
designed with the provable cryptography in mind, contrary to IKEv2
b) TLS being designed with public and not pre-shared keys in mind, 
contrary to IKEv2 that from the start allowed such credentials

I am by no way giving here an "authoritative evaluation" on the 
cryptography of TLS (because I am not qualified to do so ;-) & :-() but 
rather a (semi)-educated opinion... Of course TLS has received a fair 
deal of cryptographic review, it is widely used and believed to be 
"secure" (whatever this vague assertion may mean).

2) Reuse of the underlying network protocol

Here, I tend to think that more analysis would have to be done for TLS 
and IKEv2

Indeed, TLS was natively designed to run over TCP which is IINM not 
exactly the type of connection of EAP offers ;-) Yes TLS is being worked 
on to adapt it to datagram transfer (DTLS, 
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt)... but 
this is work in progress and does not change anything to the fact that 
TLS was not designed to be run over EAP. Such a reuse probably deserves 
some attention and might bring up some issues.

Furthermore, IKEv2 includes many IP-centric features that seem to be 
inappropriate for EAP, see the nice job EAP-IKEv2 does at pruning IKEv2.

So, here I would say that a careful aspect of the networking aspects of 
the protocols are in order before they are reused for EAP.

3) Reuse of existing implementations

Given the number of TLS implementations out there (or the expected 
number of IKEv2 implementations), wouldn't it be nice as the beach boys 
sang, to leverage them for EAP?

Yes, but:
1) How many TLS implementations out there support pre-shared keys?
2) How much work is needed to prune/adapt these implementations to make 
an EAP method?
3) How "big" (code size) and "efficient" (CPU+memory consumption) are 
these implementations
4) ....

--------------

The above discussion might have seemed biased towards criticizing 
EAP-TLS and EAP-IKEv2 all the more that I designed EAP-PSK. It was not 
my goal (as I like very much EAP-IKEv2 at least ;-)). I rather tried to 
show that, although reuse of existing work is generally a sound 
cryptographic practice (for networking I don't know), there are some 
additional questions that would benefit from more analysis! I welcome 
your original question as an invitation to such an analysis. In fact, I 
am working right now on this matter: what should be the goals for an 
EAP-Pre-Shared Key method? Is there hope that such a method may be made 
available to the community?

I think that this analysis is very much complicated by the way EAP 
historically worked: in the old times, there has been the (polemic) 
choice not to charter the EAP WG to design EAP methods... and now that 
there seems to be an opening to do so, I must confess that it is quite 
late given the number of (proposed or implemented) methods out there... 
Mergers seem tricky, all the more that perhaps there allegedly could not 
be "one size fit all"....

Anyway, here are some comments on EAP-PSK:

1) EAP-PSK had to be quickly available (for practical purposes - I know 
a telco out there which wanted such a method ;-)). I am not sure how 
long it will take before TLS incorporates pre-shared key support (given 
the number of individual I-Ds you submitted ;-)) - although the TLS WG 
item http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt seem 
quite mature. Of course, I agree that the time-to-market requirement 
might not hold if we get to standardize a pre-shared key EAP method 
(though it might). Thus EAP-PSK had to be simple (I tend to think that 
RFC 2246 or Eric Rescorla's book requires more time to read...).

2) EAP-PSK has been designed with EAP in mind (message size, number of 
messages, fragmentation, lock step protocol, server initiated).

As Tom noted, I congratulate you for your 1,5 round trip TLS with 
pre-shared key exchange... but you might want to add a very useful 
EAP-TLS/start message like in RFC 2716 ;-). EAP-PSK uses 2 round-trips.

For the message size, I appreciated the figures you give (which are 
neither that big nor that small)... but I have a problem to give 
comparable figures as EAP-PSK message size (logically) depends on the 
size of the peer NAI (and also the server NAI in v4 to come). So the 
best I can do, is to say that EAP-PSK largest message size (that is 
without EAP headers) for now is max(32+peer NAI size.,37) in octets 
(IIRC your sizes were in octets: 101, 122, 43).

For the cryptographic calculations, I failed to understand your computation:
"One PFR for the master_secret, one PRF for Key_block, two for each 
Finished message. in total, six PRFs
Two symetric encryptions/decryptions and 2 MACs (Maybe I forget 
something). Neither Deffie-Hellman nor RSA."
I guess that to be meaningful (at least to me ;-)), these figures would 
have to specify
a) which computations are realized only once and which are done at each 
authentication exchange
b) which are done by the client and which are done by the server (if you 
have two PRFs for the finished message, why do you have only one for the 
key block?)
c) the performance of the cryptographic modes of operation
d) which are the cryptographic primitives that are used - optional at 
first but perhaps required in the mid term though cryptographic 
performance is not a sinecure (platform, optimized code, I/O and cache 
size issues, etc.). I bet there is some speed difference between SHA-1 
and AES. Whether these fine performance discussions are relevant may not 
be obvious in some cases
Nevertheless, to try and answer your figures, for EAP-PSK, we have:
1) a one-time PRF invocation for the client and another one for the server
2) at each authentication 2 MACs, 1 encryption and 1 key derivation for 
the client and the same computations for the server

3)  EAP-PSK has been designed to be implemented over any type of devices 
(including low-cost ones) - figures to come in an upcoming paper.

To sum up, I think we should further investigate the possible design 
goals for a pre-shared key EAP method. TLS with PSK, EAP-IKEv2, EAP-PSK, 
EAP-PAX... all have their pros and cons which should *all* be analyzed.

I hope  I have clarified some points on EAP-PSK.

BR,
Florent

Mohamad Badra wrote:

> http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsprocess.ppt, 
> 6th slide you wrote:
>
> As long as I feel, these new contributions will be based on pre shared 
> key instead of the PKI based-certificate. If this is the case, I would 
> like to know the objective of the definition of new methods based on 
> pre shared key outside TLS or IKEv2.
>
> Badra
>
>
>

---

From: Florent Bersani <[email-masked]>
Date: Mon, 16 Aug 2004 16:34:21 +0200

Thanks again to Mohammed for the nice point he raised and to Tom and 
Mohammed's enlightening conversation!

Would there be others out there interested in defining/refining possible 
goals for Pre-Shared Key EAP methods and why not, compare the different 
proposals according to these goals (sth like jfk-sigma comparison, 
although I am afraid that EAP-PSK is not a match against the two 
aforementioned protocols ;-))?

Although the two cents I have just brought to the debate, could be 
misinterpreted, I really wanted to, as objectively as I could, divert 
the debate from a matter of taste on method A vs. method B to a 
technical comparison of pre-Shared Key methods... which essentially 
remains to do.

I am not sure how this can best be done. I have crunched privately on it 
for a while. I am not sure that this mailing list is the more 
appropriate place. Any ideas?

Florent

Florent Bersani wrote:

> of the definition of new methods based on pre-shared key outside TLS 
> or IKEv2. "
>
> http://www.drizzle.com/~aboba/IETF60/eap.zip), half of the slides 
> where devoted to general discussion on Pre-Shared Key methods (while 
> the remaining half was on EAP-PSK). Moreover, in the first slide, 
> among the possible pre-shared key methods, I quoted TLS with PSK and 
> EAP-IKEv2...
>
> wholeheartedly agree that more work, at least one section 1.6, would 
> do no harm ;-)
>
> broaden your question? I'd rather have it as: "what should be the 
> goals of a pre-shared key EAP methods". Indeed, the question why we 
> would need EAP-TLS with pre-shared key support and could not be simply 
> satisfied with EAP-IKEv2 also deserves, IMHO, an answer ;-)
>
> TLS/IKEv2 reuse for EAP... which kind of precludes a thorough apples 
> to apples comparison with other Pre-Shared Key EAP methods (e.g., with 
> (http://www.ee.technion.ac.il/~hugo/sigma.html), I am less convinced 
> by TLS.
>
> This comes from:
> a) the difficulties for formally analyzing TLS (to quote E. 
> Rescorla's, D. Boneh's and H. Shacham's "Client Side Caching for TLS" 
> paper - available at 
> http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf - section 3.6 
> "Unfortunately, a formal argument about the security of fast-track as 
> a handshake protocol is extremely difficult, especially in the absence 
> of a comprehensive formal analysis of TLS"), which was not designed 
> with the provable cryptography in mind, contrary to IKEv2
> cryptography of TLS (because I am not qualified to do so ;-) & :-() 
> but rather a (semi)-educated opinion... Of course TLS has received a 
> fair deal of cryptographic review, it is widely used and believed to 
> be "secure" (whatever this vague assertion may mean).
>
> exactly the type of connection of EAP offers ;-) Yes TLS is being 
> worked on to adapt it to datagram transfer (DTLS, 
> TLS was not designed to be run over EAP. Such a reuse probably 
> deserves some attention and might bring up some issues.
>
> So, here I would say that a careful aspect of the networking aspects 
> of the protocols are in order before they are reused for EAP.
>
> number of IKEv2 implementations), wouldn't it be nice as the beach 
> boys sang, to leverage them for EAP?
>
> Yes, but:
> 2) How much work is needed to prune/adapt these implementations to 
> make an EAP method?
> my goal (as I like very much EAP-IKEv2 at least ;-)). I rather tried 
> to show that, although reuse of existing work is generally a sound 
> your original question as an invitation to such an analysis. In fact, 
> I am working right now on this matter: what should be the goals for an 
> EAP-Pre-Shared Key method? Is there hope that such a method may be 
> made available to the community?
>
> late given the number of (proposed or implemented) methods out 
> there... Mergers seem tricky, all the more that perhaps there 
> allegedly could not be "one size fit all"....
>
> 1) EAP-PSK had to be quickly available (for practical purposes - I 
> know a telco out there which wanted such a method ;-)). I am not sure 
> how long it will take before TLS incorporates pre-shared key support 
> (given the number of individual I-Ds you submitted ;-)) - although the 
> TLS WG item 
> http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt seem 
> I guess that to be meaningful (at least to me ;-)), these figures 
> would have to specify
> a) which computations are realized only once and which are done at 
> each authentication exchange
> b) which are done by the client and which are done by the server (if 
> you have two PRFs for the finished message, why do you have only one 
> for the key block?)
> and AES. Whether these fine performance discussions are relevant may 
> not be obvious in some cases
> 2) at each authentication 2 MACs, 1 encryption and 1 key derivation 
> for the client and the same computations for the server
>
> 3)  EAP-PSK has been designed to be implemented over any type of 
> devices (including low-cost ones) - figures to come in an upcoming paper.
>
> goals for a pre-shared key EAP method. TLS with PSK, EAP-IKEv2, 
> EAP-PSK, EAP-PAX... all have their pros and cons which should *all* be 
> analyzed.
>
>> As long as I feel, these new contributions will be based on pre 
>> shared key instead of the PKI based-certificate. If this is the case, 
>> I would like to know the objective of the definition of new methods 
>> based on pre shared key outside TLS or IKEv2.
>>
>> Badra
>>
>>
>>

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 16 Aug 2004 20:44:28 +0200

Dear Florent,
Please see in-line some answer to your email (I didn't answer to all 
point, your mail is very long :))

> contrary to IKEv2 that from the start allowed such credentials

When I sent first mail, I thought to make a comparison between TLS-PSK 
and another PSK propositions within the EAP framworks and NOT between 
TLS and IKEv2 in which each one has its business and its use. I profit 
here to say that IMHO TLS is more suitable for EAP than IKEv2.

On the other hand, I am not analysing the TLS security. This is useless 
in our case because all propositions use symetric keys. So IMHO, the 
security of such proposition depends on the safety of these algorithms. 
As a result, it is clear to us that if TLS-PSK is not sufficiently 
secure, that is not mean that the other PSK propositions are outside, 
they share the same problem. TLS at less allows us to negotiate the 
security level via the list of cipher_suites and that if such algorithm 
is broken, I am not forced to rewrite my code, I will just not select 
this algorithm.

> cryptography of TLS (because I am not qualified to do so & :-() but 
> exactly the type of connection of EAP offers 

So why does EAP-TLS exist and why does it become a standard track and 
another like EAP-FAST, PEAP, EAP-TTLS, etc.

As long as I know, EAP is reliable data delivery protocol and was 
designed to enable extensible authentication for network access in 
situations in which the IP protocol is not available, rigth? So I don't 
understand how IKEv2 can borrow from EAP whereas it is not allowed for TLS.

TLS needs reliable link (not necessary TCP) for 2 reasons 
(draft-rescorla-dtls-01.txt):
1. If record N is not received, then record N+1 cannot be decrypted.
2. handshake messages are assumed to be delivered reliably and breaks if 
those messages are lost.

When EAP is used and that an TLS message is encapsulated into EAP trame 
which is lost, it is for EAP to manage that without regard to TLS.

> Yes TLS is being worked on to adapt it to datagram transfer (DTLS, 

Again, I think that TLS was designed to be run over any reliable data 
delivery protocol.

> 2)How much work is needed to prune/adapt these implementations to make 
> an EAP method?

Actually you can TLS-abbreviated handshake for long duration. As I said 
to Charles, if you use for example the OpenSSL API, you can use two 
functions to read/write the formed session from/to the disk/memory in 
order to reuse saved sessions.

By the way, when I will need a protocol, it is easy to implement it. But 
I will not implement a protocol I will not use it. For example, the 
3GGP2-WLAN inter-working need TLS-PSK and will implement is as long as 
they really want to use it.

> 3) How "big" (code size) and "efficient" (CPU+memory consumption) are 

The most weak device in CPU and memory is the smartcard. Let me give you 
an idea about the length of the FULL EAP-TLS code. The total code byte 
size is around 22 KB including about 10KB of data stored in the non 
volatile memory (E2PROM). The majority of this code is for certificate 
parser, verification, and asymetric encryption/decryption.

> messages, fragmentation, lock step protocol, server initiated). 

I think the aim of this topic is to product a comparison between all PSK 
contributions.
TLA-PSK not need fragmentation when TLS-PSK will be used.
I gave the size and the number messages in a past mail.

> EAP-TLS/start message like in RFC 2716 . EAP-PSK uses 2 round-trips.

Rigth.

> you have two PRFs for the finished message, why do you have only one 

When we apply TLS-PSK, the operations are 50% for the client, 50% for 
the server. They are repeated for each session.

TBC
Badra