Subject: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 11 Jan 2008 19:35:14 +0100

Hi,

With this email we issue the WGLC for draft-ietf-mext-aaa-ha- 
goals-00.txt
The WGLC will be open till the 31 of january.
We kindly ask the WG to review the document and provide comments.

Please note that a valid comment at this stage is positive feedback  
about the document being ready to be shipped.
So, please if you think the doc is ready, do express this to the ml  
(or to the chairs)

For you convenience, additional information about the document:

	Title           : AAA Goals for Mobile IPv6
	Author(s)       : G. Giaretta, et al.
	Filename        : draft-ietf-mext-aaa-ha-goals-00.txt
	Pages           : 12
	Date            : 2007-12-27

In commercial and enterprise deployments Mobile IPv6 can be a service
offered by a Mobility Services Provider (MSP).  In this case all
protocol operations may need to be explicitly authorized and traced,
requiring the interaction between Mobile IPv6 and the AAA
infrastructure.  Integrating the AAA infrastructure (e.g.  NAS and
AAA server) offers also a solution component for Mobile IPv6
bootstrapping.  This document describes various scenarios where a AAA
interface for Mobile IPv6 is required.  Additionally, it lists design
goals and requirements for such an interface.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt

Regards, Julien and marcelo

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jan 2008 09:38:11 +0200

A few minor comments below.

FROM:

   The Home Agent can the assigned either in the Access Service
   Provider's network or in the seprate network. 

TO:

   The Home Agent can be assigned either in the Access Service
   Provider's network or in the separate network. 

   G1.1  The AAAH server and the HA MUST be able to authenticate each
      other (mutual authentication) in order to prevent the installation
      of unauthorized state on the HA.
      In some deployment scenarios, it
      may not be feasible for HA and AAA server to mutually authenticate
      each other.  In such a case, several AAA intermediate proxies
      could forward MIP6 bootstrapping information between HA and AAA.
      Thus, to prevent the installation of unauthorized state on the HA,
      the path between HA and AAAH should be secure.

[hannes] "should be secure" is a bit fuzzy. In essence you are building 
on the
AAA model with a hop-by-hop security mechanisms. Maybe a better wording 
would be

"
Thus, to prevent the installation of unauthorized state on the HA,
the communication security mechanisms available with the AAA 
infrastructure 
MUST be used between adjacent AAA peers.
"

I would fold requirement G1.2 and G1.3 into G1.1 since they are so closely
related.

   G2.10  The AAAH server MUST be able to authorize the MN for Dual
      Stack operation [9].

What exactly does this mean?

   G2.11  The AAAH server MUST be able to indicate to the HA whether the
      bearer traffic for the MN needs to receive IPsec ESP protection.

I don't understand this either.

   G2.12  The HA MUST be able to authenticate the MN through the AAAH in
      case a pre-share key is used in IKEv2 for user authentication.
      The exact procedure is part of the solution space.

Why do you list this requirement? I believe it is pretty much useless given
that it is a consequence of the solution. I suggest to delete this 
requirement.

   G4.1  The AAA-HA interface MUST allow the HA to act as a pass-through
      EAP authenticator.

This is a consequence of the already established solution. I suggest to
delete it.

   G4.2  The AAA - HA interface SHOULD support authentication based on
      the Mobility Message Authentication Options defined in [5].

A solution must be specified in the specification but it's usage is 
optional.

Section 5.4. about Mobile Node Authentication:

   G4.5  The HA MUST include the Mobile Node Identifier option [7] in
      the AAA transactions with the AAAH server.

This requirement almost sounds like a solution description already.
Isn't this a solution detail that does not need to be mentioned in such 
a document?

The same
is true for requirement G4.7, which says:

   G4.7  If the MN-AAA Mobility Message Authentication Option is not
      included by the HA or the MN-AAA Mobility Message Authentication
      Option is included and the MN-AAA authentication is successful,
      the AAAH MUST send the keying material for MN-HA key to the HA if
      the HA requested for MN-HA keying material only.  The AAAH MUST
      send the MN-HA key and the corresponding SPI value to the HA if
      the HA requested for MN-HA key and SPI.

This paragraph sounds really complex. The first sentence is pretty much
irrelevant for such a requirements document. Isn't the 2nd sentence covered
by requirement in G4.3 already?

   G4.6  The AAAH server SHOULD be able to authenticate the MN
      identified by the value in the Mobile Node Identifier option using
      the value in MN-AAA Mobility Message Authentication Option and the
      corresponding value of the SPI.

Isn't requirement G4.6 already covered by the previous requirements?

   G6.2  The NAS SHOULD be able to notify the AAAH of the
      functionalities described in [4].

Couldn't we just list what it should notify the AAAH about? It isn't a lot.

Ciao
Hannes

marcelo bagnulo braun wrote:
> Hi,
>
> With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals-00.txt

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 14 Jan 2008 17:45:25 -0800

Hi Hannes,

Thanks for the comments. Please see inline
>    Provider's network or in the separate network.

Good catch, thanks.

> MUST be used between adjacent AAA peers.

Good. I will change the text to the proposed one. Thanks

> I would fold requirement G1.2 and G1.3 into G1.1 since they are so
closely

What do you mean exactly? Are you suggesting to have a single
requirement?
> What exactly does this mean?

It means that a MN may be authorized to use MIPv6 as in RFC3775 or may
be authorized also to have an IPv4 HoA assigned for DSMIPv6. 

> I don't understand this either.

The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP tunnel or
an ESP tunnel. 

> that it is a consequence of the solution. I suggest to delete this

I agree it is a consequence of the solution. However, I think it is good
to make it clear here as RFC 5026 provides text for PSK, EAP and
certificates. I don't think it is bad to have it.

> This is a consequence of the already established solution. I suggest
to

Same as above.

> A solution must be specified in the specification but it's usage is

Can you clarify your comment please?

> Isn't this a solution detail that does not need to be mentioned in
such

Yes, you are probably right. The idea was that the HA MUST include an
identifier of the MN in the AAA transactions. 

A possible rewording could be

"The HA MUST include an identifier of the mobile node in the AAA
transactions with the AAAH server"

Would that work? Or are you suggesting removing completely the goal?

> by requirement in G4.3 already?

I agree we can remove the first sentence. The second sentence is
different form G4.3, though: G4.3 is about the HA to request the keying
material while G4.7 is about the AAAH sending it. Would you prefer merge
the two goals?

> Isn't requirement G4.6 already covered by the previous requirements?

Yes, agree. I hope Kuntal is fine if we remove this goal.

> Couldn't we just list what it should notify the AAAH about? It isn't a
lot.

OK, suggested rewording:

G6.2  The NAS MUST be able to notify the AAAH if it supports the AAA
extensions designed to receive the HA assignment information [4].

Gerardo

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Jan 2008 10:20:51 +0200

Hi Gerardo,

please find my comments inline:

Giaretta, Gerardo wrote:
>>       other (mutual authentication) in order to prevent the
>>     
> installation
>   
>>       may not be feasible for HA and AAA server to mutually
>>     
> authenticate
>   
>>       Thus, to prevent the installation of unauthorized state on the
>>     
> HA,
>   
>> [hannes] "should be secure" is a bit fuzzy. In essence you are
>>     
> building
>   
>> on the
>> AAA model with a hop-by-hop security mechanisms. Maybe a better
>>     
> wording
>   
>> would be
>>
>> "
>> I would fold requirement G1.2 and G1.3 into G1.1 since they are so
>>     
> closely
>   
>> related.
>>
>>     
>

I would write:

   G1.1  The communication between the AAAH server and the HA
      MUST reuse existing AAA security mechanisms with regard to
     authentication, replay, integrity, and confidentiality protection.
     These communication security mechanisms
     prevent a number of classical threats, including the alteration
     of exchanged data (e.g., Mobile IPv6 configuration parameters)
     and the installation of unauthorized state.

Then, delete G1.2 and G1.3.

> be authorized also to have an IPv4 HoA assigned for DSMIPv6. 
Maybe we should then write:

  G2.10  The AAAH server MUST be able to support different levels of 
Mobile IPv6 authorization. For example, the AAAH server may 
authorize the MN to use of MIPv6 (as defined in [RFC3775]) or may
authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [9].

>>    G2.11  The AAAH server MUST be able to indicate to the HA whether
>>     
> the
>   
Hmmm. I might have missed something but Mobile IP establishes IP-in-IP 
(or GRE tunnels) and not ESP tunnels.

>   
>>    G2.12  The HA MUST be able to authenticate the MN through the AAAH
>>     
> in
>   
Then, I would write make it more explicitly. Just say that RFC 5026 
supports different
authentication mechanisms (PSK, EAP and certificates) and the solution 
specification MUST
specify all variants.

>>    G4.1  The AAA-HA interface MUST allow the HA to act as a
>>     
> pass-through
>   
>>       EAP authenticator.
>>
>> This is a consequence of the already established solution. I suggest
>>     
> to
>   
>> delete it.
>>
>>
>>     
>
> Same as above.
>
>   
I believe that this requirement refers to the usage rather than the 
functionality of the specification.
Here, I would place a MUST since we have to specify it in the solution 
document.

>> Isn't this a solution detail that does not need to be mentioned in
>>     
> such
>   
>> a document?
>>
>>     
>
That's fine.

>>       the AAAH MUST send the keying material for MN-HA key to the HA
>>     
> if
>   
>> This paragraph sounds really complex. The first sentence is pretty
>>     
> much
>   
I would combine it since it is a requirement for requesting a keying 
material would (in my opinion)
 also imply that you have a way to receive it.

>>       identified by the value in the Mobile Node Identifier option
>>     
> using
>   
>>       the value in MN-AAA Mobility Message Authentication Option and
>>     
> the
>   
>> Couldn't we just list what it should notify the AAAH about? It isn't a
>>     
> lot.
>   
>
> OK, suggested rewording:
>
Sounds good.

Ciao
Hannes

>>> With this email we issue the WGLC for draft-ietf-mext-aaa-ha-goals-
>>>       
>> 00.txt
>>     
>>> In commercial and enterprise deployments Mobile IPv6 can be a
>>>       
> service
>   
>>> bootstrapping.  This document describes various scenarios where a
>>>       
> AAA
>   
>>> interface for Mobile IPv6 is required.  Additionally, it lists
>>>       
> design
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 18 Jan 2008 16:38:41 -0800

Hi Hannes,

Please see inline

> Then, delete G1.2 and G1.3.

This is fine to me. I will change it.

> authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6
[9].

That's fine too. 

> (or GRE tunnels) and not ESP tunnels.

The HA and MN may configure a child SA to protect payload traffic. In
this way the packets from HA to MN are protected using ESP. 

> >> Why do you list this requirement? I believe it is pretty much
useless
> >> given

This was suggested by Vijay. The point is that the HA may be able to
fetch the PSK from the AAAH in case it does not have it. It's not only
supporting PSK within IKEv2, rather contacting the AAAH to verify the
PSK.

> Here, I would place a MUST since we have to specify it in the solution

MUST is fine

>  also imply that you have a way to receive it.

Can you please propose some text? I still don't fully understand the
implications of the proposal. 

> > extensions designed to receive the HA assignment information [4].

Thanks again for the review

Gerardo

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Jan 2008 21:19:04 +0200

Hi Gerardo,

thanks for your quick response. Please find my comments inline:

~snip~
>>
>>     
>>>>    G2.11  The AAAH server MUST be able to indicate to the HA
>>>>         
> whether
>   
>>> the
>>>
>>>       
>>>>       bearer traffic for the MN needs to receive IPsec ESP
>>>>         
> protection.
>   
>>> The AAA may indicate if the MIPv6 tunnel should be an IP-in-IP
>>>       
> tunnel or
>   
>>> an ESP tunnel.
>>>
>>>       

This is a somewhat new requirement for me and we have not addressed this 
aspect in our DIME documents.

The additional issue with this requirement is that one needs to have a 
way to run an authorization exchange between the HA and the AAAS after 
the authentication.
At the moment the authorization exchange and the authentication exchange 
happen at the same time.

I will post a separate mail to the DIME list to see what implication 
this has with respect to the protocol design.

>>>>    G2.12  The HA MUST be able to authenticate the MN through the
>>>>         
> AAAH
>   
>>> in
>>>
>>>       
>>>>       case a pre-share key is used in IKEv2 for user
>>>>         
> authentication.
>   
>>> I agree it is a consequence of the solution. However, I think it is
>>>       
> good
>   
The way how IKEv2 works would not allow PSK based authentication to be 
relayed to the AAA server. It does not work with legacy PSK credentials.
Hence, the only reasonable way is to request the PSK from the AAAH.

But this is fine with me. I don't see a contradiction between the 
requirements text I wrote and the one envisioned by Vijay.

~snip~

>>>>    G4.7  If the MN-AAA Mobility Message Authentication Option is
>>>>         
> not
>   
>>>>       included by the HA or the MN-AAA Mobility Message
>>>>         
> Authentication
>   
>>>>       Option is included and the MN-AAA authentication is
>>>>         
> successful,
>   
>>>>       the AAAH MUST send the keying material for MN-HA key to the
>>>>         
> HA
>   
>>> if
>>>
>>>       
>>>>       the HA requested for MN-HA keying material only.  The AAAH
>>>>         
> MUST
>   
>>>>       send the MN-HA key and the corresponding SPI value to the HA
>>>>         
> if
>   
>>> different form G4.3, though: G4.3 is about the HA to request the
>>>       
> keying
>   
>>> material while G4.7 is about the AAAH sending it. Would you prefer
>>>       
> merge
>   
>>> the two goals?
>>>
>>>
>>>       
Here is G4.7

Here is G4.3:

   G4.3  The HA SHOULD be able to request either the keying material to
      generate MN-HA key for MN-HA Mobility Message Authentication
      Option or SHOULD be able to request the MN-HA key and the related
      SPI values from the AAAH server.

The new requirement as a replacement of the above 2:

The AAAH MUST be able to provide a MN-HA key (or data used for 
subsequent key derivation of the
MN-HA key by the HA) to the HA if requested.
Additional data, such as the SPI or lifetime parameters, are sent along 
with the keying material.

~snip~

Ciao
Hannes

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 30 Jan 2008 15:35:41 -0800

Hannes, 

The changes you proposed are fine. I saw that you sent an email to DIME
to request comments on the ciphering aspects. That is fine with me;
let's see if there is any opinion there. 

However let's remember that requirements should influence the solution
and not the other way around :-)

Ciao
Gerardo

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, January 19, 2008 11:19 AM
> To: Giaretta, Gerardo
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] WGLC for draft-ietf-mext-aaa-ha-goals-00.txt
> 
> Hi Gerardo,
> 
> >>>> irrelevant for such a requirements document. Isn't the 2nd
sentence
> >>>> covered
if

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Jan 2008 09:44:53 +0200

Hi Gerardo

> let's see if there is any opinion there. 
So far, no response.

> and not the other way around :-)
That's correct. I just wanted to make the group aware of a requirement 
that I haven't seen before.

Ciao
Hannes
>>>> Hmmm. I might have missed something but Mobile IP establishes
>>>>         
> IP-in-IP
>   
>>> The HA and MN may configure a child SA to protect payload traffic.
>>>       
> In
>   
>> This is a somewhat new requirement for me and we have not addressed
>>     
> this
>   
>> At the moment the authorization exchange and the authentication
>>     
> exchange
>   
>> happen at the same time.
>>
>>>>>> that it is a consequence of the solution. I suggest to delete
>>>>>>             
> this
>   
>>>>>> requirement.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> I agree it is a consequence of the solution. However, I think it
>>>>>           
> is
>   
>>> good
>>>
>>>       
>>>> authentication mechanisms (PSK, EAP and certificates) and the
>>>>         
> solution
>   
>>>> specification MUST
>>>> specify all variants.
>>>>
>>>>
>>>>         
>>> fetch the PSK from the AAAH in case it does not have it. It's not
>>>       
> only
>   
>>> supporting PSK within IKEv2, rather contacting the AAAH to verify
>>>       
> the
>   
>>> PSK.
>>>
>>>
>>>       
>> relayed to the AAA server. It does not work with legacy PSK
>>     
> credentials.
>   
>>>>>>       send the MN-HA key and the corresponding SPI value to the
>>>>>>             
> HA
>   
>>> if
>>>
>>>       
>>>>>> This paragraph sounds really complex. The first sentence is
>>>>>>             
> pretty
>   
>>>>>>             
>>>>> much
>>>>>
>>>>>
>>>>>           
>>>> I would combine it since it is a requirement for requesting a
>>>>         
> keying
>   
>>    G4.3  The HA SHOULD be able to request either the keying material
>>     
> to
>   
>>       Option or SHOULD be able to request the MN-HA key and the
>>     
> related
>   
>> Additional data, such as the SPI or lifetime parameters, are sent
>>     
> along
>