Hi Joe,
Sorry for the delayed response. I was without a functional laptop for
the better part of the last 30 or so hours and so I am behind on a few
things here.
Please see inline:
On 2/6/2008 10:00 PM, Joseph Salowey (jsalowey) wrote:
Thanks for your quick response, comments inline:
-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com]
Sent: Wednesday, February 06, 2008 1:03 AM
To: Joseph Salowey (jsalowey)
Cc: hokey(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
Extensions for EAP Re-authentication Protocol (ERP)) to
Proposed Standard
Thanks for the review Joe.
On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote:
In reading this draft (-09 version) I came up with a few
questions and
comments:
Section 3 -
Section 3 is a bit confusing it seems that much of the text
is section
3.1 (detailed description of exchanges) should go into section 3.0
because it seems that much of the process should be the
same for local
or remote cases. Currently it is difficult to really tell what
pertains to local, remote and both.
It does not appear to be clear how the peer knows if it is
in the "home"
case or the "local" case, whether the network is capable of
ERX (and
vice versa) or how the peer knows what key to use. Perhaps
I missed
this elsewhere in the document.
We worked to clarify this in the last revision. I will make
another pass at it while preparing v10 and run it by you
(probably sometime tomorrow).
Section 4 -
Section 4.1.1 duplicates text in
internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really
should not. It should reference KDF functions instead of PRFs. I
believe if you replace prf+ with KDF it would be fine. Do
you want to
use the naming defined in
internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you
specifying your own? Are these key names really necessary?
They do
no appear to be used anywhere?
This is true. I think we were trying overly hard to name
everything (one of 4962 things?) and I realized earlier that
we have a procedure to even name the rMSKs. But, it is not
clear whether the rMSK names will be used anywhere.
I just sent that email about naming and so we should be able
to clean this stuff up now if that is acceptable to everyone.
[Joe] If this is what we discussed I believe it will help, I will take a
look at that.
Yes, and I am going to poll some folks to make sure that is ok with them
too. Please review; if you want I can provide details (might ask Dan
for some help) for your review.
On duplication, it seems we have two strong opinions here.
You are suggesting less duplication and Alan is suggesting
more :). I guess we may have actually achieved the (un)happy medium!
My opinion is that we should have less duplication, perhaps
to the extent you are suggesting, so the idea is to not have
to update (when we
need) text in two different drafts. That said, there are
some usage specific properties to consider, specifically we
are trying to specify crypto-agility in case of ERP and for
those reasons, the derivations may need to be spelled out again.
[Joe] I think if we need to spell out the derivations in this document
there is a problem. This would indicate there is something wrong with
the EMSK document that needs to be fixed.
Yeah, I tend to agree. I am talking to Alan soon and after that propose
a direction here.
In the next revision, I'll see what I can do to reduce the
duplication (but before that I will talk to Alan to see what
he wants).
Why such a long key label?
Which one?
"EAP Re-authentication Root Key(_at_)ietf(_dot_)org"? I guess we could
call it "EAP rRK" but that might be an abbreviation for
something else in the future. Please suggest another name
:), but hopefully one that does not involve changing the
entire document (I don't want to introduce errors with too
many global changes).
[Joe] I suppose it doesn't matter much, it just seems that name is
unnecessarily long. The point of registering the labels with IANA is to
avoid conflicts.
Section 5 -
Section 5.1
What state are you referencing here? I don't think the
CalledStation-ID is what you want to reference, I believe RADIUS
routing is typically done with the username when EAP is
used. Why is
it only RECOMMENDED to maintain this state? It seems
either it is a MUST or it doesn't matter.
In general authenticators do not do routing, AAA does routing.
Authenticators copy the correct attributes from EAP into
the correct
attributes in the AAA message. This seems much more complicated
(routing, multiple attributes TLVs etc). Its not clear if the 3
sub-bullets of the first bullet refer to what the
authenticator needs to
do or the peer needs to do. It seems that the
authenticator should be
able to extract a single field from the peer message to
determine what
to do with it. Either it will handle it locally or it will
pass the
message within the AAA protocol copying the appropriate
field into the
message.
I see. I will make it clear and separate as to what the peer
must and what the authenticator must do. I think we have
done that in the sections after that, but I can see the ambiguity.
On the AAA stuff and the reference to state, could you please
suggest text? Thanks. We should say the AAA client in the
ER authenticator to be more precise. I was going to talk to
Alan about the AAA stuff later this week, but in the
meanwhile, please suggest text in this case and that'll help
clean up that text. Thanks.
[Joe] I think the draft prescribes a bit too much about the back end AAA
operation. AAA routing etc should work pretty much as it does to day if
this is going to be at all deployable. I'll try to put some more
specific text together.
Thanks. In fact, with the simplification you proposed -- use
keyname/rIKname-NAI as the only attribute -- we can probably get rid of
the references to the stored state etc.
Is the integrity checksum a keyed hash or MAC (if so why
use another
term?)?
Integrity checksum is the most generic term (I would think
that keyed hash would not be sufficiently generic; I guess
MAC might work, but people have had problems with that word,
especially folks with L2 background). I do see that there
are references to authentication tags and integrity
checksums. There is no need for multiple terms (or at least
we should say they mean the same thing).
If so what key is used? If a key is used in the context in
the packet
enough to determine the key? Is it possible that more that
one EMSK
has been generated by the same peer?
The key is rIK and there is an rIKname to refer to it. With
the new proposal, the rIKname or keyname, it should be called
now, will be the emskname and in the context of ERP we use
either the DS-rIK or an rIK in the integrity checksum
calculation; whether it is the rIK or the DS-rIK is
determined by the NAI used. If that is ambiguous, we need to
work on fixing the ambiguity :). Please let me know.
[Joe] I found it confusing in this section, it was not clear that if the
domain is not communicated in the lower layer how the peer decided to
use which key to use. I think it is that if they are using their home
NAI then they use the rIK. I'm not sure this is spelled out in the
document.
Ok, will check and clarify as necessary in the next revision.
Why must the authenticator rely upon the information cached
from the EAP
exchange, isn't there enough information in ERX messages?
Good question. I will try and dig up information on why this
is necessary.
The whole
routing section is complex and is not something that authenticators
generally do now. Why do you need an alternate to
R1KName-NAI? Why
is the peer name necessary? Why isn't a R1KName an NAI? Should the
R1Kname sent by the server match the one sent by the client?
There are some options here. In fact, we used to have the
option of server-ID and we got rid of that to remove some of
the complexity (that was introduced at some point because
someone suggested it, but later no one in the WG cared for it).
So, now there are three combinations really.
The first is rIKname, Peer ID and
the second is rIKname-NAI
we also support rIKname alone, but that works only if
authenticator have a default ER server to send all ER messages to.
[Joe] Isn't the r1Kname alone a valid NAI?
We differentiate between rIKname and rIKname-NAI, but if I understand
your point, you are suggesting using rIKname-NAI and that's that. That
kind of simplification is being suggested by a few folks and so that is
what we'll do.
Perhaps there is scope for simplification here. Please see below ...
Section 5.1.1
It seems there is another option other than obtaining a
DSRK from the
home domain, you may retrieve the rRK derived from the DSRK. There
are also key distribuiton attributes for RADIUS defined in
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt
and
http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-08.txt.
Is there a reason why we need to diverge?
No reason to diverge. In fact, we do intend to use keywrap.
Charles has some ideas about how to bring that all together.
I am waiting to hear from him. I have spoken to Glen before
and he gave some pointers too. I am going to talk to Alan as
well and get his thoughts from his DTLS draft perspective.
The idea is to specify attributes for requesting the DSRK and
an attribute to send the DSRK, the keyname and lifetime.
Either keywrap or dtls can be used protect such request and response.
[Joe] Neither of these are referenced in the draft instead the draft
references another set of documents. It would be good to use a
consistent set of attributes to carry keys.
It is a chain of references. I have spoken to Glen about this a few
times and the intent is definitely to reuse the work already in progress :).
I will writeup a brief note on the attributes and propose changes to the
WG and ask if there are objections for the simplification.
regards,
Lakshminath
Section 5.2
Ditto of most of the concerns in 5.1/5.1.1. Do we need two sections?
5.1 is bootstrapping and 5.2 is the protocol run. Two
sections are better to clarify the distinction. I will look
for any obvious duplication and try to get rid of it. But
here again we get into duplication vs. too little detail
(perhaps we can get rid of the duplication here since it's
all in one document).
Section 5.3
It would be helpful if the 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, there may be scope for further
simplification here. To the extent I care, I am happier with
fewer options (I guess I have said it many times already that
I want this simple, and efficient).
If we adopt 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 to by
"keyname" all bets are off anyway.
I will think some more to make sure. In the meanwhile, other
folks can try and see if we are simplifying too much (i.e.,
losing functionality).
We were thinking of privacy considerations at some point and
noted that the server could send encrypted rIKnames in the
EAP-Finish/Re-auth messages. If there is loss of
synchronization, then the peer ID 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.
regards,
Lakshminath
-----Original Message-----
From: The IESG [mailto:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Thursday, January 24, 2008 8:13 AM
To: IETF-Announce
Cc: hokey(_at_)ietf(_dot_)org
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 Extensions for EAP Re-authentication Protocol (ERP) '
<draft-ietf-hokey-erx-08.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
and solicits
final comments on this action. Please send substantive comments to
the ietf(_at_)ietf(_dot_)org mailing lists by 2008-02-07.
Exceptionally, comments
may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain
the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-08.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa
g=
15997&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf