Subject: [Emu] 答复: Re: draft-cakulev-emu-eap-ibake

From: [email-masked]
Date: Tue, 10 Apr 2012 17:07:06 +0800

Hi，Hannes，

> > 
> I personally believe that you will not get the necessary support 
> from the EMU working group to get the charter changed and the group 
> interested in IBE. 
> I can tell you that I will not spend my time on it. 
> 
> My reasons are being less excited are: 
> * Identity based crypto as a technology does not really solve a 
> problem. (In case you are going to ask: "yes" I looked it some time 
> ago when I tried to figure out what value it provides for some IETF 
> protocols. And guess what - I couldn't find any benefits.)
> * "ETSI wants it" is not a good reason for me todo anything.
> * I have so many other great documents to review. 
> * The IPR situation with identity based crypto makes me feel uneasy. 
> 
May I  ask for the reason why you think you could not find any benefits in 
identity based cryptography?
Only beacause it has IPR problems?
To be object,  identity based cryptography is a great idea, you don't have 
to transfer long public key,
and checking status of public keys frequently.

Regards~~~

-Sujing

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Apr 2012 13:42:44 +0300

Hi Zhou, 

The first step is to figure out what the actual problem is. 

Ask yourself: Is there indeed a problem with transferring the “long” public keys (of the client, as you state below)? 

For the cases where I have seen EAP used so far I have not heard about these problems. I have, however, heard about problems with the many roundtrips of EAP methods and the usage of RADIUS. This was partially the motivation for the work on RADIUS over TCP (and TLS).

There is, however, work ongoing to make use of EAP in environments with different radio interfaces (like IEEE 802.15.4 and alike) and, as you know, there you can find additional challenges. However, for those cases folks had been looking into different solutions that are more likely to find deployment (assuming that EAP is a suitable technology for whatever use cases people have in mind there). Today, as you may know the deployments are actually quite simplicity from a security point of view.  

Just to remind you about the last smart object security workshop various folks had been looking into the usage of TLS-PSK and high-quality pre-shared secret cipher suites are available as EAP methods as well. (I had once worked with Thomas Otto on a EAP-TLS-PSK method, see http://tools.ietf.org/html/draft-otto-emu-eap-tls-psk-02).  

Regarding the revocation issue: If the client’s credentials get revoked then he must not be able to successfully authenticate to the AAA server anymore. Done. I don’t see how this can get any easier regardless of the authentication protocol.

Ciao

Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, April 10, 2012 12:07 PM
To: Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: [Emu] 答复: Re: draft-cakulev-emu-eap-ibake

Hi，Hannes， 

> * The IPR situation with identity based crypto makes me feel uneasy. 
May I  ask for the reason why you think you could not find any benefits in identity based cryptography? 
Only beacause it has IPR problems? 
To be object,  identity based cryptography is a great idea, you don't have to transfer long public key, 
and checking status of public keys frequently. 

Regards~~~

-Sujing

---

From: Alan DeKok <[email-masked]>
Date: Tue, 10 Apr 2012 13:19:00 +0200

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Ask yourself: Is there indeed a problem with transferring the “long”
> public keys (of the client, as you state below)?

  I've seen this be a problem when the long keys require too many round
trips.  ~20K of data, or ~20 round trips is about the limit.

  One way to optimize this is to *not* send the certificates on every
authentication.  All implementations I've seen currently exchange all of
the certs, including any CA chain.  But I'm not sure that this is required.

  Sending only client/server cert would minimize the number of round trips.

  Alan DeKok.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Apr 2012 15:45:33 +0300

Hi Alan, 

> trips.  ~20K of data, or ~20 round trips is about the limit.

For TLS client authentication I am wondering why a certificate chain needs to be transmitted to the server. 

> authentication.

Correct. One could use the cached info extension if the size is a concern but I don't think it actually is. 

> All implementations I've seen currently exchange all
> of

This seems to be the result of misconfiguration. 

>   Sending only client/server cert would minimize the number of round

That's what should be done.

Ciao
Hannes

---

From: [email-masked]
Date: Wed, 11 Apr 2012 08:45:08 +0800

Hi，Hannes

> 
> Regarding the revocation issue: If the client’s credentials get 
> revoked then he must not be able to successfully authenticate to the
> AAA server anymore. Done. I don’t see how this can get any easier 
> regardless of the authentication protocol.

on revocation issue, 
  Traditional PKI based public key cryptography  and cert: a client login 
with a revoked cert, server check status of the cert by ocsp protocol each 
time.
  Identity based public key cryptography: a client login with a expired 
identity||date,  server can check status of the client's credential 
locally.