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

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Feb 2007 14:06:38 -0800 (PST)

Hi Lakshminath,

  A simple key derivation that includes a server or domain name will
provide for key separation. If we cannot guarantee that the a key
will never be given to the wrong entity then we don't have "sufficient
security". (I also don't think we'll necessarily have "sufficient
security" if we have that guarantee either but we'll definitely be
closer to that goal).

  Fixing the AAA model or the EAP model may not be the right way to go,
as you indicate, but if there are problems with using them in HOKEY
then they should not be used. Or if there are things we need to do in
HOKEY so that we can use them then we must do them. As I have stated
repeatedly in this thread we can't take a model built on a 2 party
protocol and apply it to a 3 party protocol and say "all done".

  Dan.

P.S. you still missed Russ in the cc list. I've added him. Hi Russ!

> Sorry for the oversight in not cc'ing Russ.  I was going yo when the
> issue about domino effect came about.
>
> Let's try and get back on track here: There would have been a
> domain-specific key derivation somewhere in the key hierarchy, that
> could have been part of deliverable 2 or deliverable 6.  At the meeting
> in San Jose, we had rough consensus on having symmetry in the key
> hierarchy, so things got shuffled a little bit.  We are in the middle of
> discussing that and along the way, I didn't learn anything new actually;
> a simple derivation that binds the server or domain id/name provides
> sufficient security; I haven't seen any real problems with that
> derivation so far.
>
> Now, if we delve into fixing the AAA model or the EAP model, sure, we
> will have problems.  As long as we don't go there, we will be in decent
> shape.
>
> regards,
> Lakshminath
>
> 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
>

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

---

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

> will never be given to the wrong entity then we don't have "sufficient

Dan,

The disconnect between us as I see it is on what happens when the key is 
given to the wrong entity?  What are the implications?

Let us define the "wrong" entity and discuss who is lying to whom and 
what do they get out of it?  Could you reset the thread and explain that 
please?

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Feb 2007 16:23:44 -0800 (PST)

Hi Lakshminath,

  I am detecting a denial-of-service attack here :-)

  I have explained numerous times in this thread what the implications
are if the wrong entity is given a key. For example, my post with message
ID <[email-masked]>. Search for
"You seem to be forgetting...."

  Also this thread has a very nice discussion about who the "wrong"
entity is and who is lying to whom. For example, my post with message ID
<[email-masked]> and also message
ID  <[email-masked]>.

  This reminds me of "Question Time" with the Prime Minister. So let me
quote Tony Blair as he step to the podium: "I refer the right-honourable
gentleman to the answer I gave some moments ago." I respectfully request
you respond to the posts noted above if you wish to reset this thread.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 14 Feb 2007 19:04:24 -0800

Dan,

Thanks for the pointers.  There has been a recent custom in the IETF 
where people ask for a summary so we can have productive discussions and 
that's all I was asking for.  There is no other intention.

I will start with one question: do you agree that the goal here is to 
work within the scope of RFC 3748 and EAP-Keying framework and extend 
those notions to support reauthentication?

++++++++
You said:

You seem to be forgetting that this is a _symmetric_ credential that the
peer uses for network access. If ISP2.net obtained the key that the peer
should be using when talking to ISP1.net that allows ISP2.net to
impersonate the peer to ISP1.net. If and when the peer attempted to
legitimately connect to ISP1.net it would allow ISP2.net to decrypt all
its traffic, inject bogus traffic into the flow, and do all sorts of
nastiness.
+++++++++

We are talking about access authentication here.  The goal is to protect 
access network resources.  Confidentiality, integrity and replay 
protection of data is out of scope.  Do you agree?  What is the other 
sorts of nastiness that we should be worried about and on whose behalf?

I have for the purposes of this discussion a rather simplistic view of 
the threat model.  An access network provider wants to provide network 
access to users that roam into his/her network and get paid for it.  The 
payment arrangements are done through accounting and are facilitated by 
the AAA framework.

So, the only problem I see in the scenario you explained is that 
ISP2.net may get free service at ISP1.net, with a peer getting charged 
for it.  Can we agree that is the extent of the problem and not more?

Now let's look at the "cause" of the problem: ISP2.net being able to 
request and receive ISP1.net's DSRK.  So, let's frame some requirements 
to make sure that does not happen.  How about these:

1. "A HOKEY client SHOULD be able to detect change of the local AAA 
server and/or local HOKEY server."

2. "Every request for a DSRK MUST produce a new, unique DSRK."

3. "DSRK delivery SHOULD occur with peer involvement."

These requirements ensure that no two entities can ever get the same 
DSRK, irrespective of whether it is feasible to impersonate a NAS or 
HOKEY server.  Can we agree to these and move forward please?

thanks,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 07:23:47 -0800

Sam,

I am the one saying that data integrity and confidentiality of user data 
are not the goals of access authentication.  Sure, some networks claim 
that it is a feature (and that is a debate I have been engaged in for a 
long while in case of 3GPP and 3GPP2 networks, where encryption alone is 
used to enforce access authentication; no integrity protection 
afforded), and in fact there is a more nuanced take on how to exactly 
provide access control in wireless networks.  Here goes: For uplink 
traffic, integrity protection is alone sufficient whereas for downlink 
traffic, one could make the argument that integrity plus confidentiality 
may be required.  The argument goes like this: we want the authenticated 
receivers alone to get the benefits of accessing the network whatever 
that benefit is; if the data is in the clear, other receivers may get 
those benefits too.  I'd say that if any of the data (service) is 
valuable, that should be encrypted from server to client.

Now, as to confidentiality and integrity of data, that is an end-to-end 
affair, at least from the user's perspective and that holds true in 
service providers' networks without a doubt and that is the context.

Now you bring up a point that in some networks, corporate networks, it 
may be a requirement from the corporation's point of view that the data 
be protected on the wireless link(s) (I guess with the premise that 
security beyond wireless links, presumable the weakest link, is ensured 
by walls and people who barely check badges).  There are of course 
problems with that notion: How does a mobile device know that it is 
associating with a wireless AP from its own corporation?  It cannot 
always know for sure that based on any of the EAP and related standards 
we have already written at the IETF.

regards,
Lakshminath

Sam Hartman wrote:
> I'm jumping into this late, and not sure who is quoting who and have
> not read the messages in the thread.
> 
> Depending on the scope of the discussion, I may strongly disagree that
> we're only worried about network access and that integrity and
> confidentiality are out of scope.  For 802.11 networks it is clear
> that integrity and confidentiality of corporate networks definitely
> are in scope for 802.11i's use of EAP.
> 
> So unless you have some significant constraints here (and I don't
> think supporting visited domains is good enough to give you the
> constraints you want), confidentiality and integrity may be in the
> threat model of some deployments.
> 
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 15 Feb 2007 08:01:09 -0800 (PST)

Hi Lakshminath,

  I think the quote Sam is referring to is this:

      We are talking about access authentication here.  The goal is to
      protect access network resources.  Confidentiality, integrity and
      replay protection of data is out of scope.  Do you agree?  What is
      the other sorts of nastiness that we should be worried about and on
      whose behalf?

I believe that even if your sole concern is access authentication that
you must also require data integrity protection otherwise the session
can be hijacked. But quibbling over what sorts of protections you value
seems like a waste of time.

  The issue is that the key is a _symmetric_ network access credential.
It is supposed to uniquely identify the peer to the network. If you cannot
guarantee that this key will not be delivered to the wrong entity then
anything you intend to use it (or any derivative of it) for is now
questionable. If the only thing you care about is access authentication
then fine, you can't use the key if you can't guarantee it won't be
delivered to the wrong entity. If you care about anything else (and I
really think you should) then you still can't use the key if you can't
guarantee it won't be delivered to the wrong entity.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 08:55:06 -0800

Sam,

The vulnerability I talked about applies to link encryption also.  We 
can debate, but I don't want to hold up a HOKEY discussion for this meta 
issue.  Let me revise my initial email on this topic.

regards,
Lakshminath

Sam Hartman wrote:
> 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: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 09:01:26 -0800

Dan Harkins wrote:
> can be hijacked. 

Surely I understand that integrity protection is required until the link 
termination point and that is to prove that the parties to the initial 
authentication are in fact the communicating entities.  There is no user 
data integrity in the end-to-end sense and that is what I am getting at. 
  I am sorry if that was unclear (I thought I was careful enough when I 
wrote it; but I guess I need to be more careful).

> But quibbling over what sorts of protections you value

Here I strongly disagree with you.  It is one thing to say that the 
security model and requirements are the same and that a superset of the 
threat model I described can be addressed with the same mechanisms, but 
it is entirely different thing to say that we don't need to know what 
sort of protections we are getting.  We better know precisely. 
Otherwise, why bother with this level of discussion?

> guarantee it won't be delivered to the wrong entity.

Let us write this up as a set of requirements and that is what I was 
attempting to do with my earlier email.  Let me revise that and send so 
we can move forward here.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 12:57:38 -0800

Hi Dan,
 
> I believe that even if your sole concern is access 
> authentication that you must also require data integrity 
> protection otherwise the session can be hijacked. But 
> quibbling over what sorts of protections you value seems like 
> a waste of time.
> 

Are you suggesting that having a clear threat model and set of security
requirements emanating from that threat model is a waste of time? I hope
not, but, I'd like to understand your take anyway. 

Thanks,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 13:58:09 -0800

Agreed that it is not about what protections one person considers
important. However, I don't understand what "common protections" are -
there must be a clear threat model and a clear set of requirements that
need to be met. Otherwise, we are just shooting in the dark and no one
knows what we are designing for. Based on the fact that this is intended
to be an extension to EAP, we've identified the security requirements in
draft-ietf-hokey-reauth-ps; in fact, a lot of the high level
requirements are covered in the charter itself. So, we should look at
that and figure out if something else is missing based on the relevant
threat model. 

Do you agree? 

Vidya 

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 1:29 PM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Dondeti, Lakshminath; [email-masked]
> Subject: Re: [HOKEY] Re: Incorrect delivery of a DSRK
> 
> >>>>> "Narayanan," == Narayanan, Vidya <[email-masked]> writes:
> 
>     Narayanan,> Hi Dan,
>  
>     >> protection otherwise the session can be hijacked. But quibbling
>     >> over what sorts of protections you value seems like a waste of
>     >> time.
>     >> 
> 
>     Narayanan,> Are you suggesting that having a clear threat model
>     Narayanan,> and set of security requirements emanating from that
>     Narayanan,> threat model is a waste of time? I hope not, but, I'd
>     Narayanan,> like to understand your take anyway.
> 
> Presumably he's saying that arguing over what protections one 
> person considers important is not all that useful because we 
> need to come up with a solution that supports all the common 
> protections.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 15 Feb 2007 14:16:24 -0800 (PST)

Hi Vidya,

  No, that's not what I'm suggesting. That was a lead-in to the next
paragraph in my post where I point out that regardless of what property
you say is paramount you can't use the keying material if its distribution
was not done in a way that prevents it from being transmitted to the
wrong entity. The point being: if you can't use the keying material then
arguing over what property you value most doesn't seem productive.

  Sorry for not being clear.

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Feb 2007 10:48:44 -0500

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Feb 2007 05:33:22 -0500

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Feb 2007 16:29:19 -0500

Narayanan,> Hi Dan,

Presumably he's saying that arguing over what protections one person
considers important is not all that useful because we need to come up
with a solution that supports all the common protections.