Subject: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 20 Jul 2005 21:22:19 -0500

Hi James,
Since we seem to be having the PANA/EAP-HK dependency message exchanges in a separate email, I have not addressed those again here. Some answers to other comments and questions below. 

> 
> As I mentioned, the attraction of this protocol is that it 
> can leverage off the AAA infrastructure for network access 
> authentication. So by not doing that, I think you are 
> undercutting your strongest argument. 

I am not sure if this is the case. The fact that the HMK is derived via EAP eliminates the need for the MN to have any other security associations, except with the AAA server. It has an SA with the AAA server for EAP purposes and we are deriving a master key for handover purposes from the EAP key hierarchy. But, subsequently, since we are deriving HKs only from the HMK, it seemed like a close tie up with network access authentication is not required. 

> >
> > The AAA server does send a recommended lifetime to the AR 
> (and the AR
> forwards that to the MN). However, the AAA server does not 
> maintain any state about the lifetime itself and hence, it is 
> up to the MN and AR to enforce the lifetime. Perhaps, the 
> text can add more clarity on this.
> >
> 
> Yes. But why should the MN trust the AR on the lifetime? 
> There is no authenticated relationship between the AR and MN.
> 

The MN obtains the lifetime from the AAA server itself (this attribute sent to the AR is included in the MAC sent by the AAA server and verified by the MN). So, if the AR modified the lifetime, the MN would realize that. However, ultimately, say if the AR rebooted before the lifetime expired or if the AR itself enforced a smaller lifetime than what the AAA sent it, there is not much the MN can do, except derive a new HK. 

> >
> 
> Yes but I think you need to make it clearer in the draft how 
> retransmissions work.
> 

OK. Will fix this. 

> 
> Again, I think the draft could be clearer on this. It needs 
> to emphasize that preauthentication is primarily an optimization.
> 

OK. 

> >
> > Yes, this is true. This is among the reasons why we didn't consider 
> > any of
> these approaches for the protocol. We may have missed stating 
> that. We included this appendix to essentially explain why 
> some of the other seemingly simple approaches were not so desirable.
> >
> 
> OK. I think this could be dropped from the draft, since it 
> does not contribute to explaining the protocol.
> 

Ok. We wanted it to be part of v00 to give an idea of what alternatives were considered by the authors and why these weren't chosen for the protocol. But, yes, this can be removed in the next revision of the draft. 

Thanks,
Vidya

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

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 21 Jul 2005 19:06:45 +0200

Hi Vidya and James, 

> > >
> > 
> > Why does the MN have to use PANA when it uses 802.11i for 
> > network access? Why can't it just use the EAP method with the 
> > handover key extension during 802.1x?
> > 
> 
> So, in this case, the AAA server will then send the MSK to 
> the AP and the HK to the AR? This is unlike the operation 
> today where the AAA server does not send any keys unsolicited 
> to an entity from which it hasn't received any messages - isn't it?  
> 

I think the scheme James is referring to is very simple if the NAS is
the AR (e.g. PANA is used). In this case you don't need to transfer any
key and the AR receives the HK directly from the AAA server. 

If the NAS is not co-located with the AR (e.g. 802.1X), the NAS may
receive the HK from the AAA server and may send it to the AR. This is
somehow similar to what is done in PAA-EP exchange in PANA where SNMP is
used. Some issues with Housley criteria may arise in this case, though.
Anyway, I think having the AAA server that sends a key unsolicited to
the AR is not a good approach. 

--Gerardo

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 21 Jul 2005 12:50:30 -0500

Hi Gerardo,

> key and the AR receives the HK directly from the AAA server. 

Precisely. I don't see an issue when the AR itself is the NAS. In the scenario I was describing, the NAS is the AP, but the key needs to be sent to the AR. 

> the AR is not a good approach. 

Yes, this is really the problem. Not all the AAA key management criteria will be satisfied when the NAS is different from the entity that needs the key. Also, now this means that the solution will need to be specific to each lower layer encapsulating EAP - if an 802.11 AP or an 802.16 BS needs to send the key to the AR. And, given that typically you would not expect an SA between the AP/BS and the AR, this is a problem. 

Vidya