Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jan 2008 23:00:51 +0100

Narayanan, Vidya wrote:
> Thanks for the review.  Let me attempt to clarify a few things that may
> answer majority of your questions below.  The DSRK is a domain specific
> root key that is derived from the EMSK for the purpose of having a local
> EAP Re-authentication server (ER server) in the visited domain.

  I'm not sure I understand why.  If there isn't an EAP
re-authentication server, then the EAP authentications will go through
the local AAA server.  So there is significant benefit in *always* going
through the local AAA server.  i.e. having the AAA servers cache the
keys required for re-authentication.

> "Visited domain" doesn't necessarily imply administrative in this case -
> a large domain can be broken up into multiple smaller domains for sake
> of efficient re-authentication.  

  I'm not sure I understand how this helps efficiency.  If there's one
large domain for the initial authentication, then only one domain is
needed.  If the home server can handle the re-authentication, then
there's doubly no need for multiple domains.

> This is done so that the latency involved in reauthentication at the
> time of a handoff for a peer is minimal (the peer doesn't have to go
> back to the home AAA server to get reauthenticated).  When the peer
> hands off across domains (i.e., leaves the boundary of an ER server), it
> needs to communicate with the home AAA server to obtain a new DSRK for
> the new ER server.  This may be done using a full EAP exchange or with
> an ER exchange with the home AAA server.  

  If the re-authentication has to go back to the home AAA server for a
to obtain a new DSRK, why are there multiple domains?  The home server
is manifestly capable of handling all re-authentication requests.

> The problem statement and use cases are described further in
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
> The ERX protocol draft itself describes the protocol in detail -
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt -
> figure 2, for instance, shows the recipient of the DSRK and how it is
> further used for reauthentication during authenticator changes within
> that domain.  

  I think I need to address many of my comments to that draft.

> Hope this clarifies many of the things you ask below.  A few further
> comments inline on the other questions. 

  It clarifies it a little.  I've gone over the problem statement draft,
and have some questions about it.

> Actually, this document has gone through a couple of contortions due to
> lack of clarity from the RADIUS side on how to proceed here.

  The radext WG is always available to answer questions.  I've been
lurking on hokey for a while, but until recently have been too busy to
pay much attention to the drafts.

> There will only be one key response, but the key name is still needed so
> that the peer, upon reauthentication later, can refer to the key.

  Ok... I have questions, but I'll address them to another draft, I think.

> As I mentioned before, there is no goal to change the RADIUS security
> measures.  This draft will also be updated to work with keywrap and DTLS

  I don't believe either method is strictly necessary for transporting
these keys.  There are alternatives that should be able to work.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 3 Jan 2008 15:02:22 -0800

Hi Alan,
Some of this is revisiting the HOKEY charter discussions and can be
found in the archives, but let me try a bit further to clarify here. 

Consider the following figure: 

                                   -----------
                                  | AAA-Home  |
                                   -----------
                                        |
                ------------------------------------------------------
               |                                                      |
       -------------------
-------------------
      | Local ER server A |                                 | Local ER
server B |
      |    (Domain A)     |                                 |    (Domain
B)     |
       -------------------
-------------------
               |                                                      |
          --------------
--------------
         |              |                                       |
|
     --------        --------                                --------
--------
    | NAS A1 |      | NAS A2 |                              | NAS B1 |
| NAS B2 |
     --------        --------                                --------
--------

    ------
   | Peer |  ---------->
    ------

In the figure above, the peer is attached to a NAS (say, A1) in Domain
A, while its home domain corresponds to AAA-Home" which is potentially
much further away than Domain A is.  The first time around, the peer
authenticates with its home AAA server, which results in an MSK at NAS
A1 and an EMSK at AAA-Home.  This is in accordance with regular EAP
operation.  When the peer, the local domain and the AAA-Home also
support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
the time of the EAP exchange.  DSRK1 is derived from the EMSK and given
to the Local ER Server A.  Now, when the peer moves from NAS A1 to NAS
A2, it only needs to perform an ERP exchange with the Local ER Server A.
No exchange is required with AAA-Home.  This finishes much quicker than
an exchange that would have to go all the way to AAA-Home.  

It is when the peer moves from Domain A to Domain B that the peer has to
talk to AAA-Home again.  At this point, a DSRK2 may be given to Local ER
Server B, which then gets used for re-authentication within that domain
(say, when the peer moves from NAS B1 to NAS B2).  

As shown, all re-authentications within a local domain are restricted to
that domain with no exchanges needed with the home domain (unless the
DSRK expired).  Exchanges involve the home domain when the peer crosses
domain boundaries.  

Hope this helps.  

Thanks,
Vidya

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, January 03, 2008 2:01 PM
> To: Narayanan, Vidya
> Cc: [email-masked]; 'radext mailing list'
> Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
> 
> Narayanan, Vidya wrote:
> > Thanks for the review.  Let me attempt to clarify a few things that 
> > may answer majority of your questions below.  The DSRK is a domain 
> > specific root key that is derived from the EMSK for the purpose of 
> > having a local EAP Re-authentication server (ER server) in 
> the visited domain.
> 
> re-authentication server, then the EAP authentications will 
> go through the local AAA server.  So there is significant 
> benefit in *always* going through the local AAA server.  i.e. 
> having the AAA servers cache the keys required for re-authentication.
> 
> > "Visited domain" doesn't necessarily imply administrative 
> in this case 
> > - a large domain can be broken up into multiple smaller domains for 
> > sake of efficient re-authentication.
> 
>   I'm not sure I understand how this helps efficiency.  If 
> there's one large domain for the initial authentication, then 
> only one domain is needed.  If the home server can handle the 
> re-authentication, then there's doubly no need for multiple domains.
> 
> > hands off across domains (i.e., leaves the boundary of an 
> ER server), 
> > it needs to communicate with the home AAA server to obtain 
> a new DSRK 
> > for the new ER server.  This may be done using a full EAP 
> exchange or 
> > with an ER exchange with the home AAA server.
> 
>   If the re-authentication has to go back to the home AAA 
> server for a to obtain a new DSRK, why are there multiple 
> domains?  The home server is manifestly capable of handling 
> all re-authentication requests.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt 
> > - figure 2, for instance, shows the recipient of the DSRK 
> and how it 
> > is further used for reauthentication during authenticator changes 
> > within that domain.
> 
>   It clarifies it a little.  I've gone over the problem 
> statement draft, and have some questions about it.
> 
> > Actually, this document has gone through a couple of 
> contortions due 
> > to lack of clarity from the RADIUS side on how to proceed here.
> 
>   The radext WG is always available to answer questions.  
> I've been lurking on hokey for a while, but until recently 
> have been too busy to pay much attention to the drafts.
> 
> > There will only be one key response, but the key name is 
> still needed 
> > so that the peer, upon reauthentication later, can refer to the key.
> 
>   I don't believe either method is strictly necessary for 
> transporting these keys.  There are alternatives that should 
> be able to work.
> 
>   Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2008 00:05:18 +0100

> found in the archives, but let me try a bit further to clarify here. 

  I don't want to re-visit the charter.  I think there may be more than
one way to achieve the goals.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Jan 2008 16:33:05 -0800 (PST)

Hi Vidya,

  There may be proxies in between AAA-Home and Local ER server A
and between AAA-Home and Local ER Server B. There is strong consensus
in the group that there is no problem with this that all the proxies
will behave themselves and not abuse the fact that they know DRSK1
and/or DRSK2. That being the case why cannot the same logic that justifies
these proxies having such keying material be used to just give the
same key to Local ER Server A and Local ER Server B? Why do we need
to have different DRSKs? What problem are you trying to solve and isn't
that problem still going to be there since proxies are now involved?

  Dan.

On Thu, January 3, 2008 3:02 pm, Narayanan, Vidya wrote:
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 3 Jan 2008 22:20:38 -0800

Hi Dan,
There are two points here.  End-to-end protection of key material is
certainly feasible and is not prohibited by the model - it is quite
feasible in the enterprise space, for instance.  Even when hop-by-hop
protected, the proxies don't have authorization to use the DSRK.  It is
only meant for use by the local ER server.  

For key separation, it is important to have different DSRKs per domain.
For instance, there must be separation between the rMSKs given to the
different NASs - if the same DSRK was given to multiple local ER
servers, you would end up with the same rMSK for multiple NASs.  We
could come up with other key separation techniques that keep the rMSK
unique, but that would mean introducing the domain or an equivalent
differentiation at that level instead of at the DSRK.  

Also, another point is that Domain A and Domain B may actually be
different administrative domains, in which case, it is not necessarily
true that they have a business relationship with each other or that they
have the same level of relationship with the home domain.  So, there is
no assumption that any one visited domain is a proxy in the path between
another visited domain and the home domain.  Hence, ensuring proper key
separation at the DSRK level is important. 

Regards,
Vidya

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Thursday, January 03, 2008 4:33 PM
> To: Narayanan, Vidya
> Cc: Alan DeKok; radext mailing list; [email-masked]
> Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
> 
> 
>   Hi Vidya,
> 
>   There may be proxies in between AAA-Home and Local ER 
> server A and between AAA-Home and Local ER Server B. There is 
> strong consensus in the group that there is no problem with 
> this that all the proxies will behave themselves and not 
> abuse the fact that they know DRSK1 and/or DRSK2. That being 
> the case why cannot the same logic that justifies these 
> proxies having such keying material be used to just give the 
> same key to Local ER Server A and Local ER Server B? Why do 
> we need to have different DRSKs? What problem are you trying 
> to solve and isn't that problem still going to be there since 
> proxies are now involved?
> 
>   Dan.
> 
> >       |    (Domain A)     |                                 
> |    (Domain
> > support ERP, a DSRK (DSRK1) may be requested by the local 
> ER server A 
> > at the time of the EAP exchange.  DSRK1 is derived from the 
> EMSK and 
> > given to the Local ER Server A.  Now, when the peer moves 
> from NAS A1 
> > to NAS A2, it only needs to perform an ERP exchange with 
> the Local ER Server A.
> > No exchange is required with AAA-Home.  This finishes much quicker 
> > than an exchange that would have to go all the way to AAA-Home.
> >
> > It is when the peer moves from Domain A to Domain B that 
> the peer has 
> > to talk to AAA-Home again.  At this point, a DSRK2 may be given to 
> > Local ER Server B, which then gets used for 
> re-authentication within 
> > that domain (say, when the peer moves from NAS B1 to NAS B2).
> >
> > As shown, all re-authentications within a local domain are 
> restricted 
> > to that domain with no exchanges needed with the home 
> domain (unless 
> > the DSRK expired).  Exchanges involve the home domain when the peer 
> > crosses domain boundaries.
> >
> > Hope this helps.
> >
> > Thanks,
> > Vidya
> >
> >> re-authentication server, then the EAP authentications will go 
> >> through the local AAA server.  So there is significant benefit in 
> >> *always* going through the local AAA server.  i.e.
> >>   I'm not sure I understand how this helps efficiency.  If there's 
> >> one large domain for the initial authentication, then only 
> one domain 
> >> is needed.  If the home server can handle the 
> re-authentication, then 
> server for 
> >> a to obtain a new DSRK, why are there multiple domains?  The home 
> >> server is manifestly capable of handling all re-authentication 
> >> requests.
> >>
> >>   It clarifies it a little.  I've gone over the problem statement 
> >> draft, and have some questions about it.
> >>
> have been 
> >> too busy to pay much attention to the drafts.
> >>
> >>   Ok... I have questions, but I'll address them to another 
> draft, I 
> >> think.
> >>
> >> > measures.  This draft will also be updated to work with 
> keywrap and 
> >> > DTLS
> >>
> >> transporting these keys.  There are alternatives that 
> should be able 
> >> to work.
> >>
> >>   Alan DeKok.
> >>
> >

---

From: <[email-masked]>
Date: Fri, 4 Jan 2008 00:10:35 -0800

>When the peer, the local domain and the AAA-Home also
> the time of the EAP exchange.

Some questions:

1. Is the  "Local ER server" always a RADIUS client?   The ERX document 
seems to
indicate that this might not always be the case.

2.  How is the request for the DSRK made by the "local ER server"?    Is the
request authenticated with user credentials?  How does the RADIUS server
determine if the Request is valid?

3. How does the RADIUS server know how to reach the "Local ER server"?
The ERX document talks about a "Domain Identity".  How does the RADIUS 
server
use the "Domain Identity" to determine what RADIUS client to send a packet 
to?
Is there an assumption that the "Local ER server" is one hop away from the
home RADIUS server?  What attributes need to be placed within an 
Access-Accept
to ensure that the packet is routed to the "local server"?

4.  In Figure 1, the ERX document shows the following flow:

    [<-- EAP-Request/ ------
        Identity]
    [<-- EAP Initiate/ ------
        Reauth-Start]

Is this a typo?  The figure shows that the EAP-Request/Identity isn't being 
responded
to by the peer.  If the peer implements RFC 3748, won't it send an 
EAP-Response,
which will be passed to the RADIUS server, which will then initiate EAP? 
Figure 1
seems to show the EAP peer ignoring the EAP-Request, which
implies that it needs to wait for some period of time for another message, 
which
might or might not arrive.   How long should it wait?

If the peer doesn't respond to the EAP-Request/Identity, according to RFC 
3748
and RFC 4137, the NAS will retransmit.  So we'll have two EAP conversations
going on at once?

5. In Figure 2,  the peer is initiating what would appear to be a standard
RADIUS/EAP conversation via the EAP-Response/Identity.   However, it
would appear that the EAP Response/Identity is being "augmented" by
the local server.  It's hard for me to tell from the figure whether the
[DSRK Req, Domain Identity] is being inserted within the 
EAP-Response/Identity,
or whether it represents separate RADIUS attributes.  Can you clarify?

6. If the "local 'server" isn't on the path between the NAS and the home 
server
(as it might not be, because of failover), what happens?   Does each proxy
also need to host a "local server" to make sure that doesn't occur?
If the "local server" is not on the path, then it seems like two distinct 
messages
would be required.   Is there an expectation that the RADIUS Access-Accept
will be multicast, or that two distinct RADIUS Access-Accept packets will
be sent?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Jan 2008 11:56:35 +0100

Working on
http://tools.ietf.org/wg/dime/draft-dondeti-dime-erp-diameter-01.txt
the question of defining AVPs vs. defining a new Diameter application 
showed up.

I wrote a section about this into that draft and I wonder whether my 
assumptions are reasonable:

3.  Assumptions

   This document defines additional optional AVPs for usage with the
   Diameter EAP application.  Routing of these messages is therefore
   provided via the Diameter Application Identifier (among other
   elements), as specified by the Diameter Base protocol [4].  Based on
   the deployment of ERP, a local Diameter server (the same entity
   serves as a Diameter proxy during the full EAP authentication) may
   play the role of the ER server for future re-authentication attempts.
   As such, the local Diameter server requesting the DSRK needs to be in
   the path of the current EAP exchange between the peer and the EAP
   server and also along the path in the future.  The Diameter client is 
   furthermore assumed to be able to route the re-authentication 
   messages to the ER server.

Depending on some of the answers to the questions raised in this 
discussion it might be necessary to define a new Diameter application 
rather than just defining new AVPs.

Ciao
Hannes

[email-masked] wrote:
> 1. Is the  "Local ER server" always a RADIUS client?   The ERX 
> document seems to
> use the "Domain Identity" to determine what RADIUS client to send a 
> packet to?
> Is this a typo?  The figure shows that the EAP-Request/Identity isn't 
> being responded
> which will be passed to the RADIUS server, which will then initiate 
> EAP? Figure 1
> implies that it needs to wait for some period of time for another 
> message, which
> If the peer doesn't respond to the EAP-Request/Identity, according to 
> RFC 3748
> 6. If the "local 'server" isn't on the path between the NAS and the 
> home server
> If the "local server" is not on the path, then it seems like two 
> distinct messages

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 4 Jan 2008 07:55:06 -0800 (PST)

Hi Vidya,

  Thank you very much for responding.

> only meant for use by the local ER server.

  I understand that it is "not prohibited" but it is not mandatory and
therefore when looking at the security of the scheme we have to operate
under the assumption that the key is being exposed to parties that are
the intended recipient.

  This non-authorization isn't enforced anyway is it? It is merely by
fiat in the document that the proxies are not authorized to use the key.
We're just assuming that they won't misbehave.

> differentiation at that level instead of at the DSRK.

  You could only end up with the same rMSK being used for multiple NASs
if the sequence number the peer used during re-auth was the same. So if
that is deemed a problem then mandate that the sequence number be a
monotonically increasing counter which is initialized to 1 when the peer
finishes initial and full EAP authentication and not when a new rRK is
derived. No need for any domain differentiation at any level, just a
simple edit of half a sentence in the ERX document.

  If this is the only problem that is solved by having this key hierarchy
then let's do the simple edit I propose and get rid of the key hierarchy!
Agreed?

> separation at the DSRK level is important.

  Yes, Domain A and Domain B may actually be different administrative
domains! And the proxies between them and the home server might be too!
And they all might have different business relationships with each other!
That's my point!

  We're just placing blind trust in proxies to "do the right thing".
That being the case the level of blind trust placed in ER servers in
Domain A or Domain B CANNOT be any less than the level of blind trust
placed in proxies between them and the home AAA server.

  Again, what _specific problem_ is being solved by having different keys
in Domain A and Domain B? Do you want to stop NASs in Domain A from
impersonating NASs in Domain B but for some reason you're not concerned
about proxies impersonating Domain A or Domain B in their entirety?

  It seems to me that any problem that requires different keys for ER
Servers in Domain A and Domain B will also require different keys for all
proxies. But we can't do that so we can't really use key separation to
solve the problem, whatever it is.

  Key separation would be important if there was a 3 party protocol between
the home AAA server the ER server and the peer that disclosed a unique
key to the ER server and only the ER server. But there isn't.

  The argument against a 3 party protocol is that the peer doesn't care
to whom the key is disclosed as long as he continues to get service
provided (and there's no surprises in the bill at the end of the month
but that's what legal documents are for). If the network has to disclose
keys to unintended recipients in order to continue to be able to provide
service then have at it, disclose keys!

  What we've ended up with is a network being trusted implicitly to not
misbehave with keys it obtains and a peer that doesn't care as long as
he gets a dial tone. So please tell me what problem is being solved by
having this key hierarchy.

  Thank you again for responding to my post and I would be very grateful
if you could answer my questions above and/or point out the errors in
my logic.

  regards,

  Dan.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jan 2008 08:29:53 -0800

> You could only end up with the same rMSK being used for multiple NASs> if the sequence number the peer used during re-auth was the same. So if> that is deemed a problem then mandate that the sequence number be a> monotonically increasing counter which is initialized to 1 when the peer> finishes initial and full EAP authentication and not when a new rRK is> derived. No need for any domain differentiation at any level, just a> simple edit of half a sentence in the ERX document.> > If this is the only problem that is solved by having this key hierarchy> then let's do the simple edit I propose and get rid of the key hierarchy!> Agreed?
 
My understanding is that this scheme is in use today, requiring only the MSK,
and no changes to the AAA server or new RADIUS attributes.  Only changes to
the peer, authenticator and local server are needed.  As I understand it, the 
AAA server only sees Access-Requests originating from the "local server" 
(e.g. NAS-Identifier = local server), so it just responds with the MSK. 
However, the peer and authenticator do need to be modified to 
negotiate the scheme prior to first use, since the rMSK is now a function 
of the MSK and the counter, so as to ensure that no authenticators 
share the same keying material.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jan 2008 09:20:05 -0800

I think this makes the assumption that every Diameter agent advertising
support for the ERX application understands ERX.  While Diameter auth 
servers do need to understand the application to advertise it, Diameter agents 
may only be able to forward the messages.  
 
This could become an issue if there is an expectation that the "local server"
will process a packet whose NAI realm is not the local realm.  Instead of
processing the packet, the Diameter agent would forward the packet to
the server corresponding to the NAI realm (e.g. the home server). 
 
The issue is that there is no equivalent of the "router alert" option for
AAA. 
 
> Date: Fri, 4 Jan 2008 11:56:35 +0100> From: [email-masked]> To: [email-masked]> CC: [email-masked]; [email-masked]> Subject: AAA Routing with EAP-ER> > Working on> http://tools.ietf.org/wg/dime/draft-dondeti-dime-erp-diameter-01.txt> the question of defining AVPs vs. defining a new Diameter application > showed up.> > I wrote a section about this into that draft and I wonder whether my > assumptions are reasonable:> > 3. Assumptions> > This document defines additional optional AVPs for usage with the> Diameter EAP application. Routing of these messages is therefore> provided via the Diameter Application Identifier (among other> elements), as specified by the Diameter Base protocol [4]. Based on> the deployment of ERP, a local Diameter server (the same entity> serves as a Diameter proxy during the full EAP authentication) may> play the role of the ER server for future re-authentication attempts.> As such, the local Diameter server requesting the DSRK needs to be in> the path of the current EAP exchange between the peer and the EAP> server and also along the path in the future. The Diameter client is > furthermore assumed to be able to route the re-authentication > messages to the ER server.> > > Depending on some of the answers to the questions raised in this > discussion it might be necessary to define a new Diameter application > rather than just defining new AVPs.> > Ciao> Hannes> > > [email-masked] wrote:> >> When the peer, the local domain and the AAA-Home also> >> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at> >> the time of the EAP exchange.> >> > Some questions:> >> > 1. Is the "Local ER server" always a RADIUS client? The ERX > > document seems to> > indicate that this might not always be the case.> >> > 2. How is the request for the DSRK made by the "local ER server"? > > Is the> > request authenticated with user credentials? How does the RADIUS server> > determine if the Request is valid?> >> > 3. How does the RADIUS server know how to reach the "Local ER server"?> > The ERX document talks about a "Domain Identity". How does the RADIUS > > server> > use the "Domain Identity" to determine what RADIUS client to send a > > packet to?> > Is there an assumption that the "Local ER server" is one hop away from > > the> > home RADIUS server? What attributes need to be placed within an > > Access-Accept> > to ensure that the packet is routed to the "local server"?> >> > 4. In Figure 1, the ERX document shows the following flow:> >> > [<-- EAP-Request/ ------> > Identity]> > [<-- EAP Initiate/ ------> > Reauth-Start]> >> > Is this a typo? The figure shows that the EAP-Request/Identity isn't > > being responded> > to by the peer. If the peer implements RFC 3748, won't it send an > > EAP-Response,> > which will be passed to the RADIUS server, which will then initiate > > EAP? Figure 1> > seems to show the EAP peer ignoring the EAP-Request, which> > implies that it needs to wait for some period of time for another > > message, which> > might or might not arrive. How long should it wait?> >> > If the peer doesn't respond to the EAP-Request/Identity, according to > > RFC 3748> > and RFC 4137, the NAS will retransmit. So we'll have two EAP > > conversations> > going on at once?> >> > 5. In Figure 2, the peer is initiating what would appear to be a > > standard> > RADIUS/EAP conversation via the EAP-Response/Identity. However, it> > would appear that the EAP Response/Identity is being "augmented" by> > the local server. It's hard for me to tell from the figure whether the> > [DSRK Req, Domain Identity] is being inserted within the > > EAP-Response/Identity,> > or whether it represents separate RADIUS attributes. Can you clarify?> >> > 6. If the "local 'server" isn't on the path between the NAS and the > > home server> > (as it might not be, because of failover), what happens? Does each > > proxy> > also need to host a "local server" to make sure that doesn't occur?> > If the "local server" is not on the path, then it seems like two > > distinct messages> > would be required. Is there an expectation that the RADIUS > > Access-Accept> > will be multicast, or that two distinct RADIUS Access-Accept packets will> > be sent?> >> >> >> >> >> >> > -- > > to unsubscribe send a message to [email-masked] with> > the word 'unsubscribe' in a single line as the message text body.> > archive: <http://psg.com/lists/radiusext/>>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 4 Jan 2008 11:37:43 -0800 (PST)

Hi Lakshminath,

On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
[snip]
> Hi Dan,
>
> I am trying to understand the direction of the discussion here:
>
> When there is end-to-end security, it appears that we have agreement
> that a key hierarchy is necessary.

  No, that's not what I'm saying.

> When there is hop-by-hop security, you are making the argument that the
> DSRK hierarchy is not necessary and that we can use other techniques to
> make things work.  Isn't it simpler to have the same key hierarchy
> irrespective of the protection policies in the AAA network?  Besides,
> the different DSRKs would allow the peer to help the home network verify
> the accounting information, for instance.

  We have to deal with the system holistically and not dissect it into
parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
to one part or the other. The issue is what is the threat model for the
holistic system?

  If proxies are permitted, and they are, then the problems they introduce
have to be accepted. We have consensus to do that. It is my contention
that the key hierarchy attempts to address those problems that we have
already accepted into our system due to proxies so I feel the key
hierarchy is an unnecessary complexity.

  Of course I may be all wrong. If someone could just tell me exactly
what problem will completely go away by having this key hierarchy I would
greatly appreciate it. Can you tell me?

> We talked about the reasoning for the DSRK hierarchy for a long time and
> achieved consensus.  I understand that you are bringing up these
> questions again with the hop-by-hop security model in mind.

  The goalposts have moved. The discussion about the key hierarchy was
held back when we were still arguing over a 3 party protocol. That was
when disclosure of keys to people who are not the intended recipient
was a problem we were going to address. But I have come to the realization
that the working group is not interested in a protocol that could not work
in the presence of proxies and that the working group now feels that that
problem is not something that needs addressing.

  I believe that the problems that proxies introduce are the same ones that
arise when a key is shared between domains. The key hierarchy addresses the
latter but not the former. Since WG consensus is that the former is not
something that needs addressing I question why the latter needs addressing.

  A counter example would go a long way to justifying the key hierarchy.
Do you have one?

>                                                              Personally,
> I find it instructive to think about the implications of putting trust
> in proxies.  We discussed that in Vancouver and noted that billing
> inconsistencies may be the result.  If an operator is willing to handle
> those through non-protocol means (and that's what many do today), we
> should continue to allow that model of operation.

  I'm not saying we shouldn't allow that model of operation. In fact,
I am acknowledging that the WG has consensus to allow it.

  What I am saying is that by allowing that model of operation we are
agreeing to not address the problems it introduces. And that being the
case the key hierarchy becomes extraneous, an unnecessary complexity
that we should just do away with.

> best wishes for the new year,
> Lakshminath

  Thank you very much! I hope you have a great 2008.

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 4 Jan 2008 19:27:44 -0500

I can see two conflicting types of trust for hop-by-hop security to
work.

Type 1 trust: Trusted entities can use any keys that they have access
to, regardless of how they are distributed.

Type 2 trust: Trusted entities will not use keys distributed to others
even if they have access to the keys.

In Type 1 trust, multiple trusted entities are actually sharing keys
for use, and thus key hierarchy is not needed.  

In Type 2 trust, key hierarchy is still needed.  Also, there is no
Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
to a real-world case where we need to trust how a check-in baggage
will be inspected and treated once it is checked in.  Inspectors have
the right to access to the baggage contents for the purpose of airline
security, but airline customers (need to) trust them that they will
not use the contents.

The issue seems to be which trust model (or something else) is
acceptable for us.  In my personal opinion, Type 2 trust is not
desirable from security perspective, unless AAA proxies really need to
access to the keys to improve AAA secuirty.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 4 Jan 2008 17:24:46 -0800

Hi Bernard,

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, January 04, 2008 12:11 AM
> To: [email-masked]
> Cc: [email-masked]
> support ERP, a 
> >DSRK (DSRK1) may be requested by the local ER server A at  
> the time of 
> >the EAP exchange.
> 
> Some questions:
> 
> 1. Is the  "Local ER server" always a RADIUS client?  

Yes, it is both a client and a server.  It is a client from the
perspective that it requests for the key material from a RADIUS server
and a server from the perspective that it will later serve NASs during
reauthentication. 

> The 
> ERX document 

Could you please point out where?  I just scanned the ERX document and
except for describing a specific security consideration with the use of
RADIUS, the document only seems to have pointers to the RADIUS and
Diameter documents.  Perhaps I missed it.  

> request authenticated with user credentials?  How does the 
> RADIUS server determine if the Request is valid?
> 

The request for DSRK is made with a RADIUS attribute or Diameter AVP in
an ERP bootstrapping exchange initiated by the peer or the first EAP
Response message coming from the peer in a regular EAP exchange.  The
EAP or ERP exchange authenticates the peer and upon successful
authentication, a DSRK is included along with ER Finish or EAP Success
for the local ER server.  This is not much unlike providing the MSK to
the NAS, except that there is no explicit request for an MSK.  

> The ERX document talks about a "Domain Identity".  How does 
> the RADIUS server use the "Domain Identity" to determine what 
> RADIUS client to send a packet to?
> Is there an assumption that the "Local ER server" is one hop 
> away from the home RADIUS server?  What attributes need to be 
> placed within an Access-Accept to ensure that the packet is 
> routed to the "local server"?
> 

The local ER server must be in the path of the full EAP exchange or the
ERP bootstrapping exchange of the peer in order to request and receive a
DSRK.  This text was present in draft-gaonkar-radext-erp-attrs-01 and I
notice that it is missing in 02.  We will fix that.  The packet is
routed just using regular AAA routing - the requesting entity's identity
is part of the attribute defined, which will provide an FQDN or IP
address of the local ER server requesting the key - this is present in
the Access-Accept as well.  The local ER server that requested the DSRK
will look for this attribute in the Access-Accept.  

> Is this a typo?  The figure shows that the 
> EAP-Request/Identity isn't being responded to by the peer.  
> If the peer implements RFC 3748, won't it send an 
> EAP-Response, which will be passed to the RADIUS server, 
> which will then initiate EAP? 

The idea behind sending both EAP-Request/Identity and
EAP-Initiate/Reauth-Start is that the network can initiate regular EAP
or re-authentication when it wants.  A peer that supports ERX and
possesses a valid EMSK should respond only to the
EAP-Initiate/Reauth-Start.  The EAP process may timeout or the
authenticator, upon receiving the EAP-Initiate/Reauth-Start may
terminate EAP.  

> implies that it needs to wait for some period of time for 
> another message, which

Not sure why the peer would wait.. It sees that the authenticator
supports ERX and knows that it possesses a valid EMSK - so, it just
proceeds with the ERP exchange. 

> and RFC 4137, the NAS will retransmit.  So we'll have two EAP 
> conversations going on at once?
> 

As I note above, the authenticator may retransmit the
EAP-Request/Identity, in which case it will timeout or it may terminate
EAP when it receives the EAP-Initiate/Reauth-Start.  A smart
implementation should do the latter.  Even upon retransmission of the
EAP-Request/Identity, there isn't really an issue, since, the identifier
for EAP-Initiate is picked by the peer.  Hence, the EAP code (Initiate),
along with the identifier value, will distinguish this exchange from an
EAP-Request transmitted by the authenticator.  

> would appear that the EAP Response/Identity is being 
> "augmented" by the local server.  It's hard for me to tell 
> from the figure whether the [DSRK Req, Domain Identity] is 
> being inserted within the EAP-Response/Identity, or whether 
> it represents separate RADIUS attributes.  Can you clarify?
> 

It represents separate RADIUS attributes. 

> 6. If the "local 'server" isn't on the path between the NAS 
> and the home server
> If the "local server" is not on the path, then it seems like 
> two distinct messages
> will be multicast, or that two distinct RADIUS Access-Accept 
> packets will be sent?
> 
> 

As written, the protocol only supports the case where the local ER
server is in the path between the NAS and home server.  There was some
interest in later supporting the case where it is not in the path, but
there is no proposal to support that option now. 

Thanks,
Vidya

> 
>  
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 5 Jan 2008 14:13:59 -0500

Lakshminath,

Thank you for the pointer to RFC 4568.

In my reading of RFC 4568, it recommends end-to-end security when the
communication path of the SDP message is routed through intermediate
systems like SIP proxies.  IMO, end-to-end security (with Type 1
trust) should be the default model for any key distribution mechanism
even if hop-by-hop security is not totally prohibited for some use
cases.  

Yoshihiro Ohba

On Fri, Jan 04, 2008 at 04:58:42PM -0800, Lakshminath Dondeti wrote:
> Hi Yoshi,
>
> You are on the right track by exploring the implications of hop-by-hop 
> security.  In the case we are talking about, it may result in billing 
> inconsistencies.  That we have agreed is ok in some cases and perhaps not 
> ok in others.  This is a reasonable conclusion as illustrated elsewhere:  
> In case of SIP proxies, hop-by-hop security implies that proxies may be 
> able to compromise end-to-end user data/media confidentiality.  In this 
> case, end-to-end security may be compromised and we have an assortment of 
> techniques at the IETF to deal with the problem.  The proxy model is 
> allowed however.  There are key distribution mechanisms (RFC 4568) which 
> work with the proxy model in mind.
>
> best wishes for 2008,
> Lakshminath
>
> On 1/4/2008 4:27 PM, Yoshihiro Ohba wrote:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 5 Jan 2008 18:31:05 -0500

Why just not use inter-realm Kerberos to establish an end-to-end SA
between EAP server and DSR-KH, and then do DSRK distribution over the
established SA?  Inter-realm Kerberos works with chain of trust and
should work with the case where AAA proxies are between EAP server and
DSR-KH.  The past proposal about Kerberos over RADIUS indicated by
Bernard sounds like a good solution.

Yoshihiro Ohba

On Sat, Jan 05, 2008 at 11:22:41AM -0800, Lakshminath Dondeti wrote:
> The key however is that there was no real mechanism for end-to-end security 
> that 4568 might recommend and now RAI is in another iteration for key 
> management for SRTP.
>
> Lakshminath
>
> On 1/5/2008 11:13 AM, Yoshihiro Ohba wrote:
>> Lakshminath,
>>
>>>> for use, and thus key hierarchy is not needed.  In Type 2 trust, key 
>>>> hierarchy is still needed.  Also, there is no

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 6 Jan 2008 01:25:35 -0500

Do you mean DTLS-SRTP or something else?  In the former case, I'm not
sure how it works with AAA proxies.

Yoshihiro Ohba

On Sat, Jan 05, 2008 at 06:33:12PM -0800, Lakshminath Dondeti wrote:
> Isn't there a solution on the table already with DTLS proposal?
>
> Lakshminath
>
> On 1/5/2008 3:31 PM, Yoshihiro Ohba wrote:
>>> The key however is that there was no real mechanism for end-to-end 
>>> security that 4568 might recommend and now RAI is in another iteration 
>>> for key management for SRTP.
>>>
>>> Lakshminath
>>>
>>>> cases.  Yoshihiro Ohba
>>>>> inconsistencies.  That we have agreed is ok in some cases and perhaps 
>>>>> not ok in others.  This is a reasonable conclusion as illustrated 
>>>>> elsewhere:  In case of SIP proxies, hop-by-hop security implies that 
>>>>> proxies may be able to compromise end-to-end user data/media 
>>>>> confidentiality.  In this case, end-to-end security may be compromised 
>>>>> and we have an assortment of techniques at the IETF to deal with the 
>>>>> problem.  The proxy model is allowed however.  There are key 
>>>>> distribution mechanisms (RFC 4568) which work with the proxy model in 
>>>>> mind.
>>>>>
>>>>> best wishes for 2008,
>>>>> Lakshminath
>>>>>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 06 Jan 2008 08:08:03 +0100

> Isn't there a solution on the table already with DTLS proposal?

  No.  RADIUS + DTLS is still hop by hop.  There are no provisions in it
for end to end security.

  Alan DeKok.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 Jan 2008 10:43:02 +0200

Hi Bernhard,

Bernard Aboba wrote:
> support for the ERX application understands ERX.
That's not really desirable.

>   While Diameter auth 
Correct.

> will process a packet whose NAI realm is not the local realm.  
Based on my understanding this seems to be the case with EAP-ER.

> Instead of
I know.

It seems that you are saying that a new Diameter application would be 
necessary to accomplish the required functionality in a reasonable way.

Ciao
Hannes