Bernard Aboba wrote:
If the EAP Server silently drops EAP-Response/GPSK-2, then how would
the client know the PSK is incorrect? Would the conversation just
time out?
Yes.
Perhaps we should add a "MAC Failed" message as Jouni suggested?
Sending it would leave the server state unchanged.
On Sun, Jun 11, 2006 at 08:58:41PM -0700, Lakshminath Dondeti wrote:
> I am not a fan of MAC failed messages, to say the least. Those would
> allow an adversary to start guessing the PSK and have the guesses
> deterministically validated by the server. I would however send a
> generic failure
At 07:29 PM 6/11/2006, Charles Clancy wrote:
Bernard Aboba wrote:
>> Yes, I just listed the first one. If PSK does not match, server will
>> find an incorrect MAC in GPSK-2. What should it do? Just send
>> EAP-Failure?
>
> I would recommend silent discard for packets with MAC failures, since
> th
If the EAP Server silently drops EAP-Response/GPSK-2, then how would the
client know the PSK is incorrect? Would the conversation just time out?
Yes.
Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it
would leave the server state unchanged.
What is the peer supposed
Bernard Aboba wrote:
>> Yes, I just listed the first one. If PSK does not match, server will
>> find an incorrect MAC in GPSK-2. What should it do? Just send
>> EAP-Failure?
>
> I would recommend silent discard for packets with MAC failures, since
> that is most resilient against forgery. Otherwi
Yes, I just listed the first one. If PSK does not match, server will
find an incorrect MAC in GPSK-2. What should it do? Just send EAP-Failure?
I would recommend silent discard for packets with MAC failures, since that
is most resilient against forgery. Otherwise, an attacker only needs to
co
On Sun, Jun 11, 2006 at 11:37:56PM +0200, Hannes Tschofenig wrote:
> >For -00 version, this was in quite good state. I was able to implement a
> >functional server and peer without any major problems and the number of
> >places needing "liberal interpretations" of the text was very small.
>
> Gre
Jouni,
Thanks for your comments. This is quite obviously a -00 document. Many
of the inconsistencies you've pointed out are editorial, and certainly
not intentional. We redesigned large parts of the protocol a couple
times, and unfortunately there are artifacts of previous designs throughou
Hi Jouni,
~snip~
For -00 version, this was in quite good state. I was able to implement a
functional server and peer without any major problems and the number of
places needing "liberal interpretations" of the text was very small.
Great. How long did it take you to get something implemented?
W
On Sun, Jun 11, 2006 at 02:57:02PM -0400, Charles Clancy wrote:
> Thanks for your comments. This is quite obviously a -00 document. Many
> of the inconsistencies you've pointed out are editorial, and certainly
> not intentional. We redesigned large parts of the protocol a couple
> times, and
On Sun, Jun 11, 2006 at 09:30:41PM +0200, Hannes Tschofenig wrote:
> >>>Variable length ID_Server and ID_Client are concatenated in MK and
> >>>KDF_out derivation.
> I am not sure I have seen this type of construction. Maybe I just forgot
> it.
>
> Wouldn't you then have to add a delimiter for e
Hi Jouni,
Jouni Malinen wrote:
On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote:
ID Server/Client in key derivation:
Variable length ID_Server and ID_Client are concatenated in MK and
KDF_out derivation. This means that there is no explicitly specified
boundary between these
On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote:
> >ID Server/Client in key derivation:
> >
> >Variable length ID_Server and ID_Client are concatenated in MK and
> >KDF_out derivation. This means that there is no explicitly specified
> >boundary between these fields
> Do you see
Hi Jouni,
thanks for the detailed comments. Please find my response inline:
Jouni Malinen wrote:
draft-clancy-emu-eap-shared-secret-00.txt
KDFData:
What defines the arbitrary data (KDFData_Client and KDFData_Server)
that is to be included in the KDF? What is this used for? Chapter 7.4
defines
draft-clancy-emu-eap-shared-secret-00.txt
KDFData:
What defines the arbitrary data (KDFData_Client and KDFData_Server)
that is to be included in the KDF? What is this used for? Chapter 7.4
defines a mechanism for server and peer to send "Extra KDF Data" to
allow binding data into the key derivati
15 matches
Mail list logo
