Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 3 Nov 2006 15:29:49 +0100

Hi Madjid,

thanks for the review. Most comments are editorial and I'll fix them
in next version. Just one more detailed question below.

>
> 5.1.  General goals
>
>    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 AAAH to mutually authenticate each
>       other.  For example, let us consider the case where MSP is not the
>       MSA.  In such a case, several AAA intermediate proxies could
>       forward MIP6 bootstrapping information back and forth between HA
>       and AAA.  Thus, to prevent the installation of unauthorized state
>       on the HA, the path between HA and AAAH should be trustworthy>/
>
>
> Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing
> into something that is more of a
>
> AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end
> point authentication and AAA
>
> signaling security all in one requirement. Mutual authentication of HA and
> home AAA is one thing, protecting
>
> bootstrapping info over AAA messaging is another. This should be broken into
> two requirements. I believe you
>
> have text on confidentiality in G1.4. The AAA signaling security issue is
> that of a AAA client in visited
>
> AAA domain dealing with a home AAA domain are well known. for instance if
> you don't like the transitive
>
> trust provided by the hop by hop security in RADIUS, so you need external
> ways to cure the transitive trust
>
> problem. On the other hand providing a mutual authentication procedure
> between HA and home AAA server
>
> without intervention of AAA intermediaries in a whole different problem. So
> we need to be careful, otherwise
>
> we may end up ruling RADIUS out of here. Is that the intention?
>
> I would simply state the well known issues in the security consideration
> section.
>

sorry but I cannot get your point clearly.

which is your suggestion? Removing the requirement? Rephrasing it? Can
you please provide some text?

Thanks,
--Gerardo

>
> Giaretta, et al.         Expires March 16, 2007                 [Page 6]
>
>
> Internet-Draft          AAA Goals for Mobile IPv6         September 2006
>
>
>    G1.2  The AAA-HA interface MUST provide integrity protection in order
>       to prevent any alteration of exchanged data (e.g., Mobile IPv6
>       configuration parameters).
>
>    G1.3  The AAA-HA interface MUST provide replay protection.
>
>    G1.4  The AAA-HA interface SHOULD provide confidentiality since it
>       may be used to transfer keying material (e.g., shared key
>       generated during EAP method authentication).
>
> Madjid>>same comment as that on security in G1.1.
>
>    G1.5  The AAA-HA interface SHOULD support inactive peer detection.
>       This functionality can be used by the AAAH server to maintain a
>       list of active HAs.
>
>
> 5.2.  Service Authorization
>
> Madjid>>Typically authorization follows a successful authentication. It
> seems that the burden of the making
>
> sure the MN is authenticated falls into the lap of the HA, should we not
> have a requirement on this?
>
>    G2.1  The AAA-HA interface SHOULD allow the use of Network Access
>       Identifier (NAI) to identify the user.
>
> Madjid>>I believe for the split scenario. We were saying that the
> Diameter_EAP and Diameter-MIP need to use
>
> the same ID. does this cover that? Is NAI always the ID used for EAP?
>
>    G2.2  The HA SHOULD be able to query the AAAH server to verify Mobile
>       IPv6 service authorization for the mobile node.
>
>    G2.3  The AAAH server MAY assign explicit operational limitations and
>       authorization restrictions on the HA (e.g., packet filters, QoS
>       parameters).
>
>    G2.4  The AAAH server MUST be able to send an authorization lifetime
>       to the HA to limit Mobile IPv6 session duration for the MN.
>
>    G2.5  The HA MUST be able to request to the AAAH server an extension
>       of the authorization lifetime granted to the MN.
>
>    G2.6  The AAAH server MUST be able to force the HA to terminate an
>       active Mobile IPv6 session for authorization policy reasons (e.g.,
>       credit exhaustion).
>
>
> 5.3.  Accounting
>
>    G3.1  The AAA-HA interface MUST support the transfer of accounting
>       records needed for service control and charging.  These include
>       (but may not be limited to): time of binding cache entry creation
>       and deletion, octets sent and received by the mobile node in bi-
>       directional tunneling, etc.
>
>
>
>
>
>
> Giaretta, et al.         Expires March 16, 2007                 [Page 7]
>
>
> Internet-Draft          AAA Goals for Mobile IPv6         September 2006
>
>
> 5.4.  Mobile Node Authentication
>
>    G4.1  The AAA-HA interface MUST support pass-through EAP
>       authentication with the HA working as EAP authenticator operating
>       in pass-through mode and the AAAH server working as back-end
>       authentication server.
>
> Madjid>>Does this really have to be a MUST?
>
> 5.5.  Provisioning of Configuration Parameters
>
>    G5.1  The HA SHOULD be able to communicate to the AAAH server the
>       Home Address allocated to the MN (e.g., for allowing the AAAH
>       server to perform a DNS update on behalf of the MN).
>
>    G5.2  The AAAH SHOULD be able to indicate to the HA if the MN is
>       authorized to autoconfigure its Home Address.
>
>
>
> 6.  Goals for the Integrated Scenario
>
>    In the integrated scenario, the AAA server provides the HA
>    information to the NAS as part of the whole AAA operations for
>    network access.  Next goals are considered in addition to those
>    described in section Section 5.
>
>    G6.1  The AAAH server MUST be able to communicate the Home Agent
>       Information (IP Address or FQDN) to the NAS.
>
>    G6.2  The NAS SHOULD be able to notify that it supports the
>       functionalities described in [4].
>
>    G6.3  The ASP/MSP SHOULD be able to indicate to the MSA if it can
>       allocate a Home Agent to the MN.
>
>    G6.4  The AAA server of the MSA MUST be able to indicate to the NAS
>       whether the MN is authorized to use a local Home Agent (i.e. a
>       Home Agent in the ASP/MSP)
>
>
>
> Giaretta, et al.         Expires March 16, 2007                 [Page 8]
>
>
> Internet-Draft          AAA Goals for Mobile IPv6         September 2006
>
>
> 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.
>
> Madjid>> Diameter supports this. should say "some AAA protocols".
>
>
>
> -----Original Message-----
> From: Gerardo Giaretta [mailto:[email-masked]]
> Sent: Tuesday, October 03, 2006 8:13 AM
> To: [email-masked]
> Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03
>
> FYI, please review the document.
>
> --Gerardo
>
> ---------- Forwarded message ----------
> From: Basavaraj Patil <[email-masked]>
> Date: Oct 3, 2006 4:49 PM
> Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03
> To: [email-masked]
>
>
>
> Hello,
>
> This is a Working group last call for the WG I-D: AAA Goals for Mobile
> IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve
> as the AAA requirements for Mobile IPv6.
>
> Please review the I-D and submit your comments to the authors or to
> the list directly.
>
> The WGLC expires on Oct 18th, 06.
>
> The I-D is intended to be published as an Informational RFC.
>
> -Raj
>
>
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Sat, 04 Nov 2006 14:15:02 -0800

The doc calls itself AAA-HA goals, so We need to see what we need to
accomplish by the document

1) define AAA function requirements on HA and on HA-AAA server protocol?

2) what is vendor required to put inside MIP6 HA to support AAA interaction.

If the goal is 1) and you are not careful, you can unintentionally rule out
RADIUS. Plus some of the requirements are beyond the scope of those for AAA
client (HA) and AAA protocols. I am just pointing out that unless trying to
set up a set of goals for the Dime drafts, we need to be careful about the
side-effect of ruling out use of RADIUS for MIP6.

Let me go through the goal

>       on the HA, the path between HA and AAAH should be trustworthy>/

Madjid>>I am going to assume HA is AAA client, not sure, if authentication
between a AAA client and a AAA is an explicit requirement in any of the AAA
protocols. First it means a direct SA between the HA and AAAH. If there are
proxies on the AAA path, RADIUS for one does not support the end to end SA
directly, let alone the act of end to end authentication.
I understand that sending keys from AAAH to HA requires tight security, but
this is not a "AAA requirement", since it may not be covered by some AAA
protocols, it is part of security provisioning for the entire HA design. You
may want to bring this up in "security consideration section".

You already seem to have this part of security consideration, so not sure
why it is also mentioned as AAA-HA goal, unless the goal of the doc is the
(2) mentioned above.

I hope I have been helpful.

R,

Madjid 

-----Original Message-----
From: Gerardo Giaretta [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 6:30 AM
To: Madjid Nakhjiri
Cc: [email-masked]; [email-masked]; Julien Bournelle
Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d:
draft-ietf-mip6-aaa-ha-goals-03

Hi Madjid,

Thanks,
--Gerardo

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 6 Nov 2006 10:01:00 -0800

Hi Madjid,

> why it is also mentioned as AAA-HA goal, unless the goal of the doc is the

ok, now I get your point. However in the goal text we have already
added this sentence:

      In some deployment scenarios, it
      may not be feasible for HA and AAAH to mutually authenticate each
      other.  For example, let us consider the case where MSP is not the
      MSA.  In such a case, several AAA intermediate proxies could
      forward MIP6 bootstrapping information back and forth between HA
      and AAA.  Thus, to prevent the installation of unauthorized state
      on the HA, the path between HA and AAAH should be trustworthy.

This was added exactly for RADIUS. Doesn't this text solve your issue?

--Gerardo

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 06 Nov 2006 14:27:43 -0800

-----Original Message-----
From: Gerardo Giaretta [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 10:01 AM
To: Madjid Nakhjiri
Cc: [email-masked]; [email-masked]; Julien Bournelle
Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d:

Hi Madjid,

Madjid>>Yes, hence my comments, you are raising a well-known issue for
RADIUS in a "AAA requirement section". Everybody knows RADIUS has this
issue, so are trying to say RADIUS cannot/should not be used. If this is not
your intentention (I don't think it is), you should simply remove the entire
comment into the security section. It does not belong as a "AAA
requirement".

Madjid

--Gerardo