AW: [Emu] EAP-GPSK: Ciphersuites

Hi Lakshminath, I am not sure that the group wants to use CCM. (If you are referring to this part of your mail.) Ciao Hannes > -Ursprüngliche Nachricht- > Von: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 22. August 2006 11:44 > An: Hannes Tschofenig > Cc: emu@i

AW: [Emu] Tying EAP-TLS method type to specific ciphersuites

Hi Charles, > -Ursprüngliche Nachricht- > Von: Charles Clancy [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 26. Oktober 2006 18:45 > An: Bernard Aboba > Cc: emu@ietf.org > Betreff: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites > > So, it sounds like defining an EAP t

[Emu] NIST KDF & EAP-GPSK

Hi all, at the EMU working group meeting we received some feedback regarding the usage of the NIST KDF in EAP-GPSK. In order to make progress with the document we would like to get some more information about the suggested change to the document. Some NIST documents have been mentioned. Could s

AW: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods

cht- > Von: ext Sam Hartman [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 3. April 2007 17:40 > An: Tschofenig, Hannes > Cc: Hannes Tschofenig; [EMAIL PROTECTED]; emu@ietf.org > Betreff: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods > > >>>>&

AW: [Emu] Re: Next Steps on Passwd-based EAP Methods

Hi Sam, > > "Hannes" == Hannes Tschofenig > <[EMAIL PROTECTED]> writes: > > Hannes> Hi all, before we spend more time considering EAP > Hannes> tunneling methods like PEAP and TTLS I would like to hear > Hannes> the opinion of our ADs on this subject. So far, the > Hannes>

AW: [Emu] Crypto-binding in TTLS-v0

Crypto-binding: Yes (my opinion) Sam also suggested to add channel bindings and to address internalization support in a proper way. Regarding your other question: No. EAP-TTLS is not a charter item since the work on password-based protocols currently does not include tunneled EAP protocols. T

Re: [Emu] EMU Charter revision

Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP & co track. Is it because you expect performance improvement

Re: [Emu] Liaison Statement on ITU-T Recommendation X.1034

Here are a few random review comments. Section 3.2: Terminology The definition of PFS does not correspond to the crypto literature. Here is the definition from the Handbook of applied cryptography: " 12.16 Definition A protocol is said to have perfect forward secrecy if compromise of long-term k

[Emu] Comments for draft-clancy-emu-chbind-02.txt

* When I have to introduce this work to our AAA server folks then they will obviously ask me the following question: What is the benefit and what does it cost? As you mentioned in the operational considerations section there is cost associated with updating the EAP methods, putting new information

Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09

Yogendra, do you plan to contribute text? Ciao Hannes From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext yogendra pal Sent: 11 November, 2008 08:12 To: [EMAIL PROTECTED] Cc: emu@ietf.org Subject: [Em

Re: [Emu] Comments from Hannes on draft-clancy-emu-aaapay-01.txt

Hi Joe, The idea of defining one payload format for carrying information in EAP methods sounds useful. Then, someone only has to define something once and it is available (at least from a specification point of view) in all EAP methods. In practice, this obviously requires code changes and the

Re: [Emu] Impersonation and Lying NAS problem: two distinctissues (with different solutions)

There are 3 parties in the AAA/EAP exchange. Not every party is authenticated in the exchange (e.g. the NAS/AAA client is not authenticated by the EAP peer) -- there is only key confirmation taking place. The NAS can therefore report different identities to the EAP client and to the AAA server.

Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network"

Hi Bernard, here is my guess of the background of all this work. Imagine a company has worked on strong password based authentication and key exchange protocols. That company might also believe that they have some IPRs in this field. Now, some folks in that company would like to get their

Re: [Emu] Draft response for ITU-T X.1034 liaison statement

Very nice writeup, Joe. You might want to point out to them that they can develop EAP methods and publish them as informational documents without any special reaon or new set of requirements even if other EAP methods already provide similar functionality. >-Original Message- >From: emu-

Re: [Emu] draft-cakulev-emu-eap-ibake

Hi Violeta, What problem are you trying to solve with this EAP method? Ciao Hannes > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > ext Cakulev, Violeta (Violeta) > Sent: Wednesday, January 11, 2012 10:16 PM > To: emu@ietf.org > Subject: [E

Re: [Emu] draft-cakulev-emu-eap-ibake

2012 5:17 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake > > Hannes, > Thanks for the interest. > > IBAKE was proposed and adopted as a method for device bootstrapping in > ETSI M2M. > IBAKE is especially sui

Re: [Emu] IETF 83 agenda request: channel binding implementation

I am looking forward to the discussion. I care about implementation specific aspects, particularly if they hide some underlying problems. > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > ext Sam Hartman > Sent: Monday, February 06, 2012 5:33

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

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,

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

Hi Alan, > 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

[Emu] Open Issues with EAP-GPSK

Hi all, Paul Rowe, Arnab Roy, Prof. Andre Scedrov and Prof. John C. Mitchell did an analysis of EAP-GPSK and they essentially found three issues: 1) Use of encryption algorithms before choice is confirmed This aspect can be covered in the security consideration section of the upcoming draft v

[Emu] EAP-GPSK and Client-Side DoS Attacks

Hi all, What is the issue? The first message from the server to the peer is not authenticated. This may allow some kind of denial of service attack against the peer. The peer should be ready to accept new sessions from the same server, so the peer must store one server nonce and one peer nonce fo

[Emu] EAP-GPSK & Key Derivation Function

Hi all, What is the issue? The derivation of MK uses "0x00" as a key for the KDF. Here is the key derivation step: MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) ^ Here is the problem. Here is what Charles recognized during the discussion: " I

AW: [Emu] EAP-GPSK & Key Derivation Function

That's also a reasonable suggestion. I like this one. Ciao Hannes > -Ursprüngliche Nachricht- > Von: ext Charles Clancy [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 20. September 2007 13:11 > An: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) > Cc: emu@ie