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

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Jun 2006 18:03:09 -0700

Hi James,
 
> >
> > This is my second review of this document. I reviewed an
> earlier draft
> > of the document. This draft seems to have addressed most of
> the issues
> > I found in the earlier draft.
> >
> > High Level Comment:
> >
> > This protocol strikes me as being somewhat complex.
> 
> The protocol itself is a single roundtrip protocol. The comments you 
> have included below have not particularly indicated what strikes you 
> as complexity (I've addressed your comment on key derivation below). 
> Could you please elaborate on what you mean here and provide any 
> suggestions on what you think could be simplified?
> 
> jak>> I'm concerned that there may be race conditions or other 
> jak>> complexities,
> depending on the exact nature of the AAA protocol. This protocol 
> depends on an AAA protocol for network access authentication. This 
> specification does not tie down what AAA protocol to use. Particularly

> when reauthorization upon handover is required, this may lead to 
> various complexities.
> Implementing it together with 802.1x/802.11i/802.11r would give a 
> confirmation that it worked together with a particular AAA protocol 
> suite that it might be expected to be used with in practice.
> 

I'm not sure why you think there is any dependency on the protocol used
for network access authentication whatsoever here. The protocol is
completely independent of network access authentication. It does need a
AAA server at the backend, which may imply that it would be most suited
for systems that use a AAA server for network access authentication.
However, this protocol has zero dependency on network access - there
could be no network access authentication and the protocol still
applies. So, I'm confused on the above take of yours. 

> Perhaps, we can do a better job with the protocol summary section to 
> exactly summarize the message exchange. Would that clarify things 
> better?
> 
> jak>> That would help
> 

Okay. We will do this. 

> > I did not
> > make a concerted effort to dig out possible security holes, but I 
> > think it could use some deeper study,
> 

<snip>

> >
> 
> I am not sure why you think implementation before standardization may 
> be needed here. Perhaps if we clarfied your complexity comment, this 
> won't be your feeling? In this protocol itself, I don't see what an 
> implementation can buy - the protocol should be fully analyzable on 
> paper. If you feel there are parts of the protocol that aren't 
> allowing this, then those must be clarified. I don't think we need to 
> delay the standardization process for implementation here.
> 
> jak>> Hmm. Used to be IETF's motto was "rough concensus and
> running code". 
> Has it now become "rough concensus and a paper design"? I did not 
> suggest that standardization should be delayed, only that 
> implementation would be a good idea in this case, particularly since 
> this prototcol depends on other protocols, the details of which are 
> not explicitly discussed in this specification.

The protocol depends on an encapsulation in AAA at the backend. Other
than that, there is no dependency to network access or any other
protocol. 

> Implementation turned out to be absolutely critical when we did SEND, 
> otherwise we would not have discovered that IPsec didn't work until 
> after the RFC was published. Nobody could have forseen that the 
> implementation would severely impact the IPsec fast path.
> 

Typically, implementation and protocol analysis serve different purposes
- if we think that the protocol cannot be analyzed, that is a problem.
I'm not saying that implementation is not helpful - but, if we agree
that we don't need to delay standardization on account of
implementation, that would be good. 

> > pg. 17: The key derivation algorithm described here seems to be 
> > somewhat complex. What security benefit is derived from this 
> > complexity? If any, then it should be described in the document.
> >
> 
> In general, the key derivation algorithm used is borrowed from the 
> IKEv2
> prf+ with one very minor change (the change was needed to
> randomize the
> input for the handover integrity key calculation). A prf+ like 
> operation is needed for two reasons - a) multiple keys are derived 
> from the same HMK (an integrity key and a handover key) and two 
> separate un-coordinated PRFs for doing this is not recommended and b) 
> we have built algorithm agility into the protocol, which basically 
> means that depending on the algorithm used for the MAC calculation, 
> the key length could be different. A static PRF fixes the maximum key 
> length and this is undesirable. These are all the reasons why prf+ was

> introduced in
> IKEv2 - it made sense to re-use this rather than re-invent anything 
> here.
> 
> If you think it is needed, we can add some text to clarify this 
> motivation.
> 
> jak>> Yes, I think adding some text would help.
> 

Okay, we will add some text to clarify this. 

> > pg. 23, 6th paragraph: I'm not sure about this. If the NC entry for 
> > the CoA expires and the AR removes the key, then the MN is left 
> > thinking that the key is valid when it isn't.
> > Why not send an NS to the MN to see if it is still around
> and refresh
> > the NC entry?
> >
> 
> Actually, in this protocol, the AR does not remove the key when the NC

> entry for the CoA expires - it only removes the
> *binding* between the key and the CoA. This is because we do allow a 
> new CoA to be tied to the same key, if the MN re-appears on that link 
> prior to the expiry of the lifetime for that key. Since the protocol 
> itself is independent of NDP, this becomes feasible - this ensures 
> that a AAA RT isn't needed when the lifetime of a key is still valid.
> 
> jak>> So what is the key bound to so that the AR can reattach
> it if the
> jak>> MN
> should want to reestablish a binding with another CoA? The MN 
> identity, right? Which is the NAI? This needs to be explained in more 
> detail. At least, it wasn't clear to me how this would work.
> 

Yes, it is bound to the NAI - the NAI is always carried in the HKReq
message and hence, the CoA can be bound when the subsequent HKReq is
sent. We will clarify this better. 

Thanks,
Vidya

>             jak

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Jun 2006 08:33:48 -0700

> delay the standardization process for implementation here.

jak>> So you are claiming that the protocol can operate with no AAA network 
access protocol at all, like in a hotspot situation? If so, I'd like to see 
that claiim written up and put into the document.

jak>> I'm recommending that someone do an implementation. That's all. I'd 
like to have some confidence that the protocol actually works, and the only 
way I know to do that is to actually have an implementation that works. How 
that impacts the standardization effort is up to the WG chairs and their 
management of the process. As I said in the original post, there is no 
requirement that the WG show an implementation to the IESG for 
implementation of IETF protocols except for routing protocols, though the 
release form that the WG chairs fill out and send to the IESG prior to 
submitting the draft does have a question about implementation.

jak>> OK. You might consider phrasing it as a "conceptual data structure".

            jak