Subject: [HOKEY] comments on erx-03

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 13:09:25 -0700

Hi authors, all,

My first comment is both key derivation and terminology is not aligned
between this and the key-mgm doc, since ERX is to discuss signaling and
protocol, we should collect the key hierarchy especially top level key
hierarchy in Key-mgm.

We should also reconcile terminology differences, for instance rRK is called
HRK elsewhere (including the charter), so I suggest we use HRK instead. 

Other comments to follow (Probably best to submit some on issue tracker
later)

I hope you don't mind the nits coming first, I just provide comments as I go
through the doc.

-It is probably a good idea to add ERP to title:

"EAP re-auth extensions for EAP Re-authentication Protocol (EAP)"

-The term ERP should be included in the terminology.

-Abstract would not need "In most common deployment scenario.. for
per-packet enforcement", Probably better to add that justification to the
intro right before second paragraph in introduction "When a peer moves from
one authenticator."

-first paragraph of intro, last sentence: I would not use "TSK for per
packet access enforcement" using TSK does not determine whether the packets
go through the network or not, this sounds like IPsec ACL, which is not, TSK
is for providing access link security not access enforcement.

-please replace "some methods" with "some EAP methods" in "some methods
specify the use of state from initial authentication.."  In introduction
paragraph 2.

-rMSK, if this is a per-authenticator key, why are we calling it "re-auth"
MSK, which can be mis-interpreted with keys used for re-authentication with
any of the local or home servers. I know AMSK is taken but we should come up
with something that includes authenticator, how about AMK (authenticator
Master key)?

Section 3: Why is MSK distributed and used at the first authenticator. I
think we should have a cleaner solution that uses an EMSK off-spring right
off the bat. As I suggested in my other email, may be MSK can come down with
lifetime=0 to indicate the need for ERX to get an rMSK (AMK). And BTW, I
don't think EAP mandates MSK distribution, so you don't HAVE to send it
anyway..

Section 3: why is rIK derived from rRK (HRK), after an EAP you could
generate an IK from EMSK directly and use it for anything that follows the
first EAP. That would be specially cleaner if the rRK (HRK) is going to be
derived from DSRK for some of your cases!! So you don't have to mess around
with this when you move from one domain to the next, because to me for DSRK
based solution every time you roam to a new domain and want a new DSRK, you
have to go the initial EAP server to get it and thus you would need a key to
interact with the EAP server.

-Section 3: "particularly, when the ER state is duplicated among the
different backend entities." would you elaborate what this means?

-Section 3: "the exchange itself may happen when the peer attaches to a new
authenticator supporting EAP reauthentication, or prior to attachment". Are
you saying the ERP exchange happens prior to attachment to an authenticator?
Are we planning to talk about a pre-auth scenario in this draft? I think
things will complicated very quickly then..

-Is there a description of the rIKname based NAI in the draft now?

-Why is rMSK (AMK) derivation only based on sequence number for the ERP
packet? Are we not using the authenticator-ID as input? I think it is best
to bind the scope of the key to the authenticator. Replay protection alone
is not enough. Even though adding seq. no is good for creating fresh keys..

-"the rMSK is transported in a manner similar to that of the MSK along with
the EAP success in a full EAP exchange"

I think this needs further deliberation or a reference to key-mgm doc as
work in progress.

-section 3.1 

A local server could get a DSUSRK (I called this DSHRK) from the home
server, in cases where a HRK is a USRK and keys for other domains are
generated from that HRK, so this should be reflected in this section as well
as in the pictures showing the exchange (DSRK delivery is one alternative).

-I like the DS-rRK and DS-rIK idea binding the IK and RK to Domains, that is
why I suggested to do IK and CK re-auth independent, so you can support
roaming across domains.

Section 4.1.1

Shouldn't key names be derived from the parent of the key rather than the
key itself?

This is as far as I got:-)

Hope this helps,

Madjid

 

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 18:21:42 -0700

Madjid,

Thanks again.  Please see inline:

> protocol, we should collect the key hierarchy especially top level key 

All I have to say here is that an overall terminology alignment is 
needed.  Let's take that issue separately.

> 
> We should also reconcile terminology differences, for instance rRK is 
> called HRK elsewhere (including the charter), so I suggest we use HRK 
> instead.

The word handover in this context is a misnomer.  Consider that it is 
plausible for a peer to run ERP without a handover being involved.
> I hope you don’t mind the nits coming first, I just provide comments as 
> I go through the doc.
> 

Ok.
> 
> “EAP re-auth extensions for EAP Re-authentication Protocol (EAP)”
> 
Ok.
> 
> -Abstract would not need “In most common deployment scenario…. for 
> per-packet enforcement”, Probably better to add that justification to 
> the intro right before second paragraph in introduction “When a peer 
> moves from one authenticator…”
Ok.
> 
> -first paragraph of intro, last sentence: I would not use “TSK for per 
> packet access enforcement” using TSK does not determine whether the 
> packets go through the network or not, this sounds like IPsec ACL, which 
> is not, TSK is for providing access link security not access enforcement.

As it turns out, you are wrong.  The TSK is in fact used for per packet 
access control enforcement.  Link security is definitely an additional 
property (in some cases an incidental property).

> 
> -please replace “some methods” with “some EAP methods” in “some methods 
> specify the use of state from initial authentication….”  In introduction 
> paragraph 2.

Sure.
> 
>  
> 
> -rMSK, if this is a per-authenticator key, why are we calling it 
> “re-auth” MSK, which can be mis-interpreted with keys used for 
> re-authentication with any of the local or home servers. I know AMSK is 
> taken but we should come up with something that includes authenticator, 
> how about AMK (authenticator Master key)?

Not sure here.  The idea in using MSK as part of the name is to show 
that it is an MSK equivalent key and we used the small letter 'r' to 
differentiate EMSK type of extensions to the abbreviation MSK.  I think 
re-authentication sounds good.  But erMSK, erpMSK, erxMSK might be other 
alternatives.  I don't like AMK because the MSK is also going to an 
authenticator.

> think we should have a cleaner solution that uses an EMSK off-spring 
> right off the bat. As I suggested in my other email, may be MSK can come 
> down with lifetime=0 to indicate the need for ERX to get an rMSK (AMK). 
> And BTW, I don’t think EAP mandates MSK distribution, so you don’t HAVE 
> to send it anyway..

I have responded to this already.  Making things more inefficient is not 
really an option.

> generate an IK from EMSK directly and use it for anything that follows 
> the first EAP. That would be specially cleaner if the rRK (HRK) is going 
> to be derived from DSRK for some of your cases!! So you don’t have to 
> mess around with this when you move from one domain to the next, because 
> to me for DSRK based solution every time you roam to a new domain and 
> want a new DSRK, you have to go the initial EAP server to get it and 
> thus you would need a key to interact with the EAP server.
> 

This is to separate the usage level proof of possession of keys just in 
case there are separate servers to deal with individual usages.  We 
don't want to have different entities holding that same top level IK you 
propose.

>  
> 
> -Section 3: “particularly, when the ER state is duplicated among the 
> different backend entities…” would you elaborate what this means?
> 

In some cases for high availability, AAA server state may be distributed 
to multiple servers and so the ERP message may go to any of the servers.

> 
> -Section 3: “the exchange itself may happen when the peer attaches to a 
> new authenticator supporting EAP reauthentication, or prior to 
> attachment”. Are you saying the ERP exchange happens prior to attachment 
> to an authenticator? Are we planning to talk about a pre-auth scenario 
> in this draft? I think things will complicated very quickly then..

This was added to address the case where the lower layer (e.g., WLANs) 
has a pre-authentication capability.  We can delete that if that makes 
you comfortable.

> -Is there a description of the rIKname based NAI in the draft now?

I think so.  Here is the intent: "rIKname based NAI" has username and 
realm portions.  The realm is either the home domain or the DSRK's 
domain; the username portion is the corresponding rIKname itself.  If 
that is not captured already, we can try and capture that in the next 
revision.

> packet? Are we not using the authenticator-ID as input? I think it is 
> best to bind the scope of the key to the authenticator. Replay 
> protection alone is not enough. Even though adding seq. no is good for 
> creating fresh keys..

Yeah, we thought about this and have been advised that there is no need 
to add the ID as input.  Does key derivation bind the scope or does policy?

> 
> -“the rMSK is transported in a manner similar to that of the MSK along 
> with the EAP success in a full EAP exchange”
> 

Sure.  We can have that discussion.

> generated from that HRK, so this should be reflected in this section as 
> well as in the pictures showing the exchange (DSRK delivery is one 
> alternative).

Hmm, as far as I understand, no.  The domain root, DSRK, is sent to the 
domain and the DSUSRK is derived thereof.

> 
> -I like the DS-rRK and DS-rIK idea binding the IK and RK to Domains, 
> that is why I suggested to do IK and CK re-auth independent, so you can 
> support roaming across domains.
> 

Thanks. Although I am not sure about IK and CK.  But, we can discuss 
these further.

>  
> 
> Section 4.1.1
> 
> Shouldn’t key names be derived from the parent of the key rather than 
> the key itself?
> 

Good point.  Looks like the EMSK document did it that way.  I will think 
some more and propose a way to make it consistent across documents.

> This is as far as I gotJ

Yes.  Thanks.  This exchange is much more helpful.

regards,
Lakshminath
> 
> Madjid 
> 
> ------------------------------------------------------------------------
>

---

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 01:50:57 +0100

Created issues 15 through 23.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc

Lakshminath Dondeti wrote:
>> between this and the key-mgm doc, since ERX is to discuss signaling 
>> and protocol, we should collect the key hierarchy especially top level 
>> key hierarchy in Key-mgm.
> 
>> Other comments to follow (Probably best to submit some on issue 
>> tracker later)
>>
>> I hope you don’t mind the nits coming first, I just provide comments 
>> as I go through the doc.
>>
>> packets go through the network or not, this sounds like IPsec ACL, 
>> which is not, TSK is for providing access link security not access 
>> enforcement.
> 
>> -please replace “some methods” with “some EAP methods” in “some 
>> methods specify the use of state from initial authentication….”  In 
>> introduction paragraph 2.
> 
> Sure.
>>
>>  
>>
>> re-authentication with any of the local or home servers. I know AMSK 
>> is taken but we should come up with something that includes 
>> authenticator, how about AMK (authenticator Master key)?
> 
>> Section 3: Why is MSK distributed and used at the first authenticator. 
>> I think we should have a cleaner solution that uses an EMSK off-spring 
>> right off the bat. As I suggested in my other email, may be MSK can 
>> come down with lifetime=0 to indicate the need for ERX to get an rMSK 
>> (AMK). And BTW, I don’t think EAP mandates MSK distribution, so you 
>> don’t HAVE to send it anyway..
> 
>> the first EAP. That would be specially cleaner if the rRK (HRK) is 
>> going to be derived from DSRK for some of your cases!! So you don’t 
>> have to mess around with this when you move from one domain to the 
>> next, because to me for DSRK based solution every time you roam to a 
>> new domain and want a new DSRK, you have to go the initial EAP server 
>> to get it and thus you would need a key to interact with the EAP server.
>>
> 
>> -Section 3: “the exchange itself may happen when the peer attaches to 
>> a new authenticator supporting EAP reauthentication, or prior to 
>> attachment”. Are you saying the ERP exchange happens prior to 
>> attachment to an authenticator? Are we planning to talk about a 
>> pre-auth scenario in this draft? I think things will complicated very 
>> quickly then..
> 
>> -Why is rMSK (AMK) derivation only based on sequence number for the 
>> ERP packet? Are we not using the authenticator-ID as input? I think it 
>> is best to bind the scope of the key to the authenticator. Replay 
>> I think this needs further deliberation or a reference to key-mgm doc 
>> as work in progress.
> 
>> generated from that HRK, so this should be reflected in this section 
>> as well as in the pictures showing the exchange (DSRK delivery is one 
>> alternative).
> 
>> that is why I suggested to do IK and CK re-auth independent, so you 
>> can support roaming across domains.
>>
>