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
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
* 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
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
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
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.
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
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-
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
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
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
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,
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
13 matches
Mail list logo
