Reviewing the document, it looks very good overall. I have a few
comments and questions about Sections 1 through 4. The later sections
will be reviewed in a separate message.
Section 2:
Defines a number of terms, but not AAA server, which is first
referenced in Section 3.1. Similarly for A
A number of reviews of this document have been posted to the HOKEY and
RADEXT WGs that raise issues that may be relevant to an IETF last call.
Links are provided below:
Stefan Winter:
http://www1.ietf.org/mail-archive/web/hokey/current/msg00987.html
Barney Wolff:
http://www1.ietf.org/mail-arc
A couple of comments to be considered as part of the last call comments:
1. Some folks from 3GPP2 (Parag Agashe, Dinesh Dharmaraju and others)
reviewed the document and pointed out that IANA stuff needs to be
cleaned up further. Charles Clancy pointed out this earlier and we
thought we caught
Hello,
I believe this is a well organized and complete document. On
numerous occasions while reviewing it I made a mental question
regarding something only to have the question answered in a
subsequent paragraph.
I do have several comments though:
1. this protocol can be used in the pres
24, 2008 8:13 AM
To: IETF-Announce
Cc: [EMAIL PROTECTED]
Subject: Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP
Re-authentication Protocol (ERP)) to Proposed Standard
The IESG has received a request from the Handover Keying WG (hokey) to
consider the following document:
- 'EAP
Here is my review:
http://www.drizzle.com/~aboba/EAP/erx-review.txt
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf
Alan,
Thanks much for your comments. Please see inline:
On 1/29/2008 8:32 AM, Alan DeKok wrote:
Reviewing the document, it looks very good overall. I have a few
comments and questions about Sections 1 through 4. The later sections
will be reviewed in a separate message.
Section 2:
Defi
On Wed, Jan 30, 2008 at 10:53:25PM -0800, Lakshminath Dondeti wrote:
>>
>>... hence the
>>authenticator initiation of the ERP exchange may require the
>>authenticator to send both the EAP-Request/Identity and EAP-Initiate/
>>Re-auth-Start messages.
>
> Yes.
>>
>> Have existing EAP
Lakshminath Dondeti wrote:
>> Have existing EAP peer implementations been validated to work under
>> these assumptions? i.e. will they break? Will they see "unexpected"
>> EAP messages or content, and reject or discard the response?
>
> Kedar noted from his implementation experience and it wor
On 1/31/2008 6:23 AM, Yoshihiro Ohba wrote:
On Wed, Jan 30, 2008 at 10:53:25PM -0800, Lakshminath Dondeti wrote:
... hence the
authenticator initiation of the ERP exchange may require the
authenticator to send both the EAP-Request/Identity and EAP-Initiate/
Re-auth-Start messages.
Y
On 1/31/2008 7:01 AM, Alan DeKok wrote:
Lakshminath Dondeti wrote:
Have existing EAP peer implementations been validated to work under
these assumptions? i.e. will they break? Will they see "unexpected"
EAP messages or content, and reject or discard the response?
Kedar noted from his implem
Lakshminath,
I remember ERP state machine is discussed in
http://www1.ietf.org/mail-archive/web/hokey/current/msg00713.html, but
lock-step issue was not discussed in the thread. Please point out a
particular HOKEY thread or meeting minutes where lock-step issue was
discussed.
(I was paying atten
Hello again,
Pardon my repetition but I have come up with a very valid
reason why naming keys using HMAC-SHA-256 is a bad idea.
If one wants to administratively remove all keys in a particular
key hierarchy (which seems like an entirely reasonable request)
one must do a linear search of al
Hi Dan,
Many thanks for your review. Please see inline for some notes.
On 2/1/2008 5:16 PM, Dan Harkins wrote:
> Hello,
>
> I believe this is a well organized and complete document. On
> numerous occasions while reviewing it I made a mental question
> regarding something only to have the qu
On 2/3/2008 12:28 AM, Glen Zorn wrote:
> Dan Harkins <> scribbled on Saturday, February 02, 2008 8:46 AM:
>
>> Hello again,
>>
>> Pardon my repetition but I have come up with a very valid reason
>> why naming keys using HMAC-SHA-256 is a bad idea.
>>
>> If one wants to administratively re
Hi Glen,
On Sun, February 3, 2008 12:28 am, Glen Zorn wrote:
> Dan Harkins <> scribbled on Saturday, February 02, 2008 8:46 AM:
>
>> Hello again,
>>
>> Pardon my repetition but I have come up with a very valid reason
>> why naming keys using HMAC-SHA-256 is a bad idea.
>>
>> If one wants
Dan Harkins wrote:
> Yea, mapping by Username might be better. Oone reason is that you
> could develop a rational searching strategy to identify keys if you
> indexed with something like "Username". That is a great suggestion and
> a useful alternative to what is in the draft now. I would support
Dan Harkins <> scribbled on Saturday, February 02, 2008 8:46 AM:
> Hello again,
>
> Pardon my repetition but I have come up with a very valid reason
> why naming keys using HMAC-SHA-256 is a bad idea.
>
> If one wants to administratively remove all keys in a particular
> key hierarchy (wh
Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 1:30 PM:
...
> There was also the issue of not being able to export EAP session IDs
> (IIRC) that I referred to in my other message.
Hmmm. draft-ietf-eap-keying-22.txt says
EAP methods supporting key derivation and mutual authen
Hi all,
Some of the reviews I have seen start with good things to say about the
document pointing about a few things that need to be fixed. Yoshi
pointed out one issue that he apparently missed during the WGLC. We
have been going back and forth on these topics and not really making
progress.
Hi Glen,
On Mon, February 4, 2008 1:09 am, Glen Zorn wrote:
[snip]
> Doesn't sound particularly readable to me; in any case, I don't think
> that it really matters (for the purposes you describe, however unlikely
> they may be) what the key name looks like. What matters is how easy it
> is to
OTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Dan Harkins
>> Sent: Friday, February 01, 2008 5:46 PM
>> To: Dan Harkins
>> Cc: ietf@ietf.org; [EMAIL PROTECTED]
>> Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
>> Extensions for EAP Re-authen
n Harkins
> Cc: ietf@ietf.org; [EMAIL PROTECTED]
> Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
> Extensions for EAP Re-authentication Protocol (ERP)) to
> Proposed Standard
>
>
> Hello again,
>
> Pardon my repetition but I have come up with a very val
gt; in protocols, most likely you will end up hashing it anyway.
> >
> > Joe
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf
> >> Of Dan Harkins
> >> Sent: Friday, February 01, 2008 5:4
can be
used to resync. That is one case where the peer ID would be useful. A
few meetings ago, the WG didn't care about privacy considerations. I
guess we can drop the peer ID now. Like I said, I will think some more,
and see if there are any other corner cases.
Thanks again Joe.
r
dopt the root key name scheme we discussed a little
> while ago, perhaps the peer-ID is not necessary. Either the
> ER server pointed to by the NAI in the keyname-NAI (instead
> of rIKname-NAI) can identify the keyname or not. If it does
> not have keys corresponding to the key referred
identity field (R1Kname-NAI) was in a
>>> deterministic place within the packet so the authenticator has less
>>> work to do to extract it. I don't see why peer name is useful (or
>>> R1Kname-TLV).
>>>
>>>
>> Yeah, as I noted earlier,
...
> Can you tell me one use for a key name that is an incomprehensible
> string of random bits?
>
> "Delete all keys associated with 0x58d610a8ff4128c9"
>
> "uhm, ok"
>
> If not then don't you agree the current key naming scheme is
> completely useless?
I don't think that it's really
On 2/3/2008 1:23 AM, Glen Zorn wrote:
> Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 1:30 PM:
>
> ...
>
>> There was also the issue of not being able to export EAP session IDs
>> (IIRC) that I referred to in my other message.
>
> Hmmm. draft-ietf-eap-keying-22.txt says
>
>
29 matches
Mail list logo
