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.
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.
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).
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.
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.
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.
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.
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&dTag=
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