Subject: [Dime] New draft for Diameter ERP: poll for adoption

From: Sebastien Decugis <[email-masked]>
Date: Mon, 08 Jun 2009 12:57:04 +0900

Hi all DIME and HOKEY members,

I have gone forward on the Diameter ERP topic and created a new draft
[1] with the same content (re-organized, hopefully for clarity) as I
presented during last DIME meeting in IETF#74. The main change with
current draft-ietf-dime-erp-00 is the use of a new separate Diameter
application for messages exchanged between the NAS and the ER server.

I would like to poll the people interested in this topic about the
adoption of this new document for Diameter ERP (in which case it would
become draft-ietf-dime-erp-01). I don't know if this can be done before
the next IETF meeting, or at least during the meeting in Stockholm?

Thank you for reading, and eventually providing your comments.
Sebastien.

[1]
http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.txt

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 8 Jun 2009 11:48:44 +0700

> become draft-ietf-dime-erp-01). 

Isn't this the job of the WG Chairs?

> I don't know if this can be done before

I am strongly opposed to the adoption of this draft as a WG item, if for no
other reason than that it is clearly derived from other work (as is admitted
in section 1.1), the authors of which are not recognized.  Add Wu,
Bournelle, Morand & Dondeti to the author list (provided that they agree, of
course).  BTW, "disappearing" co-authors is one good way to ensure that no
one agrees to collaborate with you in the future...

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

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 08 Jun 2009 14:13:38 +0900

Hello,

Thank you for quick answer.

> Isn't this the job of the WG Chairs?
Ok, I did not know. My intent is just to provide this new idea for
workgroup consideration, within the scope of the Diameter ERP topic that
is already a workgroup item.

> one agrees to collaborate with you in the future...
The authors of the previous draft are listed in contributors section. As
you mention, I don't know if they agree with the content of this new
draft, hence they are not listed as authors for this submission. Anyway,
in case the document is accepted (for its ideas, not its form...) the
authors list would be restored of course. I am not doing this to steal
the work of other people, just trying to push a new different idea to
move the document forward. And I already tried to involve in this new
direction the other co-authors of the previous draft, but got no answer,
hence my separate submission.

Sorry for the apparently tactless process, I hope my intent is now
clarified.

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 8 Jun 2009 13:20:01 +0700

Sebastien Decugis [mailto://[email-masked]] writes:

...

> hence my separate submission.

I see.  Maybe they will respond now!

> Sorry for the apparently tactless process, I hope my intent is now

Re-reading my response above, it appears that I was the one w/o tact!  I
didn't mean to suggest any nefarious intent on your part, please accept my
apology.

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Jun 2009 15:01:41 +0800

Hi, Sebastien:
Thank for creating your new idea based on our new draft on local key draft and providing it to the WG consideration.

Considering that the key  transport mechanism is not limited to be used in the ERP in the Hokey architecture, local key transport
can also be used in the pre-authentication or early authentication. So We write the draft on local key transport(i.e.,draft-wu-dime-local-keytran ) which occurs during the bootstrapping procedure between the local server and home server.

Have a quick glance at your draft, I found your draft also discuss key transport which has already been covered in the draft-wu-dime-local-keytran. I am not sure these two drafts are overlapped as regarding key transport mechanism. However I am interested in your new draft, for it is more clear and better as compared to I-D.ietf-dime-erp.  May I ask to coauthor this new work and push forward this new draft on Diameter ERP topic? 
Thanks a lot!

Regards
Qin

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Jun 2009 15:42:13 +0800

> Bournelle, Morand & Dondeti to the author list (provided that they agree, of

[Qin]: I accept being included in the author list.

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 8 Jun 2009 10:38:42 +0200

Hi sebastien, all,

 See below,

> hence my separate submission.

I thought the consensus was to wait for HOKEY WG inputs, in particular on
architectural aspects before moving forward with what we already did !

 I have to admit that I'm a little surpised...

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 08 Jun 2009 17:38:56 +0900

Hi Qin,

Thank you for your positive feedback. Please see my comments bellow.

> can also be used in the pre-authentication or early authentication. So We write the draft on local key transport(i.e.,draft-wu-dime-local-keytran ) which occurs during the bootstrapping procedure b…
This is also the intent of the new AVPs I defined in the new draft. They
are functionnally equivalent to the ones you define in your document,
although the format is slightly different. The same applies also to the
AVPs defined in the ietf-dime-erp-00 document. Since they are not
mandatory AVPs, they can be used for non-ERP situations without any
problem, I think (for example added in a different command than DER /
DEA, without any change to the ABNF).

> Have a quick glance at your draft, I found your draft also discuss key transport which has already been covered in the draft-wu-dime-local-keytran. I am not sure these two drafts are overlapped as…
You are right, this new draft probably overlaps and superseeds your
draft and the previous WG ERP draft (as stated in its introduction). I
hope it covers every aspects of ERP with Diameter (hence including key
distribution) and that the AVPs are designed in such way that they can
be re-used in other context as needed (for example for other
applications that would need key distribution.)

I have no objection adding you as a co-author (as well as all co-authors
of the previous ietf-dime-erp draft, unless they want to be removed) in
a future version if this document gets support from the WG.

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 08 Jun 2009 18:06:37 +0900

Hi Julien,

> I thought the consensus was to wait for HOKEY WG inputs, in particular
> on architectural aspects before moving forward with what we already did !
As a matter of fact, this new draft is just a rewritting of a design
document I wrote before the previous IETF (and presented at that
meeting), before this decision to wait for a (hypothetical)
clarification document was taken.

>  I have to admit that I'm a little surpised...
Let me clarify this in private mail (it's easier to do in my native
language, and also not of much interest to other people on the lists...)

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Tue, 09 Jun 2009 09:44:53 +0800

Hi, Sebastien:
Thank you for your kind feedback. Please see my reply below. 
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 08, 2009 4:38 PM
Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption

> AVPs defined in the ietf-dime-erp-00 document. 
[Qin]: As I discussed with Glen before, We recommend to use more generic new AVPs to accommodate all the key materials containing DSRK, MSK,rMSK.
The format of this grouped new AVP is:
EAP-Key ::= < AVP Header: TBD >

                     { EAP-KEY-TYPE enumerated <DSRK,MSK,rMSK>}

                     { EAP-KEY-NAME }

                     { EAP-KEY-LIFETIME}

                    *[ AVP ]

However I have not updated the draft-wu-dime-local-keytran-00 based this idea mentioned above

before you posted the new draft for Diameter ERP,:).I think your idea in the draft is probably okay.

>Since they are not
> problem, 

[Qin] I agree.

I think (for example added in a different command than DER /
> DEA, without any change to the ABNF).

[Qin]: I am not sure. I think It needs to be further discussion.
 In my mind, it is not clear whether we extend DER/DEA or define new Command Code to accommodate the two new EAP code,i.e.,EAP Initiate/Finish, as regarding key distribution between local server and home server, is it okay for us to reuse DER/DEA to transport the key to the right local server? We need to think about it.

> a future version if this document gets support from the WG.

[Qin]: I'd be happy to contribute/co-author these drafts and support the work on this topic.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 09 Jun 2009 12:20:42 +0900

Hi,

> [Qin]: As I discussed with Glen before, We recommend to use more generic new AVPs to accommodate all the key materials containing DSRK, MSK,rMSK.
I see. I think we can re-use the EAP-Master-Session-Key existing AVP
container for transporting key material. I am not aware of any existing
AVP suitable for Lifetime and key name, but there are probably some
already (maybe in the RADIUS namespace). Then, creating a grouped AVP
including all these elements, plus optional others, for each purpose,
seems straightforward to me. Anyway, this can be discussed later, it's
not a fundamental design issue, IMHO.

>  In my mind, it is not clear whether we extend DER/DEA or define new Command Code to accommodate the two new EAP code,i.e.,EAP Initiate/Finish, as regarding key distribution between local server an…
That is the main concern of this new draft. Diameter routing is based on
the application-id and destination-realm, not the command code. So
re-using DER/DEA or creating a new command code is not related to the
problem of routing the message to the proper server. For this purpose,
the draft creates a new application id (Diameter ERP).

> [Qin]: I'd be happy to contribute/co-author these drafts and support the work on this topic.
Great, thank you :) Let's see what other people think...

Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 9 Jun 2009 09:01:30 +0200

Hello,

 See inline,

> the next IETF meeting, or at least during the meeting in Stockholm?

AFAIK, this is not how things are working at IETF. The WG has already a WG
document called draft-ietf-dime-erp-00.txt which is supposed to reflect the
current WG consensus. We can't arrive with a new individual submission and
just bypass the current WG I-D. At least, I never saw that.

Having said that, we have an issue with the current WG document concerning
use of a new Application-ID or reuse of the Diameter EAP. My understanding
was that we were a little blocked because of an architectural issue
concerning the HOKEY server in regards to AAA/EAP server and because of a
routing issue. So I'd like to know what has changed from this point.

 Note that I'm not against your proposal per se. We just have to get a
consensus.

 Best regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 09 Jun 2009 17:27:54 +0900

Hi,

(BTW, I propose the follow-ups directed to the DIME mailing-list only,
to avoid the cross-posting. If people from HOKEY ML are interested and
not subscribed to DIME ML, let me know...)

> AFAIK, this is not how things are working at IETF. The WG has already
> a WG document called draft-ietf-dime-erp-00.txt which is supposed to
> reflect the current WG consensus. We can't arrive with a new
> individual submission and just bypass the current WG I-D. At least, I
> never saw that.
Well, once again, sorry for the quiproquo here... I was not
ill-intended, just interested in pushing a new different direction for
the design of Diameter ERP, and submit the new idea to the WG(s) for
consideration (and eventually integration, not by-passing). Enough with
the politics on the WG lists (but I can continue in private if people
want to argue), and let's focus on technical matters...

> Having said that, we have an issue with the current WG document
> concerning use of a new Application-ID or reuse of the Diameter EAP.
> My understanding was that we were a little blocked because of an
> architectural issue concerning the HOKEY server in regards to AAA/EAP
> server and because of a routing issue. So I'd like to know what has
> changed from this point.
For the routing issue: this new proposal aims to solve it.
For the architectural issue: I think it was a misunderstanding from the
beginning, or at least I did not understand the issue, so if someone can
clarify (what the issue was), it would be helpful.

>  Note that I'm not against your proposal per se. We just have to get a
Of course!

Best regards,
Sebastien.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 9 Jun 2009 11:46:17 +0300

Hi all, 
 
there seems to be a misunderstanding here. 
 
We have a working group document with agreed authors. 
The only question therefore is what the group wants to go into the
existing document - the content. No new document will be added to the
DIME milestones.
 
What Sebastien should be asking the group is whether the content in
draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
version of draft-ietf-dime-erp. 
 
I personally think that draft-ietf-dime-erp-01 could have included the
updated text already since we discussed it on the list. Anyway, ... 

In any case, it is good to ask the group whether this significant change
should be made. 

My answer: I believe that this is the right direction, as I indicated
previously on the list. 

Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Julien Bournelle
	Sent: 09 June, 2009 10:02
	To: Sebastien Decugis
	Cc: [email-masked]; [email-masked]
	Subject: Re: [Dime] New draft for Diameter ERP: poll for
adoption

	Hello,
	
	 See inline,

	On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
<[email-masked]> wrote:

		I have gone forward on the Diameter ERP topic and
created a new draft
		[1] with the same content (re-organized, hopefully for
clarity) as I
		presented during last DIME meeting in IETF#74. The main
change with
		current draft-ietf-dime-erp-00 is the use of a new
separate Diameter
		application for messages exchanged between the NAS and
the ER server.
		
		I would like to poll the people interested in this topic
about the
		adoption of this new document for Diameter ERP (in which
case it would
		become draft-ietf-dime-erp-01). I don't know if this can
be done before
		the next IETF meeting, or at least during the meeting in
Stockholm?

	AFAIK, this is not how things are working at IETF. The WG has
already a WG document called draft-ietf-dime-erp-00.txt which is
supposed to reflect the current WG consensus. We can't arrive with a new
individual submission and just bypass the current WG I-D. At least, I
never saw that.
	
	Having said that, we have an issue with the current WG document
concerning use of a new Application-ID or reuse of the Diameter EAP. My
understanding was that we were a little blocked because of an
architectural issue concerning the HOKEY server in regards to AAA/EAP
server and because of a routing issue. So I'd like to know what has
changed from this point.
	
	 Note that I'm not against your proposal per se. We just have to
get a consensus.
	
	 Best regards,
	
	 Julien

		
		Thank you for reading, and eventually providing your
comments.
		Sebastien.
		
		[1]
	
http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.
txt

---

From: Tina TSOU <[email-masked]>
Date: Wed, 10 Jun 2009 12:23:17 +0800

Hi Hannes,
Thank you for your clarification. It is much clearer.
This change should be made, since ERP is one of the most important  
applications for Diameter.

B. R.
Tina
IPTIME - Unified QoS ARchitecture (UQAr) [ju'ka:] /pronounced like  
"you"+"car"/
[email-masked]
http://uqar.weebly.com
http://tinatsou.weebly.com/contact.html

On Jun 9, 2009, at 4:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> My
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 10 Jun 2009 13:42:33 +0900

Hello,

> version of draft-ietf-dime-erp. 
Thank you for the clarification. That was my intention, but I realize
now that my initial mail was very misleading. Sorry for the confusion!

Best regards,
Sebastien.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 11 Jun 2009 11:22:52 +0300

Hi Tina, 
 
thanks for the support regarding the Diameter ERP work. 
I hope the excitement for it will also result in some running code that
would help us to make the design decisions in a better fashion. 

When I was talking to Sebastien recently we were wondering whether there
is HOKEY ERP code available somewhere since this is a pre-requisite for
the implementation of the Diameter ERP stuff. 

Ciao
Hannes

	From: ext Tina TSOU [mailto:[email-masked]] 
	Sent: 10 June, 2009 07:23
	To: Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: ext Julien Bournelle; Sebastien Decugis; [email-masked];
[email-masked]
	Subject: Re: [HOKEY] [Dime] New draft for Diameter ERP: poll for
adoption

	Hi Hannes,
	Thank you for your clarification. It is much clearer.
	This change should be made, since ERP is one of the most
important applications for Diameter.

eak-word; -webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; "> 
					B. R.
	Tina
	IPTIME - Unified QoS ARchitecture (UQAr) [ju'ka:] /pronounced
like "you"+"car"/
	[email-masked]
	http://uqar.weebly.com

	

	On Jun 9, 2009, at 4:46 PM, Tschofenig, Hannes (NSN - FI/Espoo)
wrote:

		Hi all, 

		We have a working group document with agreed authors. 
		The only question therefore is what the group wants to
go into the
		existing document - the content. No new document will be
added to the
		DIME milestones.
		
		What Sebastien should be asking the group is whether the
content in
		draft-sdecugis-dime-diameter-erp-01.txt should be
included in the next
		version of draft-ietf-dime-erp. 
		
		I personally think that draft-ietf-dime-erp-01 could
have included the
		updated text already since we discussed it on the list.
Anyway, ... 
		
		In any case, it is good to ask the group whether this
significant change
		s answer: I believe that this is the right direction, as
I indicated
		previously on the list. 
		
		Ciao
		Hannes

		
		
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of ext Julien Bournelle
		Sent: 09 June, 2009 10:02
		To: Sebastien Decugis
		Cc: [email-masked]; [email-masked]
		Subject: Re: [Dime] New draft for Diameter ERP: poll for
		adoption

		Hello,
		
		See inline,

		
		I have gone forward on the >created a new draft

		
		AFAIK, this is not how things are working at IETF. The
WG has
		already a WG document called draf ich is
		supposed to reflect the current WG consensus. We can't
arrive with a new
		individual submission and just bypass the current WG
I-D. At least, I
		never saw that.
		
		Having said that, we have an issue with the current WG
document
		concerning use of a new Application-ID or reuse of the
Diameter EAP. My
		understanding was that we were a little blocked because
of an
		architectural issue concerning the HOKEY server in
regards to AAA/EAP
		server and because of a routing issue. So I'd like to
know what has
		changed from this point.
		
		Note that I'm not against your proposal per se. We just
have to
		get a consensus.

		Julien

		
		
		[1]

		

		______________________
		HOKEY mailing list
		[email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jun 2009 22:21:35 +0700

Tschofenig, Hannes (NSN - FI/Espoo) [mailto://[email-masked]]

> version of draft-ietf-dime-erp.

Yes.

> updated text already since we discussed it on the list. Anyway, ...

Yes.

> My answer: I believe that this is the right direction, as I indicated

A quick review and comparison with the WG draft suggests to me that the new
doc is an improvement.

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Jun 2009 17:43:10 +0800

> version of draft-ietf-dime-erp. 

[Qin]: I support incorporating Sebastien's changes into next version of draft-ietf-dime-erp.

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 17 Jun 2009 15:18:31 +0200

Hello all,

please find my comments inline (draft is quoted with ">"),

On Wed, Jun 17, 2009 at 2:37 PM, Julien Bournelle <
[email-masked]> wrote:

> 1.  Introduction
>
>   [RFC5296] defines the EAP Re-authentication Protocol (ERP) and
>   mechanism that consists in the two following steps:
>
>   1.  Bootstrapping: creation of a root key for re-authentication,
>       after initial EAP authentication of the peer.  This root key is
>       distributed from the EAP server to the ER server.  How this key
>       is tranported is not specified in the ERP mechanism.
>
>   2.  Re-authentication: one-round-trip exchange between the peer and
>       the ER server, functionally equivalent to a full EAP
>       authentication.
>
>   This document specifies how Diameter is used to carry the re-
>   authentication exchange (second step).  For this purpose, we define a
>   new Application Id for ERP, and re-use the Diameter EAP commands
>   (DER/DEA).

We need a justification here.

>
>   We also discuss the key distribution (first step, bootstrapping) and
>   propose some solutions for different architectures.  Anyway,
>   implementors are free to choose a different mechanism for key
>   distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm].

 Rafa sent an email on this draft and I agree with him i.e. the draft should

not mention RADIUS, only AAA.

>   Security considerations for key distribution are explained in
>   [RFC5295].
>
> 1.1.  Differences with other documents
>
>   This document differs from [I-D.ietf-dime-erp] in its design and
>   scope.  In this new version, we use a new Diameter application id for
>   messages with ERP payload exchanged between authenticator and ER
>   server.  This simplifies the routing of Diameter messages to the
>   appropriate server, and allows more flexibility in the deployment of
>   ERP.

 in which scenario does it simplify the routing process ? in case of HO to a
new authenticator ?
 If this is the case, I don't really understand how it solves the problem
because we may have deployed
2 ERPs servers.

>
>   The scope of previous documents ([I-D.ietf-dime-erp] and
>   [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the
>   mechanism.

 this is not really true. The goal of our document was to define how to use
Diameter
for ERP for bootstrapping and reauthentication.

>  In particular, these documents did not consider the
>   routing of Diameter message for re-authentication exchanges (ERP
>   exchange, and also [RFC4187] for the second document).  By re-using
>   the Diameter EAP application, they create implicit constraints on
>   routing of messages that cannot be met by standard Diameter routing
>   algorithm, as defined in the Diameter Base Protocol [RFC3588].
>
>   A separate Diameter application solves this routing issue, and can
>   also allow the authenticator to dynamically discover if the local
>   domain supports re-authentication or not.

 I think that it is important to highlight what was the issue and how the
Application-Id solve it. I don't think that we can go in this new direction
without a clear understanding of the issue and of course of the proposed
solution.

 So, could you send an email explaining the Issue and the proposed solution
?

>
>
>
>
> Decugis                 Expires December 10, 2009               [Page 3]
>
> Internet-Draft            Diameter ERP support                 June 2009
>
>
> 2.  Terminology
>
>   We re-use in this document the terminology from [RFC5296].  In
>   particular, unless specified otherwise, the EAP server has implicit
>   support for ERP extensions for generation of ERP keying material and
>   its transmission to ER server.  These terms "authenticator", "ER
>   server", "EAP server" designate logical functional entities and make
>   no assumption on the real implementation and deployment.
>
>   "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
>   derived from an EMSK, depending on the location of the ER server in
>   home or foreign domain.
>
>   We re-use also some terminology and abbreviations from [RFC4072], for
>   example DER/DEA.
>
> 2.1.  Requirements Language
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
> 3.  Overview
>
>   During the lifetime of an EMSK (derived during a full EAP
>   authentication by compatible EAP methods), a peer may attach to
>   several authenticators.  In this case, re-authentication is more
>   efficient than full authentication, especially in the case of
>   roaming.  ERP provides a mechanism for re-authentication independent
>   of the link layer, so it can be used in case of multihoming or
>   handovers between different access technologies.  The following
>   figure shows the components involved in ERP, and their interactions.
>   When the peer attaches to a new authenticator, the ER server involved
>   in the transaction may change, for example in the case of inter-
>   domain roaming.  The home EAP server is assumed to be constant for a
>   given peer.
>
>                           Diameter                    +--------+
>           +-------------+   ERP   +-----------+  (*)  |  Home  |
>   Peer <->|Authenticator|<=======>| ER server | <---> |  EAP   |
>           +-------------+         +-----------+       | server |
>                                                       +--------+
>       (*) Several protocols can be used between ER server and
>          home EAP server to transport bootstrapping material.
>
>        Figure 1. Diameter applications used in the ERP mechanism.
>
>   The ER server may be located in the home domain (same as EAP server)
>
>
>
> Decugis                 Expires December 10, 2009               [Page 4]
>
> Internet-Draft            Diameter ERP support                 June 2009
>
>
>   or the visited domain (same as authenticator, when it differs from
>   the home domain).  [[Editor1: Can the ER server be located in a third
>   domain (ex: broker's)?]]

 Editor1: I don't think that we should consider this.

>
>   The bootstrapping of the ER server has to occur sometime between the
>   initial EAP authentication and the first ERP re-authentication with
>   this ER server.  See section Section 7 for detail on this process.
>   Then, the peer re-authenticates, for example after a movement that
>   makes it attach to a new authenticator.  The following figure
>   describes this re-authentication, and shows how Diameter is used in
>   this context.  See section Section 8 for a detailed description, and
>   following sections for details on the Diameter messages format.
>
>                                                        ER server
>                                                      (bootstrapped)
>  Peer                 Authenticator               (local or home domain)
>  ====                 =============               ======================
>  [ <------------------------         ]
>  [optional EAP-Initiate/Re-auth-start]
>
>   ----------------------->
>     EAP-Initiate/Re-auth
>                           ==================================>
>                                Diameter ERP, cmd code DER
>                                  User-Name: Keyname-NAI
>                              EAP-Payload: EAP-Initiate/Re-auth
>
>                           <==================================
>                                Diameter ERP, cmd code DEA
>                              EAP-Payload: EAP-Finish/Re-auth
>                               EAP-Master-Session-Key: rMSK
>    <----------------------
>      EAP-Finish/Re-auth
>
>                     Figure 2. Diameter ERP exchange.

 Just wondering: what happens with the originial AAA/EAP server which is
supposed to handle in particular lifetime session ? Do we need to inform
him of the HO ? what happens to its AAA session with the first authenticator
?

 and that's all for the moment.

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 23 Jun 2009 17:33:13 +0900

Hello Julien,

Please find my answers inline.

> We need a justification here.
Do you mean a justification for defining a new application ID?

> not mention RADIUS, only AAA.
I also agree with this proposed change.
If the referenced draft is updated, then this sentence will have to be
rewritten accordingly, for example as:
"We also discuss the key distribution (first step, bootstrapping) and
propose some solutions for different architectures, following the
principles of [I-D.ietf-hokey-key-mgm]. Anyway,
implementors are free to choose a different mechanism for key
distribution."

Of course, we might choose to restrict the choice on the key
distribution mechanism if people think it is better.

> >   This simplifies the routing of Diameter messages to the
>  in which scenario does it simplify the routing process ? in case of
> HO to a new authenticator ?
>  If this is the case, I don't really understand how it solves the
> problem because we may have deployed
> 2 ERPs servers.
It was presented during Virtual Interim meeting last February. You can
still find the slides there:
http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf
The advantages of a separate Diameter application ID are highlighted in
slide #8.

>  this is not really true. The goal of our document was to define how
> to use Diameter
That is right, and I simplified too much the phrasing in the new draft,
sorry. The general guidelines are exposed in the "Protocol overview"
section. Anyway, there is no consideration about the message routing and
Diameter deployment. This is what I wanted to express. For example,
after a first re-authentication, the message is sent with local
Destination-Realm and EAP application, but it must reach the ER local
server. I know that this was in the scope of the document (and in the
todo-list), but it was just missing in the current version.

Anyway, if this new design for Diameter ERP is to be accepted, this
section would disappear when the document becomes the WG document.

>  So, could you send an email explaining the Issue and the proposed
> solution ?
Do the slides of the Interim meeting answer your questions? Otherwise, I
can try to re-summarize all the discussion in a new mail if needed. I
thought that the routing issue was already accepted, but I realize now
that it does not seem to be the case...
Do you think this discussion should be written in the draft? I was not
sure if the RFC(-to-be) is a right place for design discussions...

Best regards,
Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 23 Jun 2009 18:35:48 +0200

Hello,

 Response inline

> Do you mean a justification for defining a new application ID?

 yes

> The advantages of a separate Diameter application ID are highlighted in

 ok, so I guess we are talking about the routing issue in case of a
handover.

 Then, I still don't see what a new application id solves here. If I have
multiple ERP servers in the visited or home, how does the target
authenticator knows to which ERP servers it shall send its request ??

> section would disappear when the document becomes the WG document.

ok

> Do the slides of the Interim meeting answer your questions?

Unfortunately not totally.

> Otherwise, I

I guess we all agree that we have a routing issue. But it could be good to
summarize
clearly the routing issue in case of ERP. And then to explain how
Application-Id solves it.

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 23 Jun 2009 18:41:01 +0200

Hello,

 What about the end of my previous mail (see below) ???

On Wed, Jun 17, 2009 at 3:18 PM, Julien Bournelle <
[email-masked]> wrote:

> him of the HO ? what happens to its AAA session with the first
> authenticator ?
>

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Jun 2009 13:41:25 +0900

Hello,

>  What about the end of my previous mail (see below) ???
Oops sorry I missed that part. I'll answer this now.

>     him of the HO ? what happens to its AAA session with the first
I am not sure of the impact of the handover on the EAP server.
Basically, I think it doesn't have any, at least on the authentication
side. In my understanding, the EAP server function is to (mutually)
authenticate a peer/user and provide a lifetime to this authentication.
When ERP is used, it allows the peer/user to change attachment point to
the network and still use this (mutual) authentication "token" while its
lifetime is not expired. Since the lifetime is not extended, the EAP
server does not need to know the movement in my opinion.
The impact of ERP on the authorization has to be studied. The EAP server
implicitly authorizes ERP (and therefore the peer movement) when
deriving an rRK / rDSRK (for a given domain) and providing it to the ER
server. If you need more granularity for the authorization than the
domain scale, then additional measures have to be taken, but I don't
think this is required in this document. Do you think otherwise?
The impact of ERP and movement on the accounting is the most problematic
in my opinion. I have put my ideas in the section 9 of the draft, for
open discussion and resolution. I don't have the appropriate background
to understand fully the needs of accounting, so I am wanting to hear
more experienced peoples thoughts. I did not check yet how it is handled
in case of IP mobility, but maybe we can use similar mechanism?

As for session(s) termination(s), I did not study how each AAA component
should behave in case of movement. For example, when the peer leaves
NAS1 to attach to NAS2, does NAS1 send a STR? This must be studied and
detailed in the document (this is independent of the choice of
application id for ERP).

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Jun 2009 14:07:53 +0900

Hi again,

>     Do you mean a justification for defining a new application ID?
Ok. It can be added in a future version of the document.
 
>  ok, so I guess we are talking about the routing issue in case of a
This is the main reason for this proposed change, but there may be other
advantages (possibility to detect if ERP is supported during the CER/CEA
exchange, for example).

>  Then, I still don't see what a new application id solves here. If I
> have multiple ERP servers in the visited or home, how does the target
I don't think there is an issue here. The question should be asked in
the HOKEY group, since it's an ERP concern, not Diameter, AFAICT.

> Unfortunately not totally.

If you use EAP application id, your local ERP Diameter proxy have to be
on the path of all EAP messages for both local and foreign realms coming
from a NAS in the local domain, and also all EAP messages coming from
other realms to the local EAP server. I think this requirement is very
difficult to achieve, and leads to a huge load of this proxy.
By having a different application ID, you can configure the routing
differently for ERP messages and for "normal" EAP messages. This
provides more flexibility in the deployment, which is always a good
thing IMHO.
I can't think of any inconvenient of having a separate application ID
for ERP compared to reusing the EAP application ID.  In any case the
support for ERP cannot be added "transparently" since ERP requires
modifications of the EAP server and the NAS (regardless of Diameter).
 
> I guess we all agree that we have a routing issue. But it could be
> good to summarize
Do you think this should be put in the document, or discussed on this
mailing-list (or both) ?

Best regards,
Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 24 Jun 2009 18:13:13 +0200

Hello,

 see inline.

> server does not need to know the movement in my opinion.

Let's make it simple:
The home AAA/EAP server must know to which NAS the UE is currently attached.
That's my issue.

 Regards,

 julien

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 24 Jun 2009 18:18:51 +0200

Hello,

 inline

On Wed, Jun 24, 2009 at 7:07 AM, Sebastien Decugis <[email-masked]>wrote:

> <snip>

hmm, that is the issue. The local ERP server has the keying material. The
target NAS must know the local ERP server to contact. This is exactly the
same issue with or w/o an Application-ID in my view.

> difficult to achieve, and leads to a huge load of this proxy.

for a Diameter Session (let's say during the EAP authentication), the local
NAS will use a Diameter Proxy and the Diameter proxy will use the home
Diameter server. We are not going to change the AAA path during the session.

Am I missing something ?

> modifications of the EAP server and the NAS (regardless of Diameter).

I don't see what it solves for our issue. I'd be glad to hear other
opinions.

> Do you think this should be put in the document, or discussed on this

At least on the ML.

Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 25 Jun 2009 11:19:40 +0900

>     If I
> hmm, that is the issue. The local ERP server has the keying material.
> The target NAS must know the local ERP server to contact. This is
> exactly the same issue with or w/o an Application-ID in my view.
To me, it's just a routing configuration, I still don't see the issue,
sorry...
If you want to have several ERP servers in the home domain, I guess
you'd have to keep the key cache in sync, or share a database, or some
similar mechanism. As I wrote, this is a question for HOKEY (i.e. it
concerns ERP), not Diameter.

> for a Diameter Session (let's say during the EAP authentication), the
> local NAS will use a Diameter Proxy and the Diameter proxy will use
> the home Diameter server. We are not going to change the AAA path
> during the session.
Nothing guarantees that the path does not change, AFAIK. Anyway, this is
not really the problem.
The ER server in local domain must be on the path of the following
exchanges if you use the EAP application ID:
 -> first and last row of full EAP exchange of a visiting peer, if you
use implicit bootstrapping
(username: user@home, dest-realm: home)
-> Re-authentication with bootstrapping, if you use explicit
bootstrapping (better IMHO, as it provides ERP only to peers that really
use it):
(username: keyname@home, dest-realm: home)
-> Simple re-authentication:
(username: keyname@local, dest-realm: local)
-> local peers visiting a foreign network:
(username: user@local, dest-realm: local).

Basically, all messages with EAP application ID to or from the local
domain would have to go through this proxy. I doubt the scalability of
such design.

With a separate application ID for ERP, only re-authentication exchanges
would reach the proxy, which unloads it a lot. (I assume that
re-authentications are far less frequent than full authentications)

> I'd be glad to hear other opinions.
Me too :)

Thanks,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 25 Jun 2009 11:21:42 +0900

> Let's make it simple:
> The home AAA/EAP server must know to which NAS the UE is currently
> attached. That's my issue.
Do you mean at any time during the lifetime of the authentication? Why
would it need to know this?

Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 25 Jun 2009 05:28:11 +0200

Hello,

> re-authentications are far less frequent than full authentications)

I still don't see the difference between requiring the same AAA/EAP proxy on
the path (if Diameter EAP Application) and requiring that the new NAS
contact the same local ERP server that was in the initial path (Diameter
ERP).

 Regards,

 Julien