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

From: Giaretta Gerardo <[email-masked]>
Date: Tue, 02 Nov 2004 09:09:30 +0100

Hi James,

see below...

> 
> 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?
> 
> 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.
>

I agree it would be less useful in a scenario between operators.

However, I don't clearly understand the scenario you described: do the
subsidiaries' AAA servers authenticate the users or simply act as AAA
proxies? In the former case, how can they authenticate them? Do they
have a copy of users' credentials? Are the users' credentials
distributed by the central AAA server to all subsidiaries' AAA servers? 

> >
> > > 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?
> 
> 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.
> 

I agree: a negotiation about dyamic address assignment is needed even if
IKEv1 is used.
Moreover, I wonder whether the MN must declare its capabilities (i.e.
which version of IKE it supports): what happens if the MN supports only
IKEv1 and the HA only IKEv2? Or do you think this scenario is not
feasible since the HA is expected to support both IKEv1 and IKEv2?

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

In the EAP negotiation phase the MN can ask for particular service
options, for example the allocation of the HA in the foreign domain. If
the AAAH cannot provide some options requested by the MN, it must be
possibile for the MN to reject the MIPv6 parameters proposed by the AAAH
(i.e. it is not interested in a HA in the home domain but only in a HA
in the foreign domain) and not to activate MIPv6 service. This is the
reason for the MN to send the Negotiation-Result-TLV.
Maybe this could be better explained in the document.

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, 2 Nov 2004 18:20:54 -0800

jak>> If they are not proxies, they would have to be caches. I don't think
the key derivation suggestion I mentioned in the original email would work,
though, unless the MN also can do it, and for that it would have to know
that it was talking with the subsidiary's AAA server.

jak>> I think it unlikely that the HA will support v2 and not v1. I'm not so
sure about the MN though, it might be possible there. It might be best to
include the IKE version, even though IKE apparently does allow adequate
version negotiation, especially if we include an indicator to get the home
address through IKE.

jak>> Yes it might be useful to explain that in the overview section.

            jak