Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt

From: Giaretta Gerardo <[email-masked]>
Date: Tue, 26 Oct 2004 18:30:57 +0200

> >The allocation of the HA in the foreign network is an open 
> issue in our
> >I-D.
> >We tried to provide a solution in version 00. The basic idea was as
> >follows:
> >- in the EAP exchange the MN asks for a HA in the foreign domain
> >- AAAH gets in touch with AAAF via AAA protocol
> >- AAAF selects a Home Agent and communicates its address to AAAH
> >- AAAH forwards this information to the MN through EAP
> >
> >We decided to remove this description because it is related to the
> >AAA-HA interface and does not affect the communication between MN and
> >AAA (that is the scope of this draft).
> >
> >Do you think there are alternative solutions that affect the MN-AAA
> >interface and should therefore be described in the draft?
> 
> I think this should be dealt with in a separate draft, 
> specifically targeted
> at dynamic assignment of an HA in the foreign network. There 
> is another
> alternative, namely that AAAH tells MN to use DHCP to find 
> the HA locally,
> rather than finding it indirectly via AAA to AAAF. If there's 
> a tight trust
> relationship between the home and foreign service providers, 
> this procedure
> might be faster.
> 

I think that this approach would be very useful if the IPsec SA can be
bootstrapped using certs (i.e. there is a certification path between the
MN and the HA of the foreign domain). In case pre-shared key
authentication is used, who is going to generate the PSK and deliver it
to MN and HA?

> 
> > Section 8.3: I would like a flag here indicating to the MN
> > that it should
> > derive its HoA from IKEv2.
> >
> 
> >This could be an interesting extension.
> >
> >BTW, do you think we need in the MN-AAA interface a mechanism to
> >negotiate the IKE version to be used between MN and HA?
> 
> Hmm, not sure. What does IKE itself provide? If there's 
> adequate support in
> IKE for version handling, then I think it isn't necessary. On 
> the other
> hand, the HA might support both and might want to control 
> which one is used
> by specific kinds of MNs.
> 
> BTW, I believe many IKEv1 implementations also provide 
> address assignment,
> though it is not part of the base specification. So just 
> telling the MN to
> use IKE address assignment probably isn't enough to determine 
> whether IKEv1
> or IKEv2 is used.
> 

This is what I had in mind: does the AAAH need to know if a specific MN
supports IKEv1 or IKEv2 or both?
Consider a scenario where some HAs support only IKEv1 and some others
support IKEv2.  In this situation, in order to allocate an appropriate
HA, the AAAH must know during the MIPv6 bootstrapping negotiation which
version of IKE the MN supports. Do you think this is a meaningful
scenario?

> >If the negotiation fails, there will not be the
> >Authorization-Lifetime-AVP.
> >So it may be better not to combine the two options. What do 
> you think?
> 
> If the negotiation fails, then presumably there will be a 
> Status option
> indicating that, and the lifetime can be set to zero. 
> Combining the two
> avoids the overhead of an additional type and length.
> 

Ok, I get your point. Maybe the termination of the negotiation procedure
can be improved.

A possible change could be:
- leave the Negotiation-Result-TLV as is for the communication from the
MN to the AAAH. This TLV is used by the MN to tell the AAAH whether it
accepts or not the proposed configuration.
- change the format (and maybe also the name) of the
Authorization-Lifetime-TLV in a way that it includes a Status field.
This is used in the communication from the AAAH to the MN.

Regards,

--Gerardo

>             jak

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
====================================================================

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Oct 2004 10:35:07 -0700

jak>>> Agree certs are the most likely candidate, but the AAA-H could push a
preshared key to the AAA-F. This is less secure than using certs w. DH
however, and probably to be discouraged. If it is used at all, the AAA-H
would probably derive a key from the preshared key and push that, and the MN
would probably use the same kind of derivation. The kind of situation I
would expect this to be used is when the network operator has a bunch of
subsidiaries that run their own AAA servers for distributed processing
rather than centralizing everything. I think it would be less useful between
operators, since there's more risk of compromise.

jak>>> Yes, it might occur. But if IKE provides adequate handling of
versions, I don't see that anything would be needed in the EAP exchange. For
the EAP exchange to indicate IKE address assignment if the HA supports
IKEv1, however, the AAA server has to know if the IKEv1 implementation
supports an unstandardized IKEv1 address assignment option.

jak>>> OK, that would work. It was not clear to me from the document that
the Negotiation-Result-TLV also originated at the MN. Is there a need for
the MN to indicate a status? The protocol seems more like the AAA server
pushing stuff to the MN, so it's kind of take it or leave it from the MN's
view, unless I'm missing something.

            jak