Subject: RE: [mobile-ip] BU Authorization method: design team recommendation

From: [email-masked]
Date: Mon, 11 Feb 2002 14:06:18 -0600

Hi Erik,

Thanks for your comments,

Please find some below:

> > I am not sure if you have taken a look at the following draft.
> > 
> > http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt
> > 
> > It uses RR+DH to create MN-CN security association. This draft 
> > also gives an example where DH method can take advantage of 
> > AAA (wherever available) to eliminate MiTM attacks that DH is
> > prone to.
> >
> 
> Yes, but I think this draft departs from the tradional model of AAA
> in that it makes the AAA infrstructure a "pass through" as examplified
> by the AAA sending out packets to the CN:

Yes that is correct

>     *  Then CN's AAAh:
> 
>       -  forwards DH(CN), MAC(Ki) to CN
> 
>       -  verfies MAC(K1) and if valid, computes DH(MN), MAC(Kj)
> 
> The AAA was architected around the AAA being a service that 
> could perform
> authentication of clients on a global scale and pass back 
> configuration 
> information that carries no semantics in the AAA itself. 
> What draft-le-mobileip-dh is proposing is to make the AAA aware of the
> semantics of these extensions which means that the AAA code 
> needs to be
> modified on the servers. I'm not convinced this is the right path.

I do not see the issue: there will be a new application for this service and the AAA servers will process the messages in the same way they have been specified to behave in the Diameter Mobile IPv4 application and in the AAA Registration keys drafts.

> It might be better to just make the AAA servers an explicit PKI with 
> cross-certificates etc.

AAA server acting as a PKI is another possibility but in such case, the AAA servers need more functionnalities: they do not only need to act as Certicate Authority but msut also maintain all other PKI services such as Key Revocation, Key history, etc. which is heavier.

The method described in the http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt draft, when used with the AAA infrastrucure allows an authenticated key distribution mechanism without the need of signatures which are usually considered heavy from a computational point of view.

> Also, it wasn't clear from the draft how the AAA does the 
> authorization
> of an address.
> Imagine I (NAI=[email-masked]) appear at some random ISP
> and get authenticated.
> The ISP assigned me a CoA (e.g. using RC 2462 stateless addrconf)
> and I communicate with the AAA.
> Is the assumption that my AAAh has a pre-configured list 
> mapping NAI->home 
> address for all nodes in sun.com?
> What if my home network renumbers (mipv6 allows for this) - 
> how does this
> mapping get updated?
> What if my MN wants to use a RFC 3041 home address - how does 
> the mapping
> in my home AAA get updated?

I don't get the point. How is it relevant ?
But to answer your question, a pre-configured list mapping NAI->home address for all nodes in sun.com could be maintained; or dynamic home agent assignement could be performed.
 
> 
> > PS: I agree with you that there is currently no concrete 
> > proposal for the "other" BU Authorization mechanisms that I
> > am talking about. But by adopting this "1 bit method" (or 
> > 2 bits as described in your mail), I fear there might be no
> > room for selecting these mechanisms later on. 
> 
> I just think that they need to be selected using other means, 
> but since I
> clueless enough to not understand the big picture for 
> infracstrcuture-based
> BU authorization I can't speculate on how.
> 
> 
> But a larger question which nobody has asked is whether the 
> better CGA defense
> against future attacks and less frequent HoA RR checks warrant the
> additional complexity of CGA.
> 
>   Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 23:26:15 +0100 (CET)

Frank,

> I do not see the issue: there will be a new application for this service and
> the AAA servers will process the messages in the same way they have been
> specified to behave in the Diameter Mobile IPv4 application and in the AAA
> Registration keys drafts.

Yes, and several people have expressed concern that we didn't look carefully
at the implications when RFC 2799 was approved - that seems to have been
the point when we for better or worse chose to make the AAA servers into
application layer routers of any message that needs security.

So just becuase the Diameter moble IPv4 stuff takes this approach doesn't
mean that it is the best approach. Could be quite the opposite IMHO.

> AAA server acting as a PKI is another possibility but in such case, the AAA
> servers need more functionnalities: they do not only need to act as
> Certicate Authority but msut also maintain all other PKI services such as
> Key Revocation, Key history, etc. which is heavier.

I don't think the PIC servers do this - they just hand out very short lived
certificates as one of the options. See draft-ietf-ipsra-pic

> But to answer your question, a pre-configured list mapping NAI->home address
> for all nodes in sun.com could be maintained; or dynamic home agent
> assignement could be performed.

My point wasn't about the home agents addresses changing - it was about how
to handle the updates to the home addresses changing e.g. due to
a site renumbering or due to the MNs using RFC 3041 and picking a new 
home address occasionally.

   Erik