Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 07:50:40 -0800

Yoshihiro Ohba wrote:
> Hi Vijay,
> 
> What I meant in my comment was that these requirements seem to
> indicate "mandatory-to-support and optional-to-use" features, and thus
> I thought it is better to say "MUST be able to" than "SHOULD be able
> to".  Perhaps we could simply say:
> 
> G5.2 The AAAH MAY indicate to the HA if the MN is authorized to
> autoconfigure its Home Address.
> 
> G6.2 The NAS MAY notify that it supports the functionalities described
> in [4].

sounds good to me.

Vijay

> 
> Yoshihiro Ohba
> 
> 
> On Tue, Oct 31, 2006 at 06:15:51PM -0800, Vijay Devarapalli wrote:
>> Gerardo Giaretta wrote:
>>
>>>>   G5.2  The AAAH SHOULD be able to indicate to the HA if the MN is
>>>>      authorized to autoconfigure its Home Address.
>>>>
>>>> YO: Why this is not "MUST be able to"?
>>>>
>>> I'll fix it.
>> this might be specific to the home agent. basically
>> the AAAH might not care whether the HA assigns the
>> home address or if the HA allows the MN to
>> autoconfigure the home address. so I don't think we
>> should have a "MUST" here.
>>
>>>>   G6.2  The NAS SHOULD be able to notify that it supports the
>>>>      functionalities described in [4].
>>>>
>>>> YO: The NAS notifies to whom?  I guess the NAS notifies AAAH server of
>>>> the functionalities.  If so, please explicitly mention it.  Also why
>>>> this is not "MUST be able to"?
>>>>
>>> ok, I'll fix it
>> again, should this be a MUST? I don't think we
>> should be requiring the NAS to be able to tell the
>> AAAH that it can support this functionality. Kuntal?
>>
>> Vijay
>>

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

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 2 Nov 2006 18:19:51 +0100

Hi Yoshi,

> >
> > This is not present in any bootstrapping solution specified in MIP6 WG
> > even though it may possible in some deployment scenarios.
>
> I thought that operators may want to let AAAH assign home
> address/prefix dedicated to a particular user.  But if no one cares
> this scenario, I would not care.
>

The operator requirement is to be able to assign a static HoA or home
prefix based on the user profile. One way to do that is to have the
AAAH assignign it.

However this may imply that we cannot re-use Diameter EAP application
as it is since we need this extra functionality.

What do others think? Should we add such a requirement?

> > >
> > >- In the integrated case, whether the AAA server for the AAA-HA
> > >interface and the AAA server for the AAA-NAS interface can be
> > >different.
> > >
> >
> > Isn't this related to the discussion? Maybe we can add a goal stating
> > that in integrated scenario the AAA server authenticating the network
> > access may be different from the AAA server authenticating the
> > mobility service and the solution must support this. Is it ok?
>
> Yes, this works for me for the second part.  What about the first part
> about separation of authentication and authorization?  In general,
> separation of authentication and authorization is good for being
> flexibile in providing services.  For example, in a particular
> scenario it is possible that an IKEv2 certificate without EAP is used
> for authenticating MN, but a AAA protocol is used for authorizing the
> MN.  Note that authorization does not necessary imply home
> address/prefix assignment by AAAH, it can be just a binary result
> (approved/denied).
>

I see the separation of authentication and authorization as a design
choice that we have done in DIME WG and not a requirement. Therefore,
I would not be in favor of adding any requirement related to
auth/authz split in this draft.

> >
> > >
> > >8.  Security Considerations
> > >
> > >   As stated in Section 5.1 the AAA-HA interface must provide mutual
> > >   authentication, integrity and replay protection.  Furthermore, if
> > >   security parameters (e.g., IKE pre-shared key) are transferred
> > >   through this interface, confidentiality is strongly recommended to be
> > >   supported.  However note that AAA protocols does not support this
> > >   unless it exists a direct connection between corresponding entities.
> > >
> > >YO: Is there any scenario in which security parameters are not
> > >transferred through this interface?
> > >
> >
> > What do you mean by security parameters here?
>
> I meant IKE pre-shared key because it is the only security parameter
> mentioned in the text.
>

ok, I can think of several scenarios in which the IKE PSK is sent to
the HA by the AAAH (as specified in my bootstrapping proposal based on
EAP) but we don't have this in any MIP6 official document.

Regards,
--Gerardo

> >
> > Anyway, the text si not fully correct since there is not any official
> > solution in MIP6 WG so far that implies that a pre-shared key is
> > transferred through this interface. However, there are some proposals
> > on this approach and I think the text in the sec cons can be kept.
>
> In the authorization-only scenario I mentioned above, no IKE
> pre-shared key would be transferred.
>
> Regards,
> Yoshihiro Ohba
>
>
> >
> > --Gerardo
> >

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 2 Nov 2006 18:21:27 +0100

Vijay,

both are "MUST be able to indicate" and not "MUST indicate". So I
would be in favor of keeping a MUST.

--Gerardo

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 2 Nov 2006 18:22:41 +0100

> > G6.2 The NAS MAY notify that it supports the functionalities described

Not sure MAY is the right key word. MUST be able is clear that is
mandatory to support and optional to use so I still prefer it.

--Gerardo

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 2 Nov 2006 13:26:01 -0500

> EAP) but we don't have this in any MIP6 official document.

OK, then it would be more appropriate to mention EAP MSK, which would
be used for signing IKEv2 AUTH payload after EAP authentication,
rather than IKE pre-shared key which seems to imply the key used for
IKEv2 PSK mode authentication.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 4 Nov 2006 19:37:01 -0800

All,
I know this is a few weeks late, given the WG LC has expired, but
hopefully, it is not too late :) 

I found the draft to be well written and quite complete. A few comments
below. 

1. In the integrated scenario, it seems to be assumed that the NAS gets
the MIP6 parameters. I'm not sure that the NAS and DHCP relay agent need
to be collocated. The NAS, where EAP is used for network access, for
instance, could be the L2 entity, while the DHCP relay agent is located
in the AR. So, is there any reason to tie the two entities? I would
suggest changing "NAS" to "DHCP Relay Agent in the ASA" or something to
that effect. 

2. Section 4.1 states "Note that even if EAP is used, the MN
authenticates the HA using public key based authentication." With double
EAP authentication for IKEv2 being defined, why does this have to be the
case? In other words, no need to preclude a double EAP, is there? 

3. Section 4.1 further states "Note that the AAA exchange between the HA
and the AAA server is normally terminated before the HA receives the
Binding Update message.  The reason is that the authentication has
succeeded if the Mobile Node is able to send the BU." I'm confused by
what this means. 

4. Section 4.2 states "In both cases, it is assumed that the AAA server
in the home domain (AAAH) authorizes both network access service and
mobility service." The HOKEY WG is defining the capability to perform
EAP re-authentication in visited domains. The mobility service may still
be under the home domain control. So, is there a need to have this
restriction? I suppose it can be viewed as the AAAH still authorizing
the network access during the first full EAP authentication, but I'm not
sure if that's what it means. Also, I can think of cases where, say, the
MN is using a local access (e.g., prepaid service in the local network).

5. "The HA SHOULD be able to query the AAAH server to verify Mobile IPv6
service authorization for the mobile node." Why would this not be a
MUST? 

6. The security considerations alludes to an IKE PSK being sent from the
AAAH to HA - I guess this is referring to the MSK - IKEv2 doesn't quite
consider this as the PSK. For instance, an IKEv2 PSK can be used
multiple times - i.e., to authenticate several IKEv2 exchanges. The EAP
MSK is only used once, in accordance with RFC4306 (the language is
vague, but that's the present case - the MSK is deleted after one use).
So, it is not quite the same as a PSK. 

Thanks,
Vidya

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Sun, 5 Nov 2006 19:39:29 +0100

Hi Vidya,

thanks for your feedback. Please find my comments below.

> suggest changing "NAS" to "DHCP Relay Agent in the ASA" or something to

I would like Kuntal or Alper to answer on this. I think the
co-location of the NAS and the DHCP Relay Agent is an assumption of
the integrated scenario solution based on DHCP.

In any case, from a functional point of view, we are talking about a
"AAA interface" so I think that the correct functional entity to
terminate the communication with the AAA server is the NAS. Then, I
agree with you that this information must be transferred to the DHCP
Relay if the NAS and the DHCP Relay are not co-located, but the AAA
server knows the NAS unless we want to make the DHCP Relay an AAA
client.

> case? In other words, no need to preclude a double EAP, is there?

I agree. The text was written to be fully in line with rfc4306. But
I'm fully in favour of the double EAP authentication here, therefore I
agree we can avoid this text.

> succeeded if the Mobile Node is able to send the BU." I'm confused by

The point is that the authentication step is performed during IKEv2
exchange, so during the bootstraping phase. When the first BU is
received by the HA, the actual user authentication has already been
performed by the AAA server. I hope now it's clearer, let me know if
you think we should re-phrase the text.

Note that this is discussed also in DIME WG because there are some
open issues about how the HA and AAAH should authorize e.g. address
autoconfiguration.

> MN is using a local access (e.g., prepaid service in the local network).

We can re-phrase stating that the first full EAP authentication and
the authorization for network access and mobility service are
performed in the home domain. Does it sound good?

> service authorization for the mobile node." Why would this not be a

Right, it's a MUST.

> So, it is not quite the same as a PSK.

The idea behind this statement was not the usage of MSK as PSK. There
have been some proposals to derive a key from the EAP authentication
for network access and use it as PSK in IKEv2 (I think there are two
individual drafts available on this topic right now): the statement
was introduced in order to give a pointer to this approach.

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Nov 2006 11:34:08 -0800

Narayanan, Vidya wrote:

> authenticates the HA using public key based authentication." 

I wonder if we should have this sentence in the
draft at all. RFC 4306 is already explicit about
this.

> With double

what is "double EAP authentication"?

> So, it is not quite the same as a PSK. 

this is valid if we talk about EAP alone. but I
think the HA-AAAH interface can be used to even
transfer keys that *can* be used as IKEv2 PSKs.

Vijay

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 05 Nov 2006 15:37:48 -0800

>what is "double EAP authentication"?

Perhaps the reference is to draft-eronen-ipsec-ikev2-eap-auth-05; IMO 
"double EAP" authentication at this point is a misnomer for that 
draft.  There is only one EAP authentication :).

Does that change anything for application of that protocol to the 
MIP6 scenario?

regards,
Lakshminath

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Nov 2006 15:57:27 -0800

Lakshminath Dondeti wrote:
> "double EAP" authentication at this point is a misnomer for that draft.  
> There is only one EAP authentication :).
> 
> Does that change anything for application of that protocol to the MIP6 
> scenario?

draft-ietf-mip6-aaa-ha-goals-03 should not talk about
this at all. draft-eronen-ipsec-ikev2-eap-auth-05 has
an impact only on draft-ietf-mip6-ikev2-ipsec.

version 4 of draft-ietf-mip6-ikev2-ipsec had the
following text.

    The IKEv2 specification [4] requires that public key based mechanism
    be used to authenticate the home agent to the mobile node, when EAP
    is used.  This should be used by default by the mobile node and the
    home agent.  If the EAP method that is used, supports mutual
    authentication and key generation, then the mobile node MAY use EAP
    itself to authenticate the home agent.  The mobile node can request
    this by including the EAP_ONLY_AUTHENTICATION notification payload
    [8] in message 3.  If the home agent supports the
    EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP,
    it omits the public key based AUTH and CERT payloads in message 4.
    If the home agent does not support this mechanism, it rejects it by
    including an AUTH payload in message 4.  More details can be found in
    [8].

but it was decided to remove this text because the
status for draft-eronen-ipsec-ikev2-eap-auth was
unknown. has that changed?

Vijay

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 06 Nov 2006 00:28:30 -0800

At 03:57 PM 11/5/2006, Vijay Devarapalli wrote:
>>Perhaps the reference is to draft-eronen-ipsec-ikev2-eap-auth-05; 
>>IMO "double EAP" authentication at this point is a misnomer for that draft.

No the status of that draft has not "changed."  It is still in "ID 
Exists" state.

Coming back to the issue at hand, I am curious about the group's 
opinion (we can discuss the status of 
draft-eronen-ipsec-ikev2-eap-auth-05 separately).  If the MN and the 
HA MUST mutually authenticate each other, then well 4306 
applies.  With the removal of the paragraph you included above, 
that's what it defaults to.  This is my preference.

If HA authentication can be indirect (similar to that of a 
pass-through NAS in the EAP model), 
draft-eronen-ipsec-ikev2-eap-auth-05 could apply if there is 
consensus around it.  I would like to hear the case for this, if any.

Lakshminath