Subject: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Aug 2008 21:32:50 +0300

Hi all,

Avi gave a presentation about the MIP6 RADIUS draft
http://www3.ietf.org/proceedings/08jul/slides/mext-9.ppt
and the MIP6 RADIUS draft
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.txt
is the RADIUS counterpart of our Diameter Mobility documents:
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt and
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-09.txt

Now, here is the important part.

As part of the work on the draft, the feedback Avi got during the 
presentation and offlist comments from Pasi and Jari there are some 
concerns about the security properties provided by the following two 
mechanisms:
* IKEv2 with PSKs
* IKEv2 with CERTs

To briefly summarize the problems (also described in the slide set) 
there are the following issues:
* Having the AAA deliver a PSK key to the HA without the AAA performing 
authentication introduces security vulnerabilities. The discussed 
possible solutions where the AAA could authenticate the PSK are somewhat 
"clunky" since IKEv2 was never meant to be used in such a way.
*  Similar problems arise with IKEv2 and Certificates where the AAA 
server is used to just authorize without getting involved in the 
authentication procedure itself.

In an offline discussion between Jari, Pasi, Avi, and Jouni the idea 
came up to drop these two mechanisms from the MIP6 RADIUS document and 
consequently also from the Diameter MIPv6 Split draft.

Is this a bad thing?

I don't think so. Currently, we don't know anyone who would be using 
them. Hence, there are somewhat "theoretical" at the moment.

We could specify them once deployments would be asking for them.

Who has objections against dropping the above-described mechanisms from 
the  Diameter MIPv6 Split draft?

Ciao
Hannes

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

---

From: "Shastry, Shankarananda" <[email-masked]>
Date: Mon, 18 Aug 2008 19:14:25 +0530

All,

I have a query in the AUTH APPID that can be sent by the Client based on
the CER/CEA negotiation.

Scenario: 

Client Supports AUTH-APPID: 4,5,16777248
Server Supports AUTH-APPID: 5

Query: 

Should the client send messages other than Auth-APPID 5 to server? I
don't see any mention of this in RFC 3588. Any help in this is
appreciated.

Regards
Shankar

---

From: Sarkar Biplab <[email-masked]>
Date: Mon, 18 Aug 2008 19:26:20 +0530

Hi Shankar,

I think the number of AUTH-ID entries in the CEA should be
"less-than-or-equal-to" the number of AUTH-ID entries in CER. 
The following statement  seems to capture this idea.

============= RFC 3588[5.3] ===================
   The receiver only issues commands to its peers that have advertised
   support for the Diameter application that defines the command.  A
   Diameter node MUST cache the supported applications in order to
   ensure that unrecognized commands and/or AVPs are not unnecessarily
   sent to a peer.
==========================================

So depending up on who has sent the CER the parameters will vary but the
resultant values (minimal-set) should be same.

Thanks & Regards,
Biplab

---

From: Ankit Kumar Sharma <[email-masked]>
Date: Tue, 19 Aug 2008 10:46:26 +0530

Hi Shankar,

In addition to what Mr. Biplab has quoted, please look at the last paragraph of section 5.3 of RFC 3588:

=======================================================================

   With the exception of the Capabilities-Exchange-Request message, a

   message of type Request that includes the Auth-Application-Id or

   Acct-Application-Id AVPs, or a message with an application-specific

   command code, MAY only be forwarded to a host that has explicitly

   advertised support for the application (or has advertised the Relay

   Application Identifier).

=======================================================================

Cheers,

Ankit Kumar Sharma

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sarkar Biplab
Sent: Monday, August 18, 2008 7:26 PM
To: Shastry, Shankarananda
Cc: Sahoo, Yogamaya; Ganesan, Eshwar; [email-masked]
Subject: Re: [Dime] Query on Auth APPID Negotiation

Hi Shankar,

I think the number of AUTH-ID entries in the CEA should be "less-than-or-equal-to" the number of AUTH-ID entries in CER.
The following statement  seems to capture this idea.

So depending up on who has sent the CER the parameters will vary but the resultant values (minimal-set) should be same.

Thanks & Regards,
Biplab

All,

the CER/CEA negotiation.

Scenario:

Query:

appreciated.

Regards

Shankar

DiME mailing list

[email-masked]<mailto:[email-masked]>

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "DHIRANANDA SENAPATI" <[email-masked]>
Date: Tue, 19 Aug 2008 12:59:53 +0530

Hi Shankar,

Please look at the 2nd paragraph of section 5.3. Capabilities Exchange of
RFC 3588:

*************************

The receiver only issues commands to its peers that have advertised support
for the Diameter application that defines the command. A Diameter node MUST
cache the supported applications in order to ensure that unrecognized
commands and/or AVPs are not unnecessarily sent to a peer.

*************************
Regards,
Dhirananda

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 19 Aug 2008 09:22:46 -0700

Hi Hannes,

Thanks for the summary (useful as I missed the IETF meeting in Dublin).

I am fine with your proposal of dropping PSKs and CERTs support from the drafts.

Ciao
Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
> Sent: Sunday, August 17, 2008 11:33 AM
> To: [email-masked]
> Subject: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft
>
> Hi all,
>