Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM: EMSK Hierarchy Changes

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 14 Feb 2007 14:35:06 -0800 (PST)

Yoshi-

Of course, working on a single domain first is a roundabout way to drive the hierarchy the way you want it, that is, EMSK -> USRKs; No DSRKs (for now at least; and not directly from the EMSK). How about this: would you still be willing to work on developing protocols and hierarchies for a single domain if the root key is not specified? I don't see how that can happen.

So we should probably go back to the discussions/votes in SJ and in the light of new objections go through the entire motion again. 

Michaela

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Madjid Nakhjiri <[email-masked]>
Cc: Lakshminath Dondeti <[email-masked]>; M. Vanderveen <[email-masked]>; Sam Hartman <[email-masked]>; [email-masked]
Sent: Wednesday, February 14, 2007 2:28:58 PM
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM: EMSK Hierarchy Changes

I agree with Madjid.  

Re-authentication in visited domains has more AAA aspects than just
handover optimization.  It basically has not been cooked very well
yet.  I was questioning in details so many times from different angles
but no one does not seem to have a consistent answer.  I just think we
need more discussion on it.  My suggestion is the same as Madjid: work
on a single domain case or domainless structure first and then do
additional work on multi-domain case.

Note that I am not disagreeing with working on re-authentication in
visited domains.

Yoshihiro Ohba

On Tue, Feb 13, 2007 at 05:15:55PM -0800, Madjid Nakhjiri wrote:
> Well, Russ was not cced as you claimed, so I added him in, sorry Russ.
> 
> As long as we are working on requirements and limited security models, I
> take a look at the HOKEY charter items and see discussion on visited domains
> as deliverable 6, not delieverable 2 (EMSK hierarchy) and not deliverable 3
> (key hierarchy). 
> 
> Visited domain keys were brought in to "make the key hierarchy symmetrical",
> but significantly complicated the key hierarchy by adding a level. As a
> result we are now discussing domino effect and operator threat models,
> forgetting our reality check that people subscribe to an operator and an
> operator controls everything to protect its network and revenue. We are even
> suggesting a user moves from roaming partner to the next possibly without
> consent to its home operator and as a result we are moving further and
> further away from delivering a spec.
> 
> I am suggesting to take the visited domain consideration off from signaling
> and key hierarchy for the moment and just make derivation of USRK from EMSK
> directly and then look at visited domain on use case by use case basis
> (handover and roaming being one use case).
> 
> As far as I am concerned the consensus process that is being referred to
> here involves a mailing list consensus, which may not have been achieved
> yet.
> 
> At end, I am coming back to an old advice of do single domain first,
> multi-domain later. There was a reason visited domain was considered as a
> separate deliverable.
> 
> I like to hear what people think about this??
> 
> Madjid
> 
> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Monday, February 12, 2007 12:23 PM
> To: M. Vanderveen
> Cc: Sam Hartman; [email-masked]; [email-masked]
> Subject: Re: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes
> 
> Ok, thanks.  Normally correctness is associated with something else: for 
> instance, if we say we have a set of requirements and if we claim that a 
> protocol meets those requirements, then we should all be able to readily 
> verify that the protocol in fact does meet those requirements. 
> (Granted, we don't require proofs at the IETF). With that definition, 
> let's just say we want correctness. :)
> 
> On whether conformance (and I think that is what you are referring to as 
> correctness) to certain criteria is required, that is a different 
> matter.  We have consensus processes and we also have some guidelines we 
> generally are expected to follow.  I am afraid the "domino effect" falls 
> under "Section 3, Requirements" in Russ's document and not under 
> "Section 4, Recommendations," so we may not have a choice there.
> 
> I am CC'ing Russ and Sam so they can provide guidance.
> 
> I support the "required" aspect of the "domino effect" for the following 
> reason (this is one of many btw): consider ATM/Cash machines; suppose 
> compromise of a single ATM machine means compromise of all ATM machines 
> (that's what it would mean to not require prevention of domino effect on 
> edge entities of a secure system, in this case, a bank), then the 
> requirements for protecting the ATM machines will be formidable.  Each 
> would have to be protected as if a bank vault would be protected: 
> tamper-resistant to a serious degree, employing several (wo)men with 
> guns per ATM machine, etc.  (BTW, that is not so much of a fictional 
> thing; there were ATM machines in India, where there would be a 
> policeman per machine, although that is still not sufficient protection 
> in our hypothetical example).  In other words, for all practical 
> purposes, ATM machines cannot be ubiquitous with the model of security 
> in this paragraph.
> 
> In your example, could you elaborate on what the operators may believe 
> as more of a significant threat than a threat to their service model?
> 
> I have said this much, so let me say one more thing so we can get 
> something constructive from this.  Please propose a limited security 
> model and state the requirements within that model.  Selectable level of 
> security is something that I can appreciate, but let us at least apply 
> the correctness principle I talked about earlier.
> 
> thanks,
> Lakshminath
> 
> M. Vanderveen wrote:
> > Of course, it depends on what the threat model is, and therefore what is 
> > appropriate correctness matching that. For example, the operators may or 
> > may not believe that the "domino effect" is a significant threat 
> > compared to the other security threats they face. If they choose not to 
> > believe that for whatever reason (we won't go into that), they should be 
> > able to implement a solution that is correct to the extent of their 
> > threat model. Otherwise we're just doing a research exercise.
> > 
> > ----- Original Message ----
> > From: Lakshminath Dondeti <[email-masked]>
> > To: Dan Harkins <[email-masked]>
> > Cc: M. Vanderveen <[email-masked]>; [email-masked]; 
> > [email-masked]
> > Sent: Monday, February 12, 2007 10:30:22 AM
> > Subject: Re: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes
> > 
> > Yep, agreed.  It is one thing to say "let's not make things
> > unnecessarily complex" and an entirely another thing to say
> > "correctness" is a luxury.  Actually, Michaela, you may want to clarify
> > what you are saying.  Are you really saying correctness as a design goal
> > is too much to ask for?
> > 
> > There is definitely a middle ground and that comes from knowing why each
> > provision/technique in the protocols and key derivations we design
> > exists and being able to clearly explain what can be traded-off for
> > efficiency and at what cost.
> > 
> > Lakshminath
> > 
> > Dan Harkins wrote:
> >  >   I've also the opposite. Convenience trumps all and you end up with
> >  > something like WEP.
> >  >
> >  >   Nobody is suggesting we get carried away but if correctness is not
> >  > the goal then incorrectness will be the result.
> >  >
> >  >   Dan.
> >  >
> >  >> Agreed with Michael. We security people tend to get carried away with
> >  >> correctness and the like. End result is no one will implement our
> specs.
> >  >> I've seen this in practice..
> >  >>
> >  >> Michaela
> >  >>
> >  >>
> >  >> ----- Original Message ----
> >  >> From: "[email-masked]" <[email-masked]>
> >  >> To: [email-masked]; [email-masked]; [email-masked]
> >  >> Cc: [email-masked]; [email-masked]
> >  >> Sent: Monday, February 12, 2007 9:01:40 AM
> >  >> Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy
> Changes
> >  >>
> >  >>
> >  >> Colleagues,
> >  >>
> >  >> The mention of latency is refreshing. While we need excellent
> security,
> >  >> we must also make it possible for seamless mobility to be achieved. We
> >  >> can't count on MBB with huge handover time budgets to hide long SA
> setup
> >  >> times.
> >  >>
> >  >> Best Regards,
> >  >> Michael G. Williams
> >  >>
> >  >> -----Original Message-----
> >  >> From: ext Glen Zorn (gwz) [mailto:[email-masked]]
> >  >> Sent: Monday, February 12, 2007 7:30 AM
> >  >> To: Charles Clancy; Narayanan, Vidya
> >  >> Cc: [email-masked]; Madjid Nakhjiri
> >  >> Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy
> Changes
> >  >>
> >  >> Charles Clancy <mailto:[email-masked]> allegedly scribbled on
> Monday,
> >  >> February 12, 2007 5:28 AM:
> >  >>
> >  >>> My interpretation of the discussion is that we should do precisely as
> >  >>> you describe, except that the RADIUS keyreq packet contain a value
> >  >>> MIC'd by an authentication key derived directly from the EMSK (like
> >  >>> the rIK/rMSK relationship in EAP-ER), and that MIC'd value should
> >  >>> contain the channel binding info.  That way it channel bindings can
> be
> >  >>> explicitly validated prior to key distribution.
> >  >> This assumes a request for a key.  I had assumed that all keys would
> be
> >  >> delivered at the same time (e.g., in the RADIUS Access-Accept).  A
> >  >> separate key request would increase the latency of the
> reauthentication
> >  >> considerably, wouldn't it?
> >  >>
> >  >> ...
> >  >>
> >  >> _______________________________________________
> >  >> HOKEY mailing list
> >  >> [email-masked]
> >  >> https://www1.ietf.org/mailman/listinfo/hokey
> >  >>
> >  >> _______________________________________________
> >  >> HOKEY mailing list
> >  >> [email-masked]
> >  >> https://www1.ietf.org/mailman/listinfo/hokey
> >  >>
> >  >>
> >  >>
> >  >> 
> >
> ____________________________________________________________________________
> ________
> >  >> Need a quick answer? Get one in minutes from people who know.
> >  >> Ask your question on
> >  >> www.Answers.yahoo.com_______________________________________________ 
> >
> <http://www.answers.yahoo.com_______________________________________________
> />
> >  >> HOKEY mailing list
> >  >> [email-masked]
> >  >> https://www1.ietf.org/mailman/listinfo/hokey
> >  >>
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > HOKEY mailing list
> >  > [email-masked]
> >  > https://www1.ietf.org/mailman/listinfo/hokey
> >  >
> > 
> > 
> > ------------------------------------------------------------------------
> > Never Miss an Email
> > Stay connected with Yahoo! Mail on your mobile. Get started! 
> >
> <http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?promote=
> mail>
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
>

____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 14 Feb 2007 14:51:34 -0800

Hi Michaela,

I don't quite understand.  Why is working on a single domain is a
"roundabout" way? It is the most common case and it is less complex. Quoting
famous old timers: "Complexity can amplify small perturbations"

Also why do you think removing DSRK (which seems to be an unnecessarily
inflated necessity!) out of the key hierarchy causes the lack of root keys,
you just remove one level and derive the HRK (as a USRK) directly from EMSK.

Hate to sound like a pedantic, but there are no votes or motions in IETF:-),
it is just rough consensus and that needs to be called on the mailing list
not in the interim meetings. The best arguments I heard on DSRKs was to have
a symmetry on the key hierarchy, so that both visited and home domain key
hierarchies look the same. 

Where as we are sacrificing the whole service authorization model and
overseeing signaling (need for exchange of identities and consents for
handovers) and security issues (channel binding). Plus that I don't see how
you can do cross-domain handovers without consent of home domain and there
goes the symmetry out the door as well.

Finally, I have to go to every venue and say look to get keys for usage XYZ,
now you have to implement EAP, implement this complicated EMSK hierarchy,
derive per-domain keys and finally you get to your use case root key, and
that is just too hard of sell.

So yes, lets go through that decision again.

R,

Madjid

  _____  

From: M. Vanderveen [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 2:35 PM
To: Yoshihiro Ohba; Madjid Nakhjiri
Cc: Sam Hartman; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM:
EMSKHierarchy Changes

Yoshi-

Of course, working on a single domain first is a roundabout way to drive the
hierarchy the way you want it, that is, EMSK -> USRKs; No DSRKs (for now at
least; and not directly from the EMSK). How about this: would you still be
willing to work on developing protocols and hierarchies for a single domain
if the root key is not specified? I don't see how that can happen.

So we should probably go back to the discussions/votes in SJ and in the
light of new objections go through the entire motion again. 

Michaela

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Madjid Nakhjiri <[email-masked]>
Cc: Lakshminath Dondeti <[email-masked]>; M. Vanderveen
<[email-masked]>; Sam Hartman <[email-masked]>; [email-masked]
Sent: Wednesday, February 14, 2007 2:28:58 PM
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM: EMSK
Hierarchy Changes

I agree with Madjid.  

Yoshihiro Ohba

> >  >> https://www1.ietf.org/mailman/listinfo/hokey
<http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?promote
<http://us.rd.yahoo.com/evt=43909/*http:/mobile.yahoo.com/services?promote>
=
> mail>

  _____  

TV dinner still cooling?
Check out <http://us.rd.yahoo.com/evt=49979/*http:/tv.yahoo.com/>
"Tonight's Picks" on Yahoo! TV.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 14 Feb 2007 15:29:54 -0800

Madjid Nakhjiri wrote:
> Hi Michaela,
>
> I don’t quite understand.  Why is working on a single domain is a 
> “roundabout” way? It is the most common case and it is less complex. 
> Quoting famous old timers: “Complexity can amplify small perturbations”
> 
> inflated necessity!) out of the key hierarchy causes the lack of root 
> keys, you just remove one level and derive the HRK (as a USRK) directly 
> from EMSK.

Madjid,

Domain specific root keys is not an inflated anything.  It is in the 
charter and we all took a step back and looked at all the requirements 
and agreed that the key hierarchy would look better if we took all the 
requirements into consideration.

Think about this: the simplest way to support efficient reauthentication 
would be to use the EMSK as the root of the hierarchy, but that is 
clearly the wrong way to approach the problem.  There might be other use 
cases for the EMSK and so we have "usage" based "level" introduced into 
the hierarchy.  Likewise "domains" is another level introduced into the 
hierarchy (no need to repeat the case for it).  Given that we are going 
to support "domain-specific" derivation and "usage-specific" derivation, 
the DSRK key hierarchy is the most logical.

<snip>

> Where as we are sacrificing the whole service authorization model and 
No we are *not* sacrificing the "whole service authorization model."  A 
domain gets a key and manages its services.  Sounds perfectly logical to me.
> overseeing signaling (need for exchange of identities and consents for 
I am confused by the above phrase.  What are we overseeing?  And who 
needs to consent to what?
> handovers) and security issues (channel binding). Plus that I don’t see 
> how you can do cross-domain handovers without consent of home domain and 
> there goes the symmetry out the door as well.

A domain specific key has been handed out to the domain by the home and 
so there is "consent."  What are you looking for beyond that and under 
what threat model.  Please explain!  TIA.

> Finally, I have to go to every venue and say look to get keys for usage 
> XYZ, now you have to implement EAP, implement this complicated EMSK 
> hierarchy, derive per-domain keys and finally you get to your use case 
> root key, and that is just too hard of sell.

Like I said, the hierarchy is no more complex than it needs to be!

> So yes, lets go through that decision again.

So we go through decisions how many times?  Do you want the work to be 
done quickly or not?

regards,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 15 Feb 2007 13:40:21 -0800

Hi Lakshminath,

I am not going to respond line by line. I think I have given enough
consideration to the discussions already. BTW, If you had not snipped
through my email, you would see more explanation:

" The best arguments I heard on DSRKs was to have a symmetry on the key
hierarchy, so that both visited and home domain key hierarchies look the
same."
I already provided an answer to this argument.

To me handing a key to a different domain should be based on a specific
service, as roaming agreements are SLA specific. No operator will agree to
give all kinds of service to a user just because he is authenticated to a
home domain. In Dallas BoF people already indicated that tying EAP and
access service to other services suffers from a skewed business assumption
of having all services coming from the same provider, if we could not get
that pass IESG, how do you expect allowing "a visited domain to do anything
it want and then charge it to home domain" go through?

All along we have been arguing for having USRKs directly below EMSK. This
has the longest history in IETF, starting from AMSK specs off of EAP Keying.
The AMSK or USRK spec was supposed to deal with use of EMSK in generating
keys for a generic use case, not to deal with roaming.

Adding a completely new level between EMSK and USRK just to serve roaming
purposes seems excessive for usages that do not care about roaming.
Especially when the identity exchanges and channel binding is required to
make sure the keys are properly scoped to a proper domain, things get even
more complicated.

As for the charter, visited domain is chartered to be dealt with a later
date and as a separate deliverable, please look at the charter. Both first
and final drafts are separate and that was designed exactly with these
issues in mind.

Finally the decision was supposed to be discussed at the mailing list, this
is IETF procedure. We are already seeing both implicit and explicit
disagreements with this hierarchy.

Madjid  

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:30 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying
MITM:EMSKHierarchy Changes

Madjid Nakhjiri wrote:
> "roundabout" way? It is the most common case and it is less complex. 
> Quoting famous old timers: "Complexity can amplify small perturbations"
> 

Madjid,

<snip>

> handovers) and security issues (channel binding). Plus that I don't see 

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 14:32:04 -0800

Madjid,

On DSRKs, you say it is complex and I say it is simple.  You say you 
want to think and work on things sequentially and I say we need to keep 
the big picture in mind while we design the key hierarchy.  I will let 
the consensus process pick it up from there.

On business agreements and SLAs, we design protocols and mechanisms to 
facilitate various business models and SLAs.  The various use cases have 
been explained already.

regards,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 12:52:42 -0800

Lakshminath, 

I already explained that providing a single key to entire visited domain
violates the service model and DOES NOT support "various SLAs" as you claim.

This is about implementation and deployment simplicity. It is not about "you
say"  "I say". Plus people have already listed a lot of problems with the
signaling involved in creating keys for other domains.

I have already provided a suggestion (my email to Michaela) to deal with the
problem in a modular fashion.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 2:32 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/
lyingMITM:EMSKHierarchy Changes

Madjid,

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:01:26 -0800

Are you trying to use 2026 keywords ;) ?  DOES NOT is part of the 
keyword set there, btw.

Providing a root key to the visited domain and then putting a context 
(The manner in which the keying material is expected to be used from 
Russ's draft) on it will support any SLA you choose.  The root key 
delivered to the visited domain can be used for all kinds of services 
within the visited domain or just what the home thinks are right at the 
moment of key derivation and distribution, depending on the context.

Does that help?

cheers,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:11:21 -0800

The context IS the service. BTW, you can ask IESG to add IS to the 2026;)

Providing a key to the domain and do "all kinds of service" means exactly
the opposite of defining context for that key. "use for everything" is not a
usage context. Obscurity does not provide security.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 1:01 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel
binding/lyingMITM:EMSKHierarchy Changes

Does that help?

cheers,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:10:42 -0800

Madjid,

You say

"Plus people have already listed a lot of problems with the
signaling involved in creating keys for other domains."

Could you summarize the "lot of problems"?  Didn't we have a conclusion 
on that discussion and Sam asked Dan to review and suggest revisions to 
Russ's draft, if anything is needed.

What issues are remaining?  Let's resolve them.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:15:43 -0800

> usage context. Obscurity does not provide security.

Consider this Madjid: the authorizing domain says to the target domain 
when handing the key to knock itself out under the "agreement in place" 
and the agreement might be provide all services that the visited domain 
provides.  There is no obscurity here: all parties know exactly what the 
context is!

Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:29:39 -0800

Responding to these emails is time consuming enough, let alone summarizing
them. I think I have already covered a whole lot of those in various email,
so I rather not act as a secretary at this point and work on the solution
off or on list. 

I have also given an alternative to both of the initial proposals which seem
to be the middle ground and address the subject of this email.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 1:11 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Problems with creating keys for other domains?

Madjid,

You say

regards,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:35:19 -0800

Define "agreement in Place", please!

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 1:16 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains??
Channelbinding/lyingMITM:EMSKHierarchy Changes

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:38:35 -0800

> Define "agreement in Place", please!

The A in SLA.

But did you miss my point?  I am saying that the context is indeed clear 
to the parties involved.  Do you dispute that?

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:42:35 -0800

Madjid,

You are, as you say, one of the people who have been working in this 
space longer than many in this WG.  Are you saying you are planning to 
solve a problem that cannot even be easily summarized so we all 
understand what you/we are solving?

You may recall that I tried to summarize the problem.  Do you disagree 
with that summary or the conclusion thereafter?

thanks,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:47:28 -0800

Well, My question was about S and L:) i.e. a quantifiable SL in way that can
be used in key derivation/ context definition.

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 1:39 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains??

The A in SLA.

Lakshminath

>> the opposite of defining context for that key. "use for everything" is
not
> a

>>>> All along we have been arguing for having USRKs directly below EMSK.

> This

>>>> domain gets a key and manages its services.  Sounds perfectly logical
to
>>> me.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:56:06 -0800

Hi Lakshminath, 

I have not claimed that on this list.

But, Yes, The problem I am working on has been described in a pre-bof, 2
bofs, one WG meeting and in a similar number of problem statement and
finally by the problem statement plus an EMSK draft both now the WG
documents.

It is also covered in the charter. And that problem statement is different
from "a problem statement for your proposed solution". 

I am going to drop this, here.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 1:43 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: [HOKEY] Re: Problems with creating keys for other domains?

Madjid,

thanks,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 14:10:43 -0800

Sam,

I am trying to understand your note.

Let us consider the following: suppose the home authorizes the visited 
domain to use a root key in contexts A and B and communicates the 
context to the peer so the peer can compute the same key and use it in 
the given context (we will ensure a way to deliver the context intact to 
the peer, so there is no chance for a bad actor to modify the context en 
route).  The peer knows what contexts the visited domain root key or 
child keys thereof can be used under.  The context can be enforce 
cryptographically in multiple ways: key derivation that takes the 
context into account is one, end-to-end integrity protection of the 
context is another for example.

The part that I am not clear about is where "a bad actor could use a key 
out of context."  How is that possible?  Or, are you simply saying that 
we need to make sure that is not possible?

Could you please clarify?

thanks,
Lakshminath

Sam Hartman wrote:
> Mmm.  I think that the security properties of a model where the
> context is enforced cryptographically--that is where the visited
> domain does not have the necessary information to derive keys that
> could be used outside the intended context--are different from the
> security properties where a bad actor could use a key out of context.
> I think it is fair for Madjid to ask you to explore both of these
> properties while dealing with deliverable 6.
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 14:34:11 -0800

I am perfectly fine with cryptographically binding the key if it solves 
the problem you described.  Unfortunately, it doesn't.  If the peer and 
the visited domain work together to use a key out of context (i.e., they 
collude to do something), the home cannot stop it.  They could use any 
key they get from the home to establish a new key or authorize a new 
service between themselves and how can anyone stop that?

In fact, there may be realistic use cases which say otherwise.  Suppose 
a domain decides that it wants to provide access to (local) broadcast 
services to any authorized peer that is visiting.  Why disallow that? 
In fact, we cannot disallow it.

So, let me ask you the question; what does "harder" mean when you say 
"it's at least harder for the visited domain to use a key
out of context."

regards,
Lakshminath

Sam Hartman wrote:
> Well, in the case where a context is integrity protected, a peer and
> service in the visited domain could work together to use the key out
> of context.  I think that is a lot of Madjid's concern: he doesn't
> want the visited domain to be able to choose to violate a SLA.
> 
> IN the case where the context is cryptographically bound into the key
> derivation, it's at least harder for the visited domain to use a key
> out of context.  A peer could of course disclose a key.
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 16 Feb 2007 16:19:00 -0800

First, I think trying to take one existing model of SLAs or charging or
guessing how the future models of charging for services is going to work
is rather useless. The number of localized services is exponentially
increasing and it is not feasible to understand all of it today. So, it
would be short-sighted of us to use one model of SLAs and design key
management for it. Broadly speaking, two categories of roaming
relationships are feasible - generalized agreements that charge flat
fees or provide a defined set of services for authorized users and
service-specific agreements that do charging on a per-service basis.
While the fact really is that the former model is gaining more and more
popularity, with some specialized services being offered with
service-specific charging, it is also largely irrelevant to the
discussion here. The fact that there are various models feasible really
means that the work we do here must be independent of the charging model
and SLAs. 

Second, this isn't even about inter-administrative domains necessarily.
Providers that have large networks may want to segment their networks
into smaller local domains to be able to do faster handoffs or some
localized services. Two concrete "usages" in such a local intra-admin
domain would be, say, re-authentication and local IP mobility (say,
hierarchical Mobile IP) - it is all part of the same "administrative"
domain and keys are needed for both local re-authentication and local IP
mobility. Again, this is making a strong case for keeping the key
hierarchy independent of any inter-administrative relationships. 

Third, I think this is easy to do and has been demonstrated. As we have
discussed a lot already, the "context" can be anything the peer and
server agree to - for instance, the "context" could be "everything and
anything" if the server is willing to say that! It is important that the
peer and the server have a common understanding of what that "context"
is. We specifically discussed this at the Interim meeting and Russ
explained how the "context" could be "local domain services" instead of
"local domain re-authentication". 

So, the point is that the DSRK is cryptographically and by definition,
bound to a "domain" or a "server" by inclusion of the appropriate domain
name or server ID in its derivation. The general idea is that the server
will still be able to specify more constrained context, if it wants to -
that can be achieved via the "optional data" or as additional attributes
sent to the local server and the peer, for instance. 

One important thing to also remember is that, as Lakshminath points out
below, while such context can be specified, if the local server and the
peer wish to violate that context, there is nothing the home server can
do, given that it is outside the path of the communication between the
peer and local server. So, the only thing that can be ensured is that
all the parties have the same notion of "context".  

Given all of this, we should not be hung up on inter-admistrative
models, let alone specific SLAs or charging models. We have a way to do
this generically and ensure the parties involved have a common
understanding of the "context", whatever it may be. So, that really
seems to me like the way to go. 

Vidya

> Sent: Friday, February 16, 2007 2:34 PM
> To: Sam Hartman
> I am perfectly fine with cryptographically binding the key if 
> it solves the problem you described.  Unfortunately, it 
> doesn't.  If the peer and the visited domain work together to 
> use a key out of context (i.e., they collude to do 
> something), the home cannot stop it.  They could use any key 
> they get from the home to establish a new key or authorize a 
> new service between themselves and how can anyone stop that?
> 
> In fact, there may be realistic use cases which say 
> otherwise.  Suppose a domain decides that it wants to provide 
> access to (local) broadcast services to any authorized peer 
> that is visiting.  Why disallow that? 
> So, let me ask you the question; what does "harder" mean when 
> you say "it's at least harder for the visited domain to use a 
> key out of context."
> 
> regards,
> Lakshminath
> 
> Sam Hartman wrote:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Feb 2007 20:30:13 -0500

Vidya,

Thank you for the detailed explanation.  I think I read your email
carefully.  Even after that, my opinion is the same as Madjid: work on
single-domain first.  Please see my comments below.

> increasing and it is not feasible to understand all of it today. So, it

If it is not feasible to understand all of it today, I believe it is
very hard for us to agree on DSRK now.

> means that the work we do here must be independent of the charging model

The fact that there are various models feasible does not justify the
use of DSRK because there is no explaination on how DSRK can be really
independent of the charging model and SLAs without understanding them.

> hierarchy independent of any inter-administrative relationships. 

This does not justify the use of DSRK either, because the same goal
can be achieved without DSRK.  Need for a key hiearchy does not mean
need for DSRK.

> "local domain re-authentication". 

However, this does not justify the need for DSRK immediately below
EMSK.  We can achieve the same goal by defining a USRK for "local
domain services for any domain" and then define DSRK under the USRK.
There is no need to mandate DSRK for a AAA deployment that does not
provide "local domain services".

> sent to the local server and the peer, for instance. 

Again, this does not justify the need for DSRK immediately below EMSK.

> all the parties have the same notion of "context".  

If the local server and the peer wish to violate that context, then
there is no need for them to talk to the home domain or perform
authentication and authorization for the violated context at all.
What is the point here?

> seems to me like the way to go. 

I don't understand how you can conclude that way, based on my comments
above.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 16:24:12 -0500

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> Are you trying to use 2026 keywords ;) ?  DOES NOT is
    Lakshminath> part of the keyword set there, btw.

    Lakshminath> Providing a root key to the visited domain and then
    Lakshminath> putting a context (The manner in which the keying
    Lakshminath> material is expected to be used from Russ's draft) on
    Lakshminath> it will support any SLA you choose.  The root key
    Lakshminath> delivered to the visited domain can be used for all
    Lakshminath> kinds of services within the visited domain or just
    Lakshminath> what the home thinks are right at the moment of key
    Lakshminath> derivation and distribution, depending on the
    Lakshminath> context.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 17:22:54 -0500

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> Sam, I am trying to understand your note.

    Lakshminath> Let us consider the following: suppose the home
    Lakshminath> authorizes the visited domain to use a root key iom: Sam Hartman <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 10:48:44 -0500
Cc: [email-masked]
Subject: [HOKEY] Re: Incorrect delivery of a DSRK

Yes.  Also, consider an 802.11 network that does not carry IP traffic.
In that environment, link security may well be important.

The point is that people build link encryption on top of EAP so we
better not break it.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 17:22:54 -0500

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 17:22:54 -0500

Lakshminath> Let us consider the following: suppose the home
    Lakshminath> authorizes the visited domain to use a root key in
    Lakshminath> contexts A and B and communicates the context to the
    Lakshminath> peer so the peer can compute the same key and use it
    Lakshminath> in the given context (we will ensure a way to deliver
    Lakshminath> the context intact to the peer, so there is no chance
    Lakshminath> for a bad actor to modify the context en route).  The
    Lakshminath> peer knows what contexts the visited domain root key
    Lakshminath> or child keys thereof can be used under.  The context
    Lakshminath> can be enforce cryptographically in multiple ways:
    Lakshminath> key derivation that takes the context into account is
    Lakshminath> one, end-to-end integrity protection of the context
    Lakshminath> is another for example.

    Lakshminath> The part that I am not clear about is where "a bad
    Lakshminath> actor could use a key out of context."  How is that
    Lakshminath> possible?  Or, are you simply saying that we need to
    Lakshminath> make sure that is not possible?

n
    Lakshminath> contexts A and B and communicates the context to the
    Lakshminath> peer so the peer can compute the same key and use it
    Lakshminath> in the given context (we will ensure a way to deliver
    Lakshminath> the context intact to the peer, so there is no chance
    Lakshminath> for a bad actor to modify the context en route).  The
    Lakshminath> peer knows what contexts the visited domain root key
    Lakshminath> or child keys thereof can be used under.  The context
    Lakshminath> can be enforce cryptographically in multiple ways:
    Lakshminath> key derivation that takes the context into account is
    Lakshminath> one, end-to-end integrity protection of the context
    Lakshminath> is another for example.

    Lakshminath> The part that I am not clear about is where "a bad
    Lakshminath> actor could use a key out of context."  How is that
    Lakshminath> possible?  Or, are you simply saying that we need to
    Lakshminath> make sure that is not possible?

n
    Lakshminath> contexts A and B and communicates the context to the
    Lakshminath> peer so the peer can compute the same key and use it
    Lakshminath> in the given context (we will ensure a way to deliver
    Lakshminath> the context intact to the peer, so there is no chance
    Lakshminath> for a bad actor to modify the context en route).  The
    Lakshminath> peer knows what contexts the visited domain root key
    Lakshminath> or child keys thereof can be used under.  The context
    Lakshminath> can be enforce cryptographically in multiple ways:
    Lakshminath> key derivation that takes the context into account is
    Lakshminath> one, end-to-end integrity protection of the context
    Lakshminath> is another for example.

    Lakshminath> The part that I am not clear about is where "a bad
    Lakshminath> actor could use a key out of context."  How is that
    Lakshminath> possible?  Or, are you simply saying that we need to
    Lakshminath> make sure that is not possible?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 18:27:44 -0500

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> So, let me ask you the question; what does "harder"
    Lakshminath> mean when you say "it's at least harder for the
    Lakshminath> visited domain to use a key out of context."

Less likely to be supported by client software, requires new exchanges
to get the key which are not likely to be interoperable, etc.

So, no, not harder in a security sense, but potentially harder in an
operational sense.

I'm not going to spend a lot of time defending that viewpoint, but I
do think it is important for you to understand why people might
believe that.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 23:45:55 -0800

Sam,

I understand what you are saying and here is an example where 
cryptographic binding may be useful: In one of the variations (the one 
in which the inner authentication is never run outside of a secure 
tunnel) of the MiTM attacks on tunneled authentication protocols, N. 
Asokan et. al., explain that it is plausible to mitigate the attack if 
the client/peer verifies the server's certificate properly, but it is 
safer, along the lines you mention below, to bind key material of the 
inner and outer authentication protocols.  I can appreciate 
cryptographic binding is the proper recommendation in that case.

Unfortunately I don't see how cryptographic binding helps in case of 
context binding in all cases.  In fact, whether there is cryptographic 
binding or not, the peer would need to verify whether the root key that 
the visited domain receives is being used within the context.  If there 
is any tangible benefit -- as in the example in the first paragraph -- I 
would really like to know.

What am I missing?

thanks Sam,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 15:47:37 -0800

I am going to focus on just the single administrative domain case here.
Within anadminstrative domain, there are no SLAs, no charging, etc. 
 
> > domain and keys are needed for both local re-authentication 
> and local 
> > IP mobility. Again, this is making a strong case for 
> keeping the key 
> This does not justify the use of DSRK either, because the 
> same goal can be achieved without DSRK.  Need for a key 
> hiearchy does not mean need for DSRK.

Let's take this basic use case above, where there is a large provider
network that is segmented into smaller local domains, each of which has
its own AAA/HOKEY server. Let's say, there is also a local mobility
management entity within each of these domains (say, an HMIP MAP). This
is all part of one big administrative domain. The MN needs to be able to
re-authenticate within one of those domains and also be able to perform
HMIP signaling with the MAP. Keys are needed for both. When a DSRK is
available, that will be sent to the local domain AAA server at the end
of the initial EAP or HOKEY exchange with the home server. After that,
the MN can re-authenticate to the local HOKEY server using a USRK that
was derived from the DSRK. Subsequently, the MN may use another USRK
derived from that DSRK for protection of HMIP signaling with the MAP.
The MAP would be able to retrieve the key from the local AAA server.
This part is certainly not something that HOKEY is specifying now, but,
it is a perfectly valid use case for future extensibility of the keying
hierarchy. 

Now, if the DSRKs are not available, the MAP would need to go to the
home AAA server to retrieve a USRK (actually, the USRK would have to be
sent to the Local AAA server after which a key derived from that would
have to be sent to the MAP) at the time of HMIP signaling. This is
completely unnecessary to do within the same administrative network
(also unnecessary in several models of inter-administrative networks,
but, let's first talk about the same administrative network case). 

So, this strongly justifies the use of DSRKs as far as I can tell.
Please let me know how you think the same can be achieved without the
DSRK. 

Thanks,
Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 13:15:28 -0500

Vidya,

Your scenario does not justify DSRK (or even a key hierarchy below
USRK in the current EMSK key hierarchy may not be needed).  I would
argue that we can simply use cross-realm Kerberos here.  There is no
need for the local MAP in each sub-domain to communicate with the home
AAA server to retrieve keys.  What is needed here is cross-realm keys
between each sub-domain and the parent domain to generate cross-realm
tickets used by the TGS in each sub-domain to generate necessary
service-specific keys.  If we talk about future extensibility outside
the scope of HOKEY, I believe that it is much better to consider
Kerberos for single-sign-on and a defined a USRK for Kerberos.  This
is another reason for me to disagree with defining DSRK as an
immediate child key of EMSK.

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 21 Feb 2007 11:23:07 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Wednesday, February 21, 2007 10:15 AM:

> argue that we can simply use cross-realm Kerberos here.  

You might be right, except for a couple of things (see below).

>There is no
> need for the local MAP in each sub-domain to communicate with the
> home AAA server to retrieve keys.  What is needed here is cross-realm
> keys between each sub-domain and the parent domain to generate
> cross-realm tickets used by the TGS in each sub-domain to generate
> necessary service-specific keys.  

AFAIK, Kerberos service tickets are actually _server_ tickets.  I've
lobbied the IETF Kerberos folk in the past for the acceptance of actual
service tickets (e.g., a single ticket for fast hand-off or network
access, etc. in a realm without success; if this is now acceptable, I'd
be both pleased and surprised.  If not, then this implies that the user
needs to know the actual name of the access point in order to request a
ticket for it.  My guess is that this is a non-starter.

> If we talk about future
> extensibility outside the scope of HOKEY, I believe that it is much
> better to consider Kerberos for single-sign-on and a defined a USRK
> for Kerberos.  

I'm more interested in current deployability than future extensibility
and from that POV Kerberos is a non-starter.  

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 15:55:58 -0500

On Wed, Feb 21, 2007 at 11:23:07AM -0800, Glen Zorn (gwz) wrote:

(snip)
> ticket for it.  My guess is that this is a non-starter.

You are right, the tickets are server tickets, not service tickets (I
should have been more careful about wording).  On the other hand,
given that each service is associated with a server, we could use
server tickets for service-bootstrapping purpose.

> and from that POV Kerberos is a non-starter.  

My whole point is that, if people want DSRK from current deployability
point of view, DSRK should not be defined as an immediate child key of
EMSK.  Just define a new USRK as a root key for key-hierarchy-based
domain-specific things.  This also allows future extensibility to
define another USRK for Kerberos-based single sign-on.

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 21 Feb 2007 13:03:40 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Wednesday, February 21, 2007 12:56 PM:

...
> server tickets for service-bootstrapping purpose. 

I'm not sure how a user/MS/whatever would know, in general, the name of
the server to which it is attempting to move (nor, actually, why that
would be desirable).  What am I missing here?
 
...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 16:39:35 -0500

> would be desirable).  What am I missing here?

The user/MN/client/whatever has to know the identity of the server
that is supposed to hold a key from key management perspective
regardless of the service.  I would be surprised if a "service" is
treated as a party that holds a key.  Perhaps the push-back you got
from Kerberos people would be related to this.

In general key-holder discovery has to be solved but it does not have
to be integral part of a key distribution protocol.  You could use
whatever discovery protocol that is appropriate.  For example, I can
think of IEEE 802.21 Information Service as a mechanism to discover
key-holders.

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 21 Feb 2007 14:16:26 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Wednesday, February 21, 2007 1:40 PM:

...

>> I'm not sure how a user/MS/whatever would know, in general, the name
>> of the server to which it is attempting to move (nor, actually, why
>> that would be desirable).  What am I missing here?
> 
> regardless of the service.  

If that's true, why does EAP work?

> I would be surprised if a "service" is
> treated as a party that holds a key.  

Really?  Seems like virtually every currently (& soon to be) deployed
service that includes any form of roaming (e.g. 3G mobile telephony,
WiMax, etc.) uses exactly that model.  The idea that the identity of
every PDSN/GGSN/ASN needs to be known (let alone verified) by a
mobile/user is just absurd from both the usability and management
standpoints.

> Perhaps the push-back you got

Perhaps.  It may also help to explain the wildly enthusiastic acceptance
of Kerberos outside the academic community, despite the support of
Microsoft ;-).  Say what you will about Microsoft, but if they can't
sell it, it probably can't be sold...having said that, though, I really
like Needham-Schroeder based protocols, including Kerberos.  If I
seriously though that specifying the usage of Kerberos in hokey would
result in it's popularization I would strongly support it.
Unfortunately, I think that doing so would simply guarantee the
irrelevance of our work.

> 
> In general key-holder discovery has to be solved 

Why?

> but it does not have
> to be integral part of a key distribution protocol.  

> You could use

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 21 Feb 2007 15:19:21 -0800

First, to answer to your comments, no operator would give you flat fee, if
they know you would be using anywhere near the upper bounds of usage that
they are telling you. In fact, for phone service, you have multiple levels
of flat fees depending on usage and for Internet, the operator simply
provisions your neighbors so you never hit the peak bandwidth or top bytes
downloaded.
The roaming agreements are tightly knit based on type of service. 

Yes, a single large operators is a good case, however, 
About a month ago, I pointed out my experience with seamoby where we argued
multi-domain and fancy requirements for 6 months, everybody lost steam and
the work stopped for another 6 months. Lets not do that here.

I think my suggestion on combining DSRK and USRK into one key derivation is
a good middle ground, sure it may increase initial provisioning time, but it
does not affect real time application performance.

Finally, the charter was debated extensively and designed taking all
existing and future models into account. The future that you are talking
about can wait another 6 month to be provisioned with deliverable 6.
This group formation was inspired not by visionary ideologies but by a
couple of very concrete problems in WiMAX. We have been debating charters
for a year, while WiMAX has gone and designed its own architecture. In fact
it is pretty hard today to go to SDOs and ask them to replace their MSKs
with another per-authenticator key, let alone ask them to derive yet another
level of hierarchy just in case somebody wants to do roaming.

Madjid
-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 4:19 PM
To: Dondeti, Lakshminath; Sam Hartman
Cc: [email-masked]; Madjid Nakhjiri
Subject: Local Domain Services, SLAs, Charging, Keys,Etc. (was RE: [HOKEY]
why visited domains?? )

Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 18:27:46 -0500

> If that's true, why does EAP work?

EAP keying framework has a bunch of text on Server-Id.

> mobile/user is just absurd from both the usability and management

I don't know whether every PDSN/GGSN/ASN holds a key, so I cannot
answer.  But if an entity is supposed to hold a key then its identity
needs to be known to the parties that are involved in key distribution
in principle.

> result in it's popularization I would strongly support it.

I am also having a hope in Needham-Schroeder based protocols for both
security and optimization perspective.  I would also strongly support
it.

> Unfortunately, I think that doing so would simply guarantee the

If handover keying is based on Kerberos or alike, I believe it is
relevant to our work.  This is one reason for why I am suggesting
separation of re-auth and handover keying.

> > In general key-holder discovery has to be solved 

For the same reason as EAP works without having EAP authenticator
discovery in integral part of EAP.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 21 Feb 2007 17:44:39 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Wednesday, February 21, 2007 3:28 PM:

...

>>>> I'm not sure how a user/MS/whatever would know, in general, the
>>>> name of the server to which it is attempting to move (nor,
>>>> actually, why that would be desirable).  What am I missing here?
>>> 

The EAP Keying Framework has yet to be published; I'm unaware of any
implementations.  In any case, 1) for all existing IETF-published EAP
methods except EAP-SAKE the Server-ID is defined to be an empty string
and 2) although the term is not completely defined, my best guess is
that "Server-ID" refers to the EAP server which most likely resides
behind a AAA server somewhere, not in the NAS to which you are
attempting connection.

...

>> Perhaps.  It may also help to explain the wildly enthusiastic
>> acceptance of Kerberos outside the academic community, despite the
>> support of Microsoft ;-).  Say what you will about Microsoft, but if
>> they can't sell it, it probably can't be sold...having said that,
>> though, I really like Needham-Schroeder based protocols, including
>> Kerberos.  If I seriously though that specifying the usage of
>> Kerberos in hokey would result in it's popularization I would
>> strongly support it. 
> 
> relevant to our work.  

I'm sorry, I wasn't clear: I believe that specifying Kerberos for any
purpose in hokey will _make_ our work irrelevant.  We may as well fold
our tents & go home.

...

> discovery in integral part of EAP. 

Sorry, I don't understand.

...

---

From: Saber Zrelli <[email-masked]>
Date: Thu, 22 Feb 2007 14:10:59 +0900

Hi Glen,

> purpose in hokey will _make_ our work irrelevant.  We may as well fold

I would like to know why do you think that specifying Kerberos for any
purpose in hokey will make the work in HOKEY irrelevant.

IMHO this depends on how you use Kerberos for HOKEY. I believe that the
proper use of Kerberos can be THE solution for HOKEY wg.

So far, the main issue with Kerberos for network access control is
related to its vulnerability against dictionary attack due to weak, user
chosen passwords. However, in HOKEY as I see it, there are no user
chosen passwords, and therefore IMHO there are no reasons why exclude
Kerberos from the solution space.

One possible use of Kerberos could be as follows :
Upon successful EAP authentication, a new Kerberos principal is created
in the KDC. The name of this principal corresponds to the Identity of
the EAP peer. The password of this new principal corresponds to a USRK
generated from the EMSK. Now this client can get service tickets for
different access nodes without calling home again.

Regards,
Saber.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Feb 2007 14:07:07 -0500

Sorry for my delayed response.

> behind a AAA server somewhere, not in the NAS to which you are

Yes, "Server-Id" refers to the EAP server.  The identity of the NAS is
authenticator id which is also discussed in EAP keying framework.

> purpose in hokey will _make_ our work irrelevant.  We may as well fold

I think it depends on the ongoing 3-party key distribution issue...

> Sorry, I don't understand.

Sorry I was not clear.  For example, EAP authenticator discovery has
to be solved to make EAP work but it does not have to be solved within
EAP (lower-layer can solve it).  Similary, key-holder discovery has to
be solved for a key distribution protocol to work but it does not has
to be solved within the key distribution protocol.

Yoshihiro Ohba