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

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Jan 2008 17:41:13 +0100

I've read the draft, and have a few comments.

   These
   attributes can be used by a visited network entity to request a key
   from the home network and the home domain to deliver the key to the
   visited network entity

  Why is the visited network requesting keys?  Is the user involved in
this request?  Does the user know that the visited network is requesting
keys on his behalf?

  These issues are referenced in the security section.  However, that
section says that channel bindings *may* be necessary.  It looks to me
like they are required to avoid a large class of security / information
leakage.

   The key-request attribute contains the requesting entity's identity
   and the type of the key being requested.

  Why is it necessary to have the requesting entities identity?  Can
multiple servers in a proxy chain make requests at the same time?  If
so, why?  What benefit does this serve?

   The key-response attribute contains the requesting entity's identity,
   the type of the key, the key itself, its length, name and lifetime.

  Are key lifetimes different from user session lifetimes?  RADIUS
already has support for Session-Timeout, which would seem to put an
upper limit on key lifetimes, at least for one session.  Are these keys
to be cached across multiple user sessions?  If so, this document should
say.

[ key request attribute ]

      The Requesting Entity's Identity is to be copied in the
      corresponding Key-Response attribute.

  The following section says that the response MAY include the identity.
   That section then says the identity "is to be included".  The text
should agree with itself.

  The next section says that the identity can be only 192 octets in
length, but that limitation is not discussed here.  It should be.

  The guidelines document discusses packing multiple fields into one
attribute:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

  The document doesn't say whether or not only one key-request attribute
is permitted in an Access-Request.  If only one is permitted, then all
of the packed fields in both attributes MUST be broken out into separate
attributes.  That will enable legacy implementations to deal with the
attributes.  i.e. not only support them, but enforce policies based on them.

  What is the purpose of the "key name" field?  This document doesn't
say, and it doesn't refer to other documents which could explain the
utility of that field.  Including a key name in a key response attribute
would seem to indicate that more than one key response is permitted in
an Access-Accept.  If so, this needs to be explained, including
use-cases.  If not, the key name is not needed.

      A stricter version of RFC 3756 requirements apply for RADIUS
      messages carrying Key-Response Attribute(s).  Implementations of
      this specification MUST support IPsec along with IKEv2 for key
      management.  IPsec ESP with a non-null transform MUST be
      supported, and IPsec ESP with a non-null encryption transform and
      authentication support is necessary to provide per-packet
      confidentiality, authentication, integrity and replay protection.

  This requirement imposes a heavy burden on any implementation of this
proposal.  Most existing RADIUS EAP deployments do not use IPSec as a
transport layer.  I also question the necessity for exposing the DSRK
"in the clear" to all parties in the AAA conversation.

  i.e. in a proxy environment, entities who transport the traffic do NOT
request the key, but can see it "in the clear".  Not only that, but they
can modify the key without detection, as the key is not authenticated.
This issue is not discussed in the security section.

  It would also appear to be a fatal flaw in this proposal: keys being
exposed to entities that don't need to see the key, and lack of
integrity checks on the keys themselves.

  I question why the visited *network* needs the DSRK, as opposed to the
visited *NAS*.  This document does not discuss any use-cases or
requirements that would make this distinction clear.

  From what I see, only the NAS requires access to any keying material.
 For security, we can presume that the keys are opaque to everyone on
the network other than the user and the home server which authenticates
that user.  Anyone else needing access to those keys can prove their
need to either the user, or to the home server.  And in general, no one
needs to get the key from the home server,

  Since the NAS is already in direct contact with the user, it becomes
clear that the NAS can ask the user how to interpret any keying material
it has.  Since that keying material is opaque to everyone else, there is
no security issue with it being exposed, because it has no useful
information.  Since that keying material is opaque, anyone and everyone
with access to it can cache it.

  See the following message for a short exposition of the concepts
outlined above:

http://ops.ietf.org/lists/radiusext/2007/msg01001.html

  That proposal would seem to meet the requirements outlined for this
document, from what I can understand.  (The requirements and use-cases
outlined here are unclear).  That proposal can be modified to include
key lifetime, if necessary.  That proposal avoids all of the security
issues inherent in this design.

  For this proposal to move forward, it needs to have clearer use-cases
and requirements.  And it needs to address the security issues that are
currently fatal flaws.

  Alan DeKok.

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 3 Jan 2008 13:30:56 -0800

Hi Alan,
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.
"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.  

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.  

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.  

Having said that, the DSRK is not for the NAS (the NAS must not have
access to it; NAS only gets the rMSK).  The DSRK is for the local ER
server that is in the path of the EAP or ER bootstrapping exchange with
the home AAA (EAP) server.  When an ER bootstrapping exchange is used,
the peer explicitly triggers the exchange of the DSRK to the local ER
server.  

The DSRK can be protected in any manner in accordance with RADIUS
security - so, it may be end-to-end protected between the local ER
server and the home server or hop-by-hop protected as the MSK is today.

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

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, January 03, 2008 8:41 AM
> To: [email-masked]
> Subject: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
> 
>   Why is the visited network requesting keys?  Is the user 
> involved in this request?  Does the user know that the 
> visited network is requesting keys on his behalf?
> 

Hope this is clear from the DSRK purpose and description above. 

>   These issues are referenced in the security section.  
> However, that section says that channel bindings *may* be 
> necessary.  It looks to me like they are required to avoid a 
> large class of security / information leakage.
> 

The DSRK is scoped to the domain of the local ER server already.  The
domain name or requesting entity's identity is used in deriving the
DSRK.  Hence, additional channel binding may be optionally used, but it
is not required. 

>   Why is it necessary to have the requesting entities 
> identity?  Can multiple servers in a proxy chain make 
> requests at the same time?  If so, why?  What benefit does this serve?
> 

Only one local ER server can request a DSRK.  However, the home AAA
server and the peer need to know the requesting entity's identity so
that the DSRK derivation can be done correctly and it can be delivered
to the right entity.  

>   Are key lifetimes different from user session lifetimes?  
> RADIUS already has support for Session-Timeout, which would 
> seem to put an upper limit on key lifetimes, at least for one 
> session.  Are these keys to be cached across multiple user 
> sessions?  If so, this document should say.
> 

The lifetime here is referring to the DSRK lifetime which may be greater
than the lifetime given to the MSK or rMSK.  The DSRK lifetime will
always be less than the EMSK lifetime though.  

>    That section then says the identity "is to be included".  
> The text should agree with itself.
> 

We will fix the inconsistency. 

>   The next section says that the identity can be only 192 
> octets in length, but that limitation is not discussed here.  
> It should be.
> 

Okay. 

>   The document doesn't say whether or not only one 
> key-request attribute is permitted in an Access-Request.  If 
> only one is permitted, then all of the packed fields in both 
> attributes MUST be broken out into separate attributes.  That 
> will enable legacy implementations to deal with the 

Actually, this document has gone through a couple of contortions due to
lack of clarity from the RADIUS side on how to proceed here.  We will be
updating this to use the RADIUS extended attributes format (that seems
to be the preferred approach as noted from the last meeting).   

>   What is the purpose of the "key name" field?  This document 
> doesn't say, and it doesn't refer to other documents which 
> could explain the utility of that field.  Including a key 
> name in a key response attribute would seem to indicate that 
> more than one key response is permitted in an Access-Accept.  
> If so, this needs to be explained, including use-cases.  If 
> not, the key name is not needed.
> 

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.  Also,
RFC4962 recommends that all derived keys have key names - the peer and
the home AAA can derive it consistently, but ultimately, the DSRK holder
needs to know the key name. 

>   This requirement imposes a heavy burden on any 
> implementation of this proposal.  Most existing RADIUS EAP 
> deployments do not use IPSec as a transport layer.  I also 
> question the necessity for exposing the DSRK "in the clear" 
> to all parties in the AAA conversation.
> 
>   i.e. in a proxy environment, entities who transport the 
> traffic do NOT request the key, but can see it "in the 
> clear".  Not only that, but they can modify the key without 
> detection, as the key is not authenticated.
>   It would also appear to be a fatal flaw in this proposal: 
> keys being exposed to entities that don't need to see the 
> key, and lack of integrity checks on the keys themselves.
> 

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
- some of the confusion there too is from the pending RADEXT direction
on this topic. 

>   I question why the visited *network* needs the DSRK, as 
> opposed to the visited *NAS*.  This document does not discuss 
> any use-cases or requirements that would make this distinction clear.
> 
>  For security, we can presume that the keys are opaque to 
> everyone on the network other than the user and the home 
> server which authenticates that user.  Anyone else needing 
> access to those keys can prove their need to either the user, 
> or to the home server.  And in general, no one needs to get 
> the key from the home server,
> 
>   Since the NAS is already in direct contact with the user, 
> it becomes clear that the NAS can ask the user how to 
> interpret any keying material it has.  Since that keying 
> material is opaque to everyone else, there is no security 
> issue with it being exposed, because it has no useful 
> information.  Since that keying material is opaque, anyone 
> and everyone with access to it can cache it.
> 
>   See the following message for a short exposition of the 
> concepts outlined above:
> 
>   That proposal would seem to meet the requirements outlined 
> for this document, from what I can understand.  (The 
> requirements and use-cases outlined here are unclear).  That 
> proposal can be modified to include key lifetime, if 
> necessary.  That proposal avoids all of the security issues 
> inherent in this design.
> 
>   For this proposal to move forward, it needs to have clearer 
> use-cases and requirements.  And it needs to address the 
> security issues that are currently fatal flaws.
> 

Hope the DSRK explanations help in clarifying the above.  Please let me
know if we can answer more questions.  We will also keep you posted on a
revision of this document. 

Thanks,
Vidya

---

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

> 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.

> 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.

> 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.

> further used for reauthentication during authenticator changes within

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

> 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.

> 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.

> 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.

> 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.

---

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

> 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.

---

From: [email-masked]
Date: Fri, 4 Jan 2008 11:15:02 +0800 (CST)

some comments on local ER servers and EAP keying hierarchy
benefits:
1. reduce communication cost between home domain and foreign domain.
2. optimize the full EAP procedure. so that signalings are reduced.
3. restricts the domino effect issue into small domains.
disadvantages :
1. it requires the carriers to deploy a lot of ER servers in the network-> spend more money
2. the EAP keying hierarchy is too complex--->lead to more key generating/managing cost---> low efficiency
IMO:
(1) the keying hierarchy draft should only aim to avoid the abuse of EMSK, it should not add so many other materials.(or maybe a seperate draft?)
(2) the idea of adding a lot of ER server into the network may not be acceptable to the carriers due to its high cost. 
 
So, In fact, there may be better choice for addressing these issues---->using a mathmetical algorithm. The following link introduced a new mathmetical algorithm. I think it may be more efficient:
http://www.ietf.org/internet-drafts/draft-wan-hokey-eccho-00.txt

在2008-01-04，"Dan Harkins" <[email-masked]> 写道：

  Hi Vidya,

  Dan.

---

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: "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: Lakshminath Dondeti <[email-masked]>
Date: Fri, 04 Jan 2008 08:58:22 -0800

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.

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 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.  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.

best wishes for the new year,
Lakshminath

---

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]
> that a key hierarchy is necessary.

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

> 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?

> 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'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,

  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: Lakshminath Dondeti <[email-masked]>
Date: Fri, 04 Jan 2008 16:41:01 -0800

Hi Dan,

The feedback I am getting from others is that we have to look at the 
multiple possible models and work accordingly.  I was also reminded that 
this is not new in the IETF; SIP proxying has similar issues (which I am 
familiar with and have had to consider in the context of key management 
for SRTP).  There are hop-by-hop security models and end-to-end security 
models in that context as well.  That by itself is sufficient 
justification for DSRK key hierarchy.  I have provided some example uses 
of such a key hierarchy in the hop-by-hop case as well.  So, the 
complexity, if we want to call it that, is necessary and useful.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 04 Jan 2008 16:58:42 -0800

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

---

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

Hi Lakshminath,

  I missed the example uses. Was there supposed to be an attachment
to your email?

  I'm very sorry this thread has gotten bogged down in the hop-by-hop
and proxy issue. Can we just forget proxies for a second and can you
then answer this question?

  -. Why does the ER Server in Domain A require a different key than
     the ER Server in Domain B?

I just want to know if there's some problem or attack or issue that this
key hierarchy is addressing. Thank you very much in advance.

  Will all due respect I think justification of the DSRK key hierarchy
by mentioning SIP proxying is a non sequitur.

  regards,

  Dan.

---

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]
> >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?  

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 
> seems to
> indicate that this might not always be the case.
> 

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.  

> 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?
> 

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.  

> 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"?
> 

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.  

> 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? 

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.  

> 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?
> 

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. 

> 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?
> 

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.  

> 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?
> 

It represents separate RADIUS attributes. 

> 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?
> 
> 

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.
> archive: <http://psg.com/lists/radiusext/>
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 04 Jan 2008 17:38:31 -0800

Hi Dan,

On the SIP thing, I was responding to your note on the holistic approach 
to design.  It is also a useful parallel to consider in the hop-by-hop 
vs. end-to-end security.  As I noted, I can't take credit for making the 
connection either.

>   I missed the example uses. Was there supposed to be an attachment

I wrote an example in my earlier response.  I was referring to that.

>      the ER Server in Domain B?

To repeat what I said,
* when there is end-to-end protection of DSRKs,
* to enable the possibility of tallying accounting information
it is necessary and useful to have different keys sent to the ER servers 
in different servers.

Furthermore, if Domains A or B are not transit domains for each other, 
they would not have access to each others' DSRKs, even when there is 
only hop-by-hop security.

Finally, independent key management is possible when the keys are 
different.  I do understand your point about ensuring key separation in 
the context of reauthentication, but it is not clear whether that would 
be the case for other plausible uses.

Have a good weekend.

regards,
Lakshminath

---

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

Hi Dan,

>      the ER Server in Domain B?

Just focusing on the question above, I thought this was the question I
answered in my previous email.  Let me try again.  There is no necessary
correlation between Domains A & B or between either of those domains and
the home domain.  The acceptable proxies between Domain A and the home
domain or Domain B and the home domain are based on business
relationships and we cannot make assumptions that those can be the same.
Hence, there are cases where there must be key separation between the
two domains.  

When one large administrative domain is being broken up into multiple
key management domains for quicker reauthentication, it is feasible to
provide the same key to the different servers.  But, this would imply
that we have two means of deriving the rMSK and that is not desirable.  

When there is end-to-end security again, key separation is clearly
useful, since even the proxies in that case have not had access to the
key - only the local ER server A and the home AAA server know DSRK1 and
only the local ER server B and the home AAA server know DSRK2.  

So, having the key hierarchy seems to be the common solution that allows
all applicable models.  Also, just as the EMSK hierarchy document is
written with a view to allowing other future uses of the EMSK within the
scope of the key, the DSRK is also set up for potential other future
uses within the scope of the domain it is derived for.  So, it is
feasible that keys for local services are derived from the DSRK within
that local domain.  Two domains may or may not provide the same set of
services and having key separation is absolutely essential for proper
key management and usage within each domain. 

Regards,
Vidya

---

From: [email-masked]
Date: Sat, 5 Jan 2008 11:53:04 +0800 (CST)

Dear all:
Thanks for your anwsers.However I still have several questons:
(1)about the key hierarchy
Why should we take end-to-end security into account here? I think end-to-end 
security is another question, it has nothing to do with access security. IMO, end-to-end security is usually concerned with other application services such as VOIP, not access authentication. If so, why not leave end-to-end security issue to those services, and we only focus on access security here? I think it is much better for the application service such as VOIP to decide how to establish a end-to-end security solution.
some one may argue that we can define the keying hierarchy for local service. However, I think the so called local service is concerned with the specified network(such as WLAN,Wimax) .
In fact, 802.11i,802.11r and wimax NWG stage 3 have already defined their keying hierarchy for solve end-to-end security in locla area. however, I think this scenario is concerned with the specified network, and it is not suitable for IETF to define such a keying hierarchy.
So, IMO, the handover WG should only focus on a narrow area : access security. 

(2)about the ER proxy
why is the proxy necessary to privide fast reauthentication?maybe there are some other solutions that need not the proxy. I think the solution that needs not a proxy will be much cheaper and efficient than a solution that brings a new net element to the network. Do you think so?
Why must a third party attend the re-authentication procedure? I think it is surely that two-party authentication is much more efficient especially in a handover scenario.
 
BR
Tom

---

From: [email-masked]
Date: Sat, 5 Jan 2008 14:36:35 +0800 (CST)

some comments on hop-to-hop security:

The IEEE 802.11 WG defined AC and AP, and the wimax forum defined the CSN,ASN,BS, BSS. so there may be the hop-to-hop security. However, I think 

this scenario is for specific wireless technologies, the entities invloded in the hop-to-hop security is wireless technology specifically, and should be defined by other standards organizations. At IETF, I think the problem only lies in the roaming between authenticators within the same AAA server. I do not know why we copy the IEEE and wimax forum keying hierarchy to IETF. Can any one here  anwser this question? Thanks.

Tom

---

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:
> 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: Lakshminath Dondeti <[email-masked]>
Date: Sat, 05 Jan 2008 11:22:41 -0800

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

---

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
>
>>>> for use, and thus key hierarchy is not needed.  In Type 2 trust, key 
>>>> hierarchy is still needed.  Also, there is no

---

From: [email-masked]
Date: Sun, 6 Jan 2008 08:54:22 +0800 (CST)

Dear Yoshi:
(1)about RFC 4568 
RFC4568 is specified for unicast media streams, so it surely will consider end-to-end security. it is different from the hokey work, and we can not draw the conclusion that end-to-end security is a default model for all systems. Also, I do not mean that end-to-end security is not necessary in wireless environment, I just mean that it is not necessary in hokey WG.
(2)about DSR-KH
If we assume that we must deploy DSR-KH in the network, then surely Kerberos like mechanism (the so called three-party authentication) is needed to establish SA between EAP server and DSR-KH. However, I think DSR-KH is not a must. There may be a much more efficent two-party solution for wireless access authenticationin.(Surely, traditional two-party authentication can hardly support mobility management. however, there seems to be a new mechanism making it possible for re-authentication.) the link: www.ietf.org/internet-drafts/draft-wan-hokey-eccho-00.txt
 
Thanks.
BR
Tom

在2008-01-06，"Yoshihiro Ohba" <[email-masked]> 写道：

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 05 Jan 2008 18:33:12 -0800

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

Lakshminath

---

From: [email-masked]
Date: Sun, 6 Jan 2008 10:48:04 +0800 (CST)

Dear all:
there is a concept end-to-end security. this concept is used all over the world. I think we need to redefine it here when we talk about it. In my mind, the end-to-end security sounds like MN-to-MN security. Am I right? could anyone here explain it? thanks.
 
BR
Tom

---

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:
>>>> cases.  Yoshihiro Ohba

---

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

The meaning of end-to-end security being discussed here is different
from MN-to-MN security.  We are using the term end-to-end security to
mean server-to-third-party security in terms of three-party key
distribution for HOKEY.

Also, I don't think hokey-eccho solution is a two-party solution.  I
think it is a three-party solution since key distribution from AAAF to
authenticator is needed.

Yoshihiro Ohba

---

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: [email-masked]
Date: Sun, 6 Jan 2008 16:31:59 +0800 (CST)

Dear Yoshi:
 
Thanks for your explaination of end-to-end security. It seems to be a very different concept. Maybe the hop-to-hop security is a different concept too. Would you please explain it to me?
 
As you said, hoke-eccho can be seen as a three-party solution. it is a two party authentication only when we focus on the handover procedure. But if we consider the whole management model, the management model of AAAF is still three-party.
 
BR
Tom

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 6 Jan 2008 13:28:26 -0800 (PST)

Hi Lakshminath,

On Fri, January 4, 2008 5:38 pm, Lakshminath Dondeti wrote:
[snip]
> * when there is end-to-end protection of DSRKs,

  So you're saying that when there is end-to-end protection of these
distributed keys that they must be different. And your justification
for making that statement is....well see that's the problem. I don't
see the justification for making that statement. I'm really having
trouble putting these things together and coming to the conclusion
that you have.

  Perhaps if I ask the question again in a different manner it will
elicit the justification I am looking for. So:

  - What problem would happen if there was end-to-end protection of
    these distributed keys and the same key was distributed to Domain A
    and Domain B?

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 6 Jan 2008 13:40:22 -0800 (PST)

Hi Vidya,

> Hence, there are cases where there must be key separation between the

  I'm not making any assumptions about business relationships. Actually,
your observation about business relationships really underscores my
point (as I alluded to when you last made brought it up). Let me try
to rephrase this question again:

  - What problem would happen if there was no key separation between the
    two domain, given your observation about differing business
    relationships?

It seems like something bad must happen if this key separation isn't
there. What is this bad thing and how does it manifest itself?

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 6 Jan 2008 14:16:08 -0800

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.
[gwz] 
There is another WG dedicated to the discussion of Kerberos.  We have
discussed (and dismissed) the usage of Kerberos in this WG several times
already & we're not doing it again. 
[/gwz]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 6 Jan 2008 18:18:12 -0500

Let me clarify one thing.  What we have discussed about the usage of
Kerberos (and the usage was dismissed) is for HOKEY 3-party key
distribution for a couple of use cases described in
draft-ietf-hokey-key-mgm (and several use cases would be ruled out
based on a consensus in the Vancouver meeting [I think such a
consensus must be confirmed over email]).  On the other hand, I don't
think we have discussed a Kerberos usage for establishing an SA
between third-party and server in HOKEY 3-party key distribution, and
that is what I am trying to bring here.

Yoshihiro Ohba

---

From: [email-masked]
Date: Mon, 7 Jan 2008 08:49:34 +0800 (CST)

Dear Dan:
 
the problem is domino effect.
 
BR
Tom

在2008-01-07，"Dan Harkins" <[email-masked]> 写道：

  Hi Vidya,

  regards,

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 06 Jan 2008 17:09:29 -0800

Hi Dan,

I get the feeling that we may be talking past each other :).  After 
several messages we are at the same question.

Let us at least try to see if we are at least understanding where we 
stand.  I think I understand what you are saying.  In my own words, you 
are saying that since it is plausible for the ER server in Domain A to 
acquire the key that the ER server in Domain B might receive, there is 
no reason for sending separate keys to the ER servers.  Cryptographic 
key separation for derived keys can be arranged through other means.  Is 
that accurate?

Could you also do me a favor and summarize what you think I am saying in 
response?

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 6 Jan 2008 22:23:07 -0800 (PST)

Hi Tom,

  The scope of a distributed key cannot be communicated to a proxy and
other parties in the system may not be aware that a proxy is even
involved so scoping the key is not possible. Also compromise of a
single proxy will affect keys held by other entities in the system.
In other words, having key separation does not prevent the domino
effect in a HOKEY system.

  Dan.

On Sun, January 6, 2008 4:49 pm, [email-masked] wrote:
> ÔÚ2008-01-07£¬"Dan Harkins" <[email-masked]> Ð´µÀ£º
>
>   Hi Vidya,
>

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 6 Jan 2008 22:32:19 -0800 (PST)

Hi Lakshminath,

  No that's not what I'm saying. What I think you're saying is that it
is your belief that key separation is mandatory when there is end-to-end
protection of keying material distribution. I just can't get to that
conclusion from that premise which is why I asked you to describe the
exact problem that would manifest itself if there wasn't key separation.

  When people talk past each other it's usually because one or both
are addressing their own questions because they are assuming those
questions are also the other person's. Let's not do that.

  Can you please explain to me the problem that would manifest itself
if there was no key separation and there was end-to-end protection of
distribution of keying material? Please.

  regards,

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Jan 2008 18:14:02 -0800

Hi Dan, 

> It seems like something bad must happen if this key 
> separation isn't there. What is this bad thing and how does 
> it manifest itself?
> 

Lack of key separation between domains fundamentally can lead to a
Domino effect.  Just because there are some operators who are
comfortable having proxies having access to the key material does not
rule out those that actually want end-to-end security or that separation
between domains.  Also, even those who are comfortable with having some
proxies have access to the key material may want key separation across
some other domains.  

We should be designing a protocol that allows for such key separation.
Deployments make a choice on the proxies, unfortunately.  It is not
useful to claim that since the model allows for proxies, we don't need
to design protection against domino effects.  The existence of proxies
is the unfortunate reality of certain deployments that we must work with
- doesn't mean we design specifically for that and leave others out. 

Regards,
Vidya

---

From: Alan DeKok <[email-masked]>
Date: Wed, 09 Jan 2008 04:18:21 +0100

Narayanan, Vidya wrote:
> rule out those that actually want end-to-end security

  The overwhelming majority of AAA proxy chains in place today are
RADIUS.  RADIUS does not have end to end security.

> or that separation

  To solve what problem?  They may want a lot of things, but not all are
reasonable.

  From what I've seen, Hokey enables temporary credentials to be
created, and cached in the network "close" to where the user is located.
   Those credentials are based on nothing more than knowledge of a
secret token / key.

  If those credentials have to be domain-specific, then domain-specific
keys can be derived from that master key, when the user attempts to log
in.  What do we gain by running key derivation functions BEFORE the user
logs in?

  If the local domains can't run the key derivation themselves, then the
derivation must be pushed back to the home authentication server (or an
equivalent one that caches the master key).  This negates much of the
benefit of Hokey.

  The local domain must also push key derivation back upstream when the
user switches domains, and wishes to do fast re-authentication.  The
alternative is to send user keys to all domains, just in case the user
switches domains in the future.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 9 Jan 2008 11:57:48 -0800

Alan,
I'm confused by your email.  I'm not sure what gave you the impression
that any key derivations are being done before the user logs in.  EAP is
run when the user logs in, as usual - a DSRK is derived from the EMSK
and distributed to a local ER server that is closer to the peer when EAP
is run or when the peer performs ERX bootstrapping.  Subsequent
reauthentications are done with the local server which holds the DSRK
and the key material for the authenticator is derived from the DSRK.  

So, I'm not sure I understand what you are getting at - please let me
know if I can help clarify anything further. 

Thanks,
Vidya

> Sent: Tuesday, January 08, 2008 7:18 PM
> To: Narayanan, Vidya
> Cc: Dan Harkins; [email-masked]
>   The overwhelming majority of AAA proxy chains in place 
> today are RADIUS.  RADIUS does not have end to end security.
> 
> > or that separation
> > between domains.  Also, even those who are comfortable with having 
> > some proxies have access to the key material may want key 
> separation 
> > across some other domains.
> 
>   To solve what problem?  They may want a lot of things, but 
> not all are reasonable.
> 
>   From what I've seen, Hokey enables temporary credentials to 
> be created, and cached in the network "close" to where the 
> user is located.
>    Those credentials are based on nothing more than knowledge 
> of a secret token / key.
> 
>   If those credentials have to be domain-specific, then 
> domain-specific keys can be derived from that master key, 
> when the user attempts to log in.  What do we gain by running 
> key derivation functions BEFORE the user logs in?
> 
>   If the local domains can't run the key derivation 
> themselves, then the derivation must be pushed back to the 
> home authentication server (or an equivalent one that caches 
> the master key).  This negates much of the benefit of Hokey.
> 
>   The local domain must also push key derivation back 
> upstream when the user switches domains, and wishes to do 
> fast re-authentication.  The alternative is to send user keys 
> to all domains, just in case the user switches domains in the future.
> 
>   Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 09 Jan 2008 23:11:09 +0100

Narayanan, Vidya wrote:
> that any key derivations are being done before the user logs in.

  ? I'm pretty clear that no key derivations are done until after the
user has been successfully authenticated.

>  EAP is

  The derivation of the DSRK happens after login, of course.  But how
does the DSRK get distributed to *multiple* domains?

  In the common case of re-authentication to the same domain as the
original authentication, local caching of the DSRK is fine.  The DSRK
cannot be distributed pro-actively to multiple domains, because most
distributed keys will never be used.

> know if I can help clarify anything further. 

  I don't understand why DSRK's are necessary.  I think I share Dan's
questions in this matter.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 9 Jan 2008 16:34:44 -0800

> 
>   ? I'm pretty clear that no key derivations are done until 
> after the user has been successfully authenticated.
> 

Well, this seems to contradict your previous email where you wrote,
"What do we gain by running key derivation functions BEFORE the user
logs in?"  So, that was the cause for my confusion. 

> > and distributed to a local ER server that is closer to the 
> peer when 
> > EAP is run or when the peer performs ERX bootstrapping.  Subsequent 
>   The derivation of the DSRK happens after login, of course.  
> But how does the DSRK get distributed to *multiple* domains?
> 
>   In the common case of re-authentication to the same domain 
> as the original authentication, local caching of the DSRK is 
> fine.  The DSRK cannot be distributed pro-actively to 
> multiple domains, because most distributed keys will never be used.
> 

What gave you the impression that any proactive distribution is even
going on or that the DSRK is distributed to multiple domains at the same
time?  When the peer first attaches to an authenticator in a new domain,
it may perform ERX bootstrapping or a regular full EAP exchange which
will result in a DSRK at the local ER server in that domain. Subsequent
authentications within that same local domain will only have to go to
the local ER server.  So, the very first authentication in a new domain
is what fetches the DSRK to the local domain - there is no proactive
distribution or even derivation of DSRKs going on. 

>   I don't understand why DSRK's are necessary.  I think I 
> share Dan's questions in this matter.
> 

I am not sure how I can explain this beyond what I've said in my emails
or what is in the EMSK hierarchy and ERX documents.  The key hierarchy
(the need for DSRKs included) was also extensively debated and the
current structure was agreed upon in the WG a while ago - I'm really
concerned about revisiting decisions and having circular discussions.  

So far, most of your observations on ERX seems to point to not having
read the protocol specification and key hierarchy documents - if that is
the case, I'd urge you to read those and send comments.  If you have
read it and there are parts of the documents that lead to the points you
have been making, pointing those out will be extremely useful so that we
can fix any misleading/incorrect text.  

Thanks,
Vidya

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 9 Jan 2008 17:12:29 -0800 (PST)

Hi Vidya,

On Wed, January 9, 2008 4:34 pm, Narayanan, Vidya wrote:
[snip]
> concerned about revisiting decisions and having circular discussions.

  Just because it's a decision doesn't mean it's correct. If all decisions
were not revisitable then there would be no need for last call-- just
publish it as an RFC! Happily that is not the case.

  As I said in a previous email, the goal posts have moved from the last
time the key hierarchy was discussed. My understanding of the need for
this thing was when the peer was concerned about authentication of "the
network" and wanted to control distribution of these network access
credentials via a 3 party protocol. In that case key separation with a
key hierarchy makes sense.

  But that is not the current consensus of the working group. The working
group in Vancouver decided that the paradigm it has is one where "the
network" is concerned about authenticating the peer and all the peer wants
is access (and no surprises in his or her bill at the end of the month).
The example given in Vancouver was that Russ' mobile phone said "Rogers"
but he's a t-mobile customer. He doesn't care who gives him service as
long as he gets a dial tone and since t-mobile bills him then for him to
get a bill for his service from Rogers it means that t-mobile and Rogers
have some sort of contractual agreement to supply and bill for service.

  The peer doesn't care about what sort of keying happens behind the
scenes in "the network" as long as its necessary to continue to provide
him with service and all "the network" cares about is that it really is
the right peer and as long as he produces _some_ key derived from the EMSK
that's proof he holds the EMSK and therefore he can be provided service
and billed.

  Since the threat model has changed, at least in the eyes of quite a few
participants in HOKEY back when the key hierarchy was discussed, it seems
entirely acceptable for things to be reevaluated to see whether they are
still needed.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 9 Jan 2008 18:33:01 -0800

Hi Dan,
The threat model has always been the same.  We have had these exact same
debates before on proxies and I've written several times before about
how there are models where the only thing the peer cares about is
getting the service it was promised and being billed as promised.  So, I
don't believe we are discussing anything new.  

It still does not mean that in all scenarios, we just hand the same key
to all local domains.  Your assumption that being comfortable with
proxies equals being comfortable handing the same key to all domains the
peer may roam to is incorrect.  If one wanted to hand the same key to
all domains, that is by all means possible - you just derive a DSRK with
the same label.  This key is at the same level as USRKs and is derived
directly from the EMSK - so, you would get your one level, same key
model when that's good enough for a deployment.  

Vidya

> Sent: Wednesday, January 09, 2008 5:12 PM
> To: Narayanan, Vidya
> Cc: Alan DeKok; Dan Harkins; [email-masked]
> > I am not sure how I can explain this beyond what I've said in my 
> > emails or what is in the EMSK hierarchy and ERX documents.  The key 
> > hierarchy (the need for DSRKs included) was also 
> extensively debated 
> > and the current structure was agreed upon in the WG a while 
> ago - I'm 
> > really concerned about revisiting decisions and having 
> circular discussions.
> 
>   Just because it's a decision doesn't mean it's correct. If 
> all decisions were not revisitable then there would be no 
> need for last call-- just publish it as an RFC! Happily that 
> is not the case.
> 
>   As I said in a previous email, the goal posts have moved 
> from the last time the key hierarchy was discussed. My 
> understanding of the need for this thing was when the peer 
> was concerned about authentication of "the network" and 
> wanted to control distribution of these network access 
> credentials via a 3 party protocol. In that case key 
> separation with a key hierarchy makes sense.
> 
>   But that is not the current consensus of the working group. 
> The working group in Vancouver decided that the paradigm it 
> has is one where "the network" is concerned about 
> authenticating the peer and all the peer wants is access (and 
> no surprises in his or her bill at the end of the month).
> but he's a t-mobile customer. He doesn't care who gives him 
> service as long as he gets a dial tone and since t-mobile 
> bills him then for him to get a bill for his service from 
> Rogers it means that t-mobile and Rogers have some sort of 
> contractual agreement to supply and bill for service.
> 
>   The peer doesn't care about what sort of keying happens 
> behind the scenes in "the network" as long as its necessary 
> to continue to provide him with service and all "the network" 
> cares about is that it really is the right peer and as long 
> as he produces _some_ key derived from the EMSK that's proof 
> he holds the EMSK and therefore he can be provided service and billed.
> 
>   Since the threat model has changed, at least in the eyes of 
> quite a few participants in HOKEY back when the key hierarchy 
> was discussed, it seems entirely acceptable for things to be 
> reevaluated to see whether they are still needed.
> 
>   Dan.
> 
> 
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Jan 2008 10:01:16 +0100

Narayanan, Vidya wrote:
> peer may roam to is incorrect.

  Why?  That's what proxies do today.

  Global Internet roaming is done *now* by exposing user authentication
credentials to *all* proxies.  This has been the practice for well over
a decade.  There have been no compelling political, commercial,
technical, or security reasons to change this.

>  If one wanted to hand the same key to

  That still doesn't explain why domain-specific keys are needed.  I
would very much like to see an answer to this question that doesn't
involve simple assertion.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 10 Jan 2008 11:22:25 -0800

> Sent: Thursday, January 10, 2008 1:01 AM
> To: Narayanan, Vidya
> > It still does not mean that in all scenarios, we just hand the same 
> > key to all local domains.  Your assumption that being 
> comfortable with 
> > proxies equals being comfortable handing the same key to 
> all domains 
> > the peer may roam to is incorrect.
> 
>   Global Internet roaming is done *now* by exposing user 
> authentication credentials to *all* proxies.  

Credentials?  Credentials aren't sent anywhere out of the home domain
server as far as I know.  Transported session keys are exposed to
proxies - and that too, only to proxies *in the path between home and
visited domains* - not arbitrarily to all proxies sitting anywhere on
the Internet.  The proxy chain between a home and visited domain is
established consciously - it is not like a visited domain randomly picks
a AAA proxy on the Internet to go to and packets get randomly routed
until the home domain is somehow reached. 

For instance, if you had a setup like this: 

                                   -----------
                                  | AAA-Home  |
                                   -----------
                                        |
         -------------
-------------
        | AAA Proxy 1 |                                        | AAA
Proxy 2 |
         -------------
-------------

There is no reason why AAA Proxy 2 should see keys being transported
from AAA-Home to Local ER server A.  To say that just because AAA Proxy
1 sees the keys sent to Local ER server A, it should suffice to send the
same key to Local ER server B is flawed. 

> This has been 
> the practice for well over a decade.  There have been no 
> compelling political, commercial, technical, or security 
> reasons to change this.
> 
> >  If one wanted to hand the same key to all domains, that is by all 
> > means possible - you just derive a DSRK with the same 
> label.  This key 
> > is at the same level as USRKs and is derived directly from 
> the EMSK - 
> > so, you would get your one level, same key model when that's good 
> > enough for a deployment.
> 
>   That still doesn't explain why domain-specific keys are 
> needed.  I would very much like to see an answer to this 
> question that doesn't involve simple assertion.
> 

It is not just an assertion.  There is very much a need for key
separation when Domains A & B in the picture above have no associations
and the home domain has separate associations with each one, possibly
with different billing agreements that must be differentiated.  Also,
there is nothing in the protocol that prevents the home domain from
actually having an end-to-end SA with the local domains to which key
distribution needs to happen.  Also, I'd like us to remember that HOKEY
can run over Diameter as well - so, we aren't designing for a narrow
view of a world of RADIUS with proxies and that too one where all local
domains that the peer visits being part of one, big proxy chain.  

Another point, which I also made in one of my recent emails, is that the
DSRK is designed for other future uses as well.  Domains A & B may
derive other key material from it for other local services that we do
not know of today.  And, there is no assumption that those set of
services are the same in every domain the peer roams to.  For instance,
one can envision a local mobility service that the peer can take
advantage of in Domain A and a local IMS breakout that the peer can take
advantage of in Domain B.  The key hierarchy and the derivations defined
are planned with such future extensibility in mind, as they should be. 

Vidya

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 11:31:03 -0800

Sorry I had to focus my attention elsewhere recently.  I will try and 
respond to some of the other emails as well.  It is a busy time of the 
year for me.

On 1/10/2008 1:01 AM, Alan DeKok wrote:
> credentials to *all* proxies.  

Perhaps this is a terminology thing, but I doubt that credentials are 
exposed to proxies.  I agree that session keys -- specifically the MSK 
-- are exposed to proxies.  Perhaps I am wrong and credentials are 
exposed to proxies today.  If that is indeed the case, pretty much all 
is lost!

> This has been the practice for well over

To reduce latency.  ERP makes reauthentication a 1 RT affair.  The 
domain specific keys allow the authentication to happen with a local 
server rather than the home server.

regards,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 10 Jan 2008 12:12:35 -0800 (PST)

Hi Lakshminath,

> exposed to proxies today.  If that is indeed the case, pretty much all

  The key provided by the AAA server is used as a credential to obtain
network access. The peer's proof of possession of that key/credential
during a secure association protocol is what causes the authenticator
to provide service to the peer. As RFC4962 says under "Strong Fresh
Session Keys":

   "[A] secure association protocol is used to establish session keys.
    The AAA protocol and EAP method MUST ensure that the keying material
    supplied as an input to session key derivation is fresh, and the
    secure association protocol MUST generate a separate session key for
    each session, even if the keying material provided by EAP is cached.
    A cached key persists after the authentication exchange has completed."

So the key that can be cached, that "keying material supplied as input
to session key derivation", is the MSK, it's the credential used to
allow network access. It's used to generate session keys but is not, itself,
the session key.

  In HOKEY something derived from the EMSK is also going to be similarly
used to provide network access and generate session keys. It is not going
to be the session key itself but will serve as a "credential" that the
peer will prove possession of as a way of obtaining service.

  (The question is how many layers of cruft are there between the EMSK
and that credential used in the secure association protocol and why?)

> server rather than the home server.

  Actually reduced latency is achieved by storing the key in the local
domain it does not answer the question "why domain-specific keys are
needed". The reasons given for having domain-specific keys are
assertion-- "we must have key separation"-- and more assertion-- "to
argue otherwise is flawed" and those aren't very compelling.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 12:57:21 -0800

>> respond to some of the other emails as well.  It is a busy time of the

So, I won't respond to your other email Dan :) and instead try and 
address this email.  And, the email is already long and so let me try to 
address two topics here.

Credentials vs. session keys:

Long term credentials are stored in the home server; they are never 
exposed to the proxies and should be kept that way.

For reauthentication we agreed to use the EMSK and keys derived thereof.

We don't want to use the EMSK for reauthentication, because that would 
be shortsighted.  So we have the notion of usage specific keys.  I 
believe there is no dispute there either.

It appears that the latency argument justifies the use of local servers. 
  So then the next question is whether to have one usage specific key 
that the home as well as one or more local servers might use or one for 
home and one each for local servers.  One key would never leave the home 
server(s) and the others might traverse proxies.  So, it is clear to me 
that there should at least be two.  As much as one might trust the 
proxies they should not be exposing keys that they do not need to. 
Next, if there is end to end security, there is no need to send the same 
key to local servers.  This is just being conservative, if nothing else 
in key sharing.

Further, there is the notion of visited/local vs. home domain services 
being different.  In that case, it makes sense to have a distinct key 
for each server.  I realize there are other ways of doing the key 
hierarchy, but we considered the many levels and agreed that it makes sense.

Dan, I realize your point about goal posts etc., (I don't agree with it, 
but I understand what you are saying), but that was not the reason the 
key hierarchy exists.

---

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

Hi Lakshminath,

> exposed to the proxies and should be kept that way.

  If you mean a user's password then yes. But you had said, "I agree that
session keys -- specifically the MSK-- are exposed to proxies." But, as
I pointed out, the MSK is not a session key, at least to use the terms
from RFC4962 it's not.

  What's output by the AAA server is going to be used as a credential to
obtain network access. Prove possession of this blob-of-bits and you get
network access.

> believe there is no dispute there either.

  I think there's a typo above. One of those mentions of EMSK has an E
in it that shouldn't be there.

  I'm not sure I understand your point about no dispute. I'm not agreeing
to anything in this key hierarchy unless it's justified. So far it's not
been justified.

> key to local servers.  This is just being conservative, if nothing else

  I think you're twisting things around by saying "if there is end to end
security, there is no need to send the same key to local servers." I don't
think there is a "need" either way. We could have a 47 level key hierarchy
and send the 44th to a local ER server. There's no "need" to send the same
one to everyone so let's have a 47 level hierarchy and send the 44th.

  But wait. Why would you need a 47 level key hierarchy in the first place?
I don't know. I could justify it using the same reasons for having the one
being proposed though: "it provides key separation", "to not have such a
key hierarchy is flawed", "it makes sense". One thing I would not be able
to do, though, is say what problem it solves or what attack is foiled by
having such a thing. Can you answer the following?

      What attack is possible if there are no domain-specific keys
      that would not be possible if keys were domain-specific?

That would illustrate, to me at least, the motivation for this thing and
point out the actual flaw in my thinking.

> hierarchy, but we considered the many levels and agreed that it makes

  "it makes sense". Hmmm, well I guess sensible people can disagree with
out being nonsensical then.

> but I understand what you are saying), but that was not the reason the

  That was the reason this stuff didn't come up before though. The
impression I get from reading responses to my posts is something along the
lines of "we went over that before and we all agreed so let's just put a
stop to this discussion." Well when we went over that before the goal
posts were different so that shouldn't preclude me from bringing up this
point now.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 17:23:03 -0800

I will try to be positive Dan :).

One of the reasons I point to the old discussions and consensus 
agreements is that we have a colorful history in the IETF in going over 
things again and again, not always to improve things.  We are also not 
really perfect in our designs either.  So I am not sure really the point 
in debating things endlessly.

But, I respect your insight into protocol design.  You have done this 
longer than I have and perhaps we were all wrong in the key hierarchy 
design.  So, let me try another way.  Here is what is needed from the 
EMSK hierarchy.

* to be able to derive various usage specific keys from the EMSK (by the 
way the typo was the omission of the word "directly"; we don't want to 
use the EMSK directly for reauthentication;)

* deliver domain specific keys so the domain servers can do the same thing

So this makes the hierarchy

                 EMSK
               /   / \
              /   /   \
     USRK[1..n] DSRK1  DSRK2  ...           (derived as needed)
                   /      \
            DSUSRK[1..m1]  DSUSRK[1..m2]

There are 2 levels in the key hierarchy.  The two reasons above explain 
the two levels.

With the above hierarchy, the USRKs are never sent out.  If there is 
dispute in billing when the rMSK is derived solely from the USRK (rRK), 
then the operator would know that the error is not due to any 
EAP-related protocols or proxies for that matter.  Likewise, if there 
are repeated billing issues associated with VisitedOperator1 and there 
is end-to-end security in delivering DSRKs, then the operator can infer 
that there are issues associated with VisitedOperator1.  Now of course, 
when proxies are involved it is not so clear.  There are strategies to 
get around that too.  For instance, the operator may program the 
smartcard in the peer to maintain usage statistics and can fetch them 
when there are such issues.  In that case again, the operator may be 
able to make inferences about where the problem is.

Hope that explains it for you.  I have a few important IETF deadlines 
and so my responses may be sparse.

And yes, sensible people can disagree without being nonsensical.

best,
Lakshminath

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 06:33:28 +0100

Lakshminath Dondeti wrote:
> exposed to proxies.

  This, then is the core of the misunderstanding.

  Authentication credentials are user names and passwords.  In RADIUS
deployments (i.e. all common inter-ISP roaming), those credentials are
exposed to all proxies.  When you use WiFi hotspots, those credentials
are exposed to all proxies.  When you use any well-known corporate
roaming for dialup (historically), or other network access, those
credentials are exposed to all proxies.

>  I agree that session keys -- specifically the MSK

>> technical, or security reasons to change this.

  NO ONE thinks that exposing the credentials in this way is a problem,
or has been a problem historically.  This design has been proven to work
for hundreds of millions of users for over a decade, across thousands of
different organizations.

> [ why DSRK ]

  If a re-authenticaton key is cached locally, yes.  That key is cached
ONLY on the network where the user originally logged in.  So for
inter-domain roaming, the key is NOT on a local server, and the
authentication MUST go back up the proxy chain, at least once.

  The alternative is to pro-actively push the keys to all domains, which
does not scale.

  Alan DeKok.

---

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Fri, 11 Jan 2008 00:46:03 -0500

I am catching the tail end of this. This is pretty interesting. I
thought the EMSK was the holy grail: the key that never leaves the EAP
server. I did not know we had the same requirement about USRK. I like to
see where that is written.

I don't think the fact that keys go over proxies justifies the
philosophy of creating two keys out of EMSK and keep one at home and one
for visited network.
With that analogy, some how the DSRK for home is safer than the visited
DSRK and that was not the reason these keys were introduced. 

The real reason the hierarchy was introduced in the first place was
support handover key management, i.e. don't do key management from
scratch if you need a quick handover. But the group (although still
called "hokey") entirely missed the point of trying to provide for
handover keying.

It seems that the DSRKs just exist there to exist and get new
justifications as years go by, may be somebody needs to do an IPR search
to find the possible original justification..

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 5:23 PM
To: Dan Harkins
Cc: [email-masked]
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

* deliver domain specific keys so the domain servers can do the same
thing

                 EMSK
               /   / \
              /   /   \

best,
Lakshminath

On 1/10/2008 4:16 PM, Dan Harkins wrote:
>>>> Sorry I had to focus my attention elsewhere recently.  I will try 
>>>> and respond to some of the other emails as well.  It is a busy time

>>>> of the year for me.
>> address this email.  And, the email is already long and so let me try

>> to address two topics here.
>>
>   If you mean a user's password then yes. But you had said, "I agree 
> that session keys -- specifically the MSK-- are exposed to proxies." 
> But, as I pointed out, the MSK is not a session key, at least to use 
> the terms from RFC4962 it's not.
> 
>   What's output by the AAA server is going to be used as a credential 
> to obtain network access. Prove possession of this blob-of-bits and 
> you get network access.
> 
>> We don't want to use the EMSK for reauthentication, because that 
>> would be shortsighted.  So we have the notion of usage specific keys.

>> I believe there is no dispute there either.
> 

>   I'm not sure I understand your point about no dispute. I'm not 
> agreeing to anything in this key hierarchy unless it's justified. So 
> far it's not been justified.
> 

>> that the home as well as one or more local servers might use or one 
>> for home and one each for local servers.  One key would never leave 
>> the home
>> server(s) and the others might traverse proxies.  So, it is clear to 
>> me that there should at least be two.  As much as one might trust the

>> Next, if there is end to end security, there is no need to send the 
>> same key to local servers.  This is just being conservative, if 
>> nothing else in key sharing.
> 
>   I think you're twisting things around by saying "if there is end to 
> end security, there is no need to send the same key to local servers."

> I don't think there is a "need" either way. We could have a 47 level 
> key hierarchy and send the 44th to a local ER server. There's no 
> "need" to send the same one to everyone so let's have a 47 level
hierarchy and send the 44th.
> I don't know. I could justify it using the same reasons for having the

> one being proposed though: "it provides key separation", "to not have 
> such a key hierarchy is flawed", "it makes sense". One thing I would 
> not be able to do, though, is say what problem it solves or what 
> attack is foiled by having such a thing. Can you answer the following?
> 
> That would illustrate, to me at least, the motivation for this thing 
> and point out the actual flaw in my thinking.
> 
>> Further, there is the notion of visited/local vs. home domain 
>> services being different.  In that case, it makes sense to have a 
>> distinct key for each server.  I realize there are other ways of 
>> doing the key hierarchy, but we considered the many levels and agreed

>> that it makes sense.
> 
>   "it makes sense". Hmmm, well I guess sensible people can disagree 
> with out being nonsensical then.
> 
>> Dan, I realize your point about goal posts etc., (I don't agree with 
>> it, but I understand what you are saying), but that was not the 
>> reason the key hierarchy exists.
> 
> impression I get from reading responses to my posts is something along

> the lines of "we went over that before and we all agreed so let's just

> put a stop to this discussion." Well when we went over that before the

> goal posts were different so that shouldn't preclude me from bringing 
> up this point now.
> 
>   Dan.
> 
> 
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 06:58:46 +0100

Narayanan, Vidya wrote:
> server as far as I know.

  For existing AAA roaming, credentials are sent *into* the home domain,
because protocol limitations require transporting them as clear-text to
all participating AAA servers.

  For HOKEY, as Dan points out, the re-authentication keys *are*
credentials.

> from AAA-Home to Local ER server A.

  Yes...

>  To say that just because AAA Proxy

  If server A sees a re-authentication key, and server B sees a
re-authentication key.  The user can get re-authenticated at either domain.

  Unless A and B collude, they have no way of knowing if the keys that
they receive are the same.  Even if they do collude, I don't see why
they would care.  The user certainly doesn't care.

  i.e. since the user isn't authenticating the domain (only 1 round
trip), the domains are ALL functionally identical.  So having per-domain
keys is a complete waste of effort.

> with different billing agreements that must be differentiated.

  I was wondering when someone would get around to discussing billing.

  Once you add billing, locally cached session keys become IMPOSSIBLE.
All authentication MUST touch the home server, because the previous
session may have exhausted the user's credit balance.  This requirement
is not a technical one.  It is a commercial requirement from all of the
ISP's and interconnection providers existing today.

  i.e. local networks will refuse to let a user on the net until someone
agrees to pay for their session.  The only entity that can agree to pay
is the home server.

> ... Also, I'd like us to remember that HOKEY

  There are commercial reasons for running proxy chains in a Diameter
world.  i.e. organizations are planning on implementing proxy chains in
Diameter.

> not know of today.

  How can this possibly require domain-specific keys as the *source* of
domain-specific derived keys?

  Alan DeKok.

---

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Fri, 11 Jan 2008 01:02:21 -0500

At some point (San Jose Jan 2006) I remember the reason DSRK was
introduced was "to make the hierarchy symmetric for all domain".  I did
argue "who cares if the hierarchy looks ugly". We did also have a long
debate about how the SLAs could be violated if you send a usage
independent Domain key to a roaming partner that can potentially do
anything they want with that, so the example Dan says Russ has brought
up about roaming between operators without worrying about your bill
would actually turn into a nightmare, where one operator can simply
charge you an arm and a leg for things you were not entitled to in your
home domain, and your home operator would refuse to protect you.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 2:11 PM
To: Narayanan, Vidya
Cc: [email-masked]
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

<snip>

  Alan DeKok.

---

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

>   Authentication credentials are user names and passwords.  
> In RADIUS deployments (i.e. all common inter-ISP roaming), 
> those credentials are exposed to all proxies.  When you use 
> WiFi hotspots, those credentials are exposed to all proxies.  
> When you use any well-known corporate roaming for dialup 
> (historically), or other network access, those credentials 
> are exposed to all proxies.
> 

Could it be that you are talking about PAP?  I don't understand how/why
credentials may be exposed to intermediate parties in the case of EAP. 

Vidya

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 07:12:14 +0100

> credentials may be exposed to intermediate parties in the case of EAP. 

  Yes.

  I was addressing the comment that exposing credentials was a problem,
presumably from a non-technical standpoint (security, policies, etc.)

  Current accepted practice shows otherwise.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 22:20:25 -0800

Alan,

I was responding to your other email and then saw this one.  I deleted 
my long response.

I am sorry, but how does PAP fit into this exactly?  I am sorry to have 
wasted my time in a debate where you were making statements based on PAP.

best wishes,
Lakshminath

---

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

> Sent: Thursday, January 10, 2008 10:12 PM
> To: Narayanan, Vidya
> Cc: Dondeti, Lakshminath; [email-masked]
> > Could it be that you are talking about PAP?  I don't understand 
> > how/why credentials may be exposed to intermediate parties 
> in the case of EAP.
> 
>   Yes.
> 
>   I was addressing the comment that exposing credentials was 
> a problem, presumably from a non-technical standpoint 
> (security, policies, etc.)
> 

You are not serious that we should be basing our future designs on how
PAP works, are you?  If so, why move to EAP? If PAP is so acceptable, we
have nothing to do.  The IETF can shut down all work in the area of
access authentication. 

Vidya

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 07:34:17 +0100

Narayanan, Vidya wrote:
> PAP works, are you? 

  <sigh>  No.  I was trying to use analogy and reference.

  To repeat the discussion in short form:

 - DSRK's are necessary
 * Why?
 - to avoid exposing credentials across domains and proxies
 * So?
 - it would be catastrophic!
 * No, it's accepted practice in many areas, and has zero problems
 - you're proposing that we use PAP?
 * Huh?

  All of the arguments for "security" of the re-authentication keys are
to protect against attacks that no one cares about.  I referred to
existing practices as proof that those arguments were unfounded.  I did
NOT propose that we replace EAP with PAP, and it's fairly annoying that
my comments were read that way.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 22:48:14 -0800

Huh!  Weird misunderstanding then.  I was just losing my mind over this. 
  Oh well.  Let's try again then :).

I'll try your example.

Requirement: DSRKs are necessary
* Why?
 > Several reasons: Have a key in each domain to do local services. 
Reauthentication being one of them.  The USRK/rRK would provide such 
services at home; is not sent out of the home domain, so let's keep it 
that way.  Derive a key per domain and send it.
* Huh!  Let's say we trust proxies.  Why do I need to send a separate 
key per domain?
 > Well, there are reasons to do it.  <........> {Wrote that in another 
email}
* I don't want to do it.  I want to make things simple.
 > Ok, fine.  Let's have both options.  If you don't want to do it, just 
send a DSRK, the same one to any domain that asks for it.
* Why can't I send my USRK to all domains?
 > Well, the problem is for each service the key needs to be requested. 
  A one-time request is more efficient.

Is that a fair enough compromise?

Sorry if I used harsh words earlier.  I was really taken by the PAP 
references.

thanks,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Jan 2008 22:58:19 -0800

On 1/10/2008 10:34 PM, Alan DeKok wrote:

> to protect against attacks that no one cares about.  

  BTW, I am fine with proxies.  In fact, that's been my argument against 
mandating 3-party protocols etc.  On the other hand, I am not opposed to 
people developing them.  If people want to non-disruptively design 
protocols for a different threat model, I think we should let them. 
This is the IETF after all.  However, it would be good to prioritize for 
more immediate and practical needs: designing with proxies in mind is 
one example.  So, I also believe it is perfectly alright to design under 
a less than perfect threat model as long as we point out what could go 
wrong.  Along the way, it would also be good to design in a way that 
does not force us to redesign a lot when things change.

Along the way, we need to find a balance between all these design 
principles (and possible others).  It is hard work of course.

I am also a bit of a sucker for elegance.  Madjid said in one of his 
emails "I did
argue "who cares if the hierarchy looks ugly". "  Well, I have the 
opposite take.  I like pretty things :).

best,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 10 Jan 2008 23:01:24 -0800

> Sent: Thursday, January 10, 2008 10:34 PM
> To: Narayanan, Vidya
>   All of the arguments for "security" of the 
> re-authentication keys are to protect against attacks that no 
> one cares about.  I referred to existing practices as proof 
> that those arguments were unfounded.  I did NOT propose that 
> we replace EAP with PAP, and it's fairly annoying that my 
> comments were read that way.
> 

I'm really confused.  If there are no security issues with PAP and if
exposing the actual credentials to all proxies is just fine, why would
we need EAP?  Why is PAP not good enough? 

I'm sorry that you find it annoying to have this discussion.  If it is
any consolation, I find it equally annoying that we would use PAP as an
analogy and say that exposing credentials are fine. 

Vidya

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2008 17:14:19 +0100

> we need EAP?  Why is PAP not good enough? 

  Because it exposes credentials in the clear to *untrusted* parties.

  The first step of WiFi authentication using PAP is insecure (user ->
AP).  But after that, PAP authentication via *trusted* AAA proxies is
secure.  Existing AAA protocols ensure that the PAP credentials are
secured from *untrusted* parties.

  And no, I am *not* proposing that hokey uses PAP.

> analogy and say that exposing credentials are fine. 

  To *trusted* parties.  My example was about proxies with established
business relationships, *not* about exposing credentials to everyone.

  If you do not trust the proxies with the user's credentials, then you
have no reason to have a business relationship with them.  Businesses
exchange clear-text credentials all of the time (e.g. credit card
details).  This is NOT a technical problem, and it has NEVER been a
technical problem.  There are commercial and legal remedies to the theft
or abuse of credentials by trusted parties.

  If you do not trust the local server with the user's credentials, then
you do not trust it to cache the DSRK (almost by definition).   At that
point hokey becomes irrelevant.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 11 Jan 2008 10:06:30 -0800 (PST)

Hi Lakshminath,

On Thu, January 10, 2008 5:23 pm, Lakshminath Dondeti wrote:
> design.

  Thank you for your kind words. But I don't actually think things were
all wrong necessarily. I had an understanding that the peer would need
to authenticate "the network". I had an understanding that a 3 party
protocol would be needed to ensure that. Therefore, in my mind at least,
a key hierarchy was needed.

  But I had an epiphany in Vancouver. The peer _doesn't care_ about
authenticating "the network". He just wants service. That being the case
he doesn't care if his network access credential (that blob-of-bits that
he proves possession of to obtain network access) is shared between the
distributed entities that comprise "the network". That being the case the
key hierarchy becomes an unnecessary complexity.

  When I described this epiphany to Russ and others it came out as one
of "enterprise" versus "service provider" but I really believe the
distinction is whether the peer requires authentication of the entity
it is connecting to. If it does then I strongly believe a 3 party protocol
is needed, and a key hierarchy thefore makes sense; if it doesn't then
you don't need a 3 party protocol and you don't need a key hierarchy.

  I remember asking you in Vancouver when you thought a 3 party protocol
would be needed in HOKEY. You said, "never".

>          So, let me try another way.  Here is what is needed from the
> EMSK hierarchy.

  Right, we don't want to use the EMSK for HOKEY. So we can derive a
HOKEY key. Specific for allowing the peer to do handoffs. He proves
possession of the HOKEY key and he gets network access.

> * deliver domain specific keys so the domain servers can do the same thing

  Deliver the HOKEY key to the servers through normal AAA mechanisms.

                 EMSK
                   |
               HOKEY-KEY

> There are 2 levels in the key hierarchy.  The two reasons above explain

  Well you want to derive usage specific keys. That is the reason for
this key hierarchy. And the need for these usage specific keys is....
Well one of them is for handoffs. There is no justification for a
multiplicity of them though. So we have a need for one "usage specific"
key derived from the EMSK. Let's call that the HOKEY-KEY and get rid of
a whole layer of this key hierarchy. Then this DSUSRK stuff is next.

> able to make inferences about where the problem is.

  But this rRK business is from a different key hierarchy defined in a
different document, right? It's _below_ the whole EMSK-USRK-DSRK-DSUSRK
tree you drew above, right? So I don't really see how that justifies
all the cruft above it.

  regards,

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 11 Jan 2008 10:19:52 -0800

> tree you drew above, right? So I don't really see how that justifies

I will respond to the rest later Dan, but this caught my attention and I 
thought I should clarify quickly:

         EMSK
        /    \
   HOKEY-KEY  DSRK
              /
            HOKEY-KEY

So, we are only debating 1-level vs. and optional 2-level key hierarchy.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 11 Jan 2008 10:23:52 -0800

Hi Dan,

> 
>   But this rRK business is from a different key hierarchy 
> defined in a different document, right? It's _below_ the 
> whole EMSK-USRK-DSRK-DSUSRK tree you drew above, right? So I 
> don't really see how that justifies all the cruft above it.
> 
>   regards,
> 
>   Dan.
> 

Perhaps this is the crux of the misunderstanding.  The rRK is a USRK.
The EMSK hierarchy document just generically defines how USRKs are
derived, since multiple usages could define their own root keys.  For
reauthentication purposes, rRK is defined and it is defined in the ERX
document.  

The DSRK is also a USRK - just a special case, where instead of a
"usage", it is meant for another domain outside the home domain.  The
DSUSRK is a USRK specific to that domain - so, an rRK specific to a
domain would belong there.  

So, we have: EMSK --> rRK for the home domain and EMSK --> DSRK --> rRK
for a visited domain.  

The latter hierarchy for a visited domain allows other usage keys for
the local domain to come out of the DSRK, just like other usage keys for
the home domain can come from the EMSK.  This allows the distribution of
one key at the time of authentication that may then be used for various
service keying needs within the domain.  If we derived an rRK and
distributed that out, then, for every local service, a key must be
requested from the home domain and this is not desirable.  

Hope that clarifies things and brings us closer to being on the same
page. 

Regards,
Vidya

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Jan 2008 16:37:25 +0100

> that way.  Derive a key per domain and send it.

  My reading of the charter, and recent discussions, indicates that
HOKEY is intended to target re-authentication within one domain
(*.example.com), and not across domains (example.com -> example.net).
If so, then I would like to know more about the need for keys in
sub-domains, e.g. *.example.com.

  To a very large extent, the key distribution issue within example.com
is completely up to example.com.  HOKEY could simply say "example.com
caches the re-authentication key, and uses that to re-authenticate the
user".  The exact mechanism is implementation-dependent.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 16 Jan 2008 11:37:11 -0800

Hi Alan,

Sorry for the delay.  Some other IETF work preempted this discussion in 
my priority list.

The notion of domains and key delivery for different domains is in fact 
in the charter and there is even a specific deliverable:

Sep 2007	  	Submit Protocol and Keying Hierarchy for Visited Domain 
Handovers and Re-authentication draft to IESG.

BTW, I noticed that most if not all HOKEY deliverables are marked 
"Done."  It is really great to see that; kudos to the chairs and working 
group contributors for this achievement!

regards,
Lakshminath