Subject: Re: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

From: "M. Vanderveen" <[email-masked]>
Date: Mon, 12 Feb 2007 10:54:50 -0800 (PST)

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_______________________________________________
>> HOKEY mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/hokey
>>
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
>

____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Feb 2007 12:23:23 -0800

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.
> 
> <http://www.answers.yahoo.com_______________________________________________/>
>  >> HOKEY mailing list
>  >> [email-masked]
> ------------------------------------------------------------------------
> 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>

---

From: <[email-masked]>
Date: Mon, 12 Feb 2007 14:57:33 -0600

Colleagues,

The point was to request that we come up with a solution that is secure
to the desired level already prescribed, but also allows for seamless
mobility too. What will happen if an optimal implementation takes, at a
minimum, many seconds setting up the new SAs to continue a session when
moving between media/technologies within a domain, or between domains?
It would be a success as a first step, yes... but doesn't there need to
be a performance aspect to the goals.

I may be rushing the issue. If so please add it to a requirements list
and defer it.

Best Regards,
Michael

-----Original Message-----
From: ext 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

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.
> "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:
>  >> 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.
>  >> 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
>  >>
>  >> 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?
>  >>
>  >> ...
>  >>
> ______________________________________________________________________
> ______________  >> Need a quick answer? Get one in minutes from people

> who know.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 13 Feb 2007 17:15:55 -0800

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

thanks,
Lakshminath

>  >> Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy
Changes
>  >> Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy
Changes
>  >> considerably, wouldn't it?
____________________________________________________________________________
________
>  >> www.Answers.yahoo.com_______________________________________________ 
<http://www.answers.yahoo.com_______________________________________________
/>
>  >> https://www1.ietf.org/mailman/listinfo/hokey
<http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?promote=
mail>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 13 Feb 2007 17:18:46 -0800

Hi Michael,

Exactly the point. We really need to see whether moving across domain is a
main requirement for our first step. I believe improving security and
latency when moving between authenticator, same or different media is the
highest priority.

You are not rushing the matter, multi-domain consideration always take
specifications to a rat hole. I think we should focus on single domain
first.

R,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 12:58 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

Colleagues,

Best Regards,
Michael

-----Original Message-----
From: ext 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

thanks,
Lakshminath

research exercise.

our specs.

distribution.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Feb 2007 18:01:41 -0800

Madjid,
I think you are confusing making the key hierarchy extensible with what
is being addressed here now. The derivation of DSRKs from the EMSK
provides the much needed extensibility. But, this does not mean that we
are embarking into solving inter-administrative domain issues. That is
not the intention at all. 

The re-authentication protocol will still be for reauthentication with a
HOKEY server (like an EAP server, this may be just part of the AAA
server) and it will use the key hierarchy defined for that purpose. By
making the key hierarchy symmetrical, we'll be able to use the protocol,
whereever the HOKEY server is located. 

A lot of the discussion we are having on the list is just adding to
confusion. But, a lot of the discussion has been about whether or not we
include channel bindings in the base protocol and how we do that - so,
it still doesn't mean we are solving any inter-administrative domain
problems. 

Vidya

> From: Madjid Nakhjiri [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 5:16 PM
> To: Dondeti, Lakshminath; 'M. Vanderveen'
> Cc: 'Sam Hartman'; [email-masked]
> Subject: RE: [HOKEY] why visited domains?? Channel binding/ 
> lying MITM: EMSKHierarchy Changes
> 
> 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 
> 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.
> 
> 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. :)
> 
> 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 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:
> > the extent of their threat model. Otherwise we're just 
> doing a research exercise.
> > 
> > our
> specs.
> >  >> 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
> >  >>
> > binding/ lying MITM: EMSK Hierarchy
> Changes
> >  >>
> > way it channel bindings can
> be
> > would
> be

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Feb 2007 18:10:37 -0800

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 13 Feb 2007 18:15:26 -0800

Hi Vidya,

I actually see that a lot of channel binding discussion here is emanating
from the issue of having to involve multiple domain's AAA server in the
signaling and the fact that it is not easy to do, is making people like you
to trivialize the channel binding problem, sorry for rough language, I just
don't like to be called confused. I thought I mentioned that to you
before...

In a single domain, dealing with channel binding is a lot simpler, because
multi-domain introduces a lot less threats to the service model.

As far as the discussion at hand, I don't think we can hand wave the
problems of channel binding and key transport. As I mentioned long time ago,
we have to decide our requirements for security, including those for key
transport and if a AAA protocol does not meet the requirements, then we
either use another or go to the AAA group and debate how to deal with
problem.

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 6:02 PM
To: Madjid Nakhjiri; Dondeti, Lakshminath; M. Vanderveen
Cc: [email-masked]
Subject: RE: [HOKEY] why visited domains?? Channel binding/ lying
MITM:EMSKHierarchy Changes

Madjid,

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Feb 2007 19:08:18 -0800

Hi Madjid,  

> Sent: Tuesday, February 13, 2007 6:15 PM
> To: Narayanan, Vidya; Dondeti, Lakshminath; 'M. Vanderveen'
> Cc: [email-masked]
> lying MITM:EMSKHierarchy Changes
> 
> Hi Vidya,
> 
> I actually see that a lot of channel binding discussion here 
> is emanating from the issue of having to involve multiple 
> domain's AAA server in the signaling and the fact that it is 
> not easy to do, is making people like you to trivialize the 
> channel binding problem, 

I am not saying the problem is trivial. It takes two steps to ensure
there isn't a problem - make sure the key is bound to the appropriate
entities (which we plan to do by including the domain name in the
derivation) and make sure the key transport protocol is secure and can
verify the identity of the recipient of the key (and correctly deployed
AAA can do this). 

> sorry for rough language, I just 
> don't like to be called confused. I thought I mentioned that 
> to you before...
> 

Sorry, no bad intentions at all. Being called confused is quite
different from saying you may be confusing something - in all the emails
going on here, it is not difficult to find this confusing and I can
relate to that state very easily :) 

> In a single domain, dealing with channel binding is a lot 
> simpler, because multi-domain introduces a lot less threats 
> to the service model.
> 

When you say multi-domain, are you referring to different administrative
domains? If so, that is not a problem we should solve and that isn't
what we are solving either. If you are just referring to multiple middle
entities, I believe the problem is the same whether there is one middle
entity (as in EAP) or two (as in HOKEY). I've explained this in one of
my emails to Dan. 

> As far as the discussion at hand, I don't think we can hand 
> wave the problems of channel binding and key transport. As I 
> mentioned long time ago, we have to decide our requirements 
> for security, including those for key transport and if a AAA 
> protocol does not meet the requirements, then we either use 
> another or go to the AAA group and debate how to deal with problem.
> 

As I've noted in another email, using something other than AAA as the
transport is not something we should be spending our energy on - AAA
satisfies the requirements we are looking for. If there are some modes
of use of RADIUS that we see problems with, we should go to RADEXT and
resolve that problem. 

Vidya

> lying MITM:EMSKHierarchy Changes
> 
> Madjid,
> I think you are confusing making the key hierarchy extensible 
> with what is being addressed here now. The derivation of 
> DSRKs from the EMSK provides the much needed extensibility. 
> But, this does not mean that we are embarking into solving 
> inter-administrative domain issues. That is not the intention at all. 
> 
> The re-authentication protocol will still be for 
> reauthentication with a HOKEY server (like an EAP server, 
> this may be just part of the AAA
> server) and it will use the key hierarchy defined for that 
> purpose. By making the key hierarchy symmetrical, we'll be 
> able to use the protocol, whereever the HOKEY server is located. 
> 
> A lot of the discussion we are having on the list is just 
> adding to confusion. But, a lot of the discussion has been 
> about whether or not we include channel bindings in the base 
> protocol and how we do that - so, it still doesn't mean we 
> are solving any inter-administrative domain problems. 
> 
> Vidya
> 
> > MITM: EMSKHierarchy Changes
> > 
> 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.
> > 
> > multi-domain later. There was a reason visited domain was 
> considered 
> > as a separate deliverable.
> > 
> 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.
> > On whether conformance (and I think that is what you are 
> referring to 
> > as
> > 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 
> > 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:
> (wo)men with 
> > 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.
> > 
> may believe 
> > 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:
> > >  >> Charles Clancy <mailto:[email-masked]> allegedly 
> scribbled on
> > Monday,

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Feb 2007 17:28:58 -0500

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

---

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

Well, as far as ccing Russ, I was just helping along for you to deliver the
promise:) It was not my idea:) I am sure you had a good reason for consuming
AD s bandwidth for this.

Again, rough consensus is achieved on the mailing list. And I already
mentioned that the symmetry is no longer there (see my other email).

Also "_could_ have been part of deliverable 2" is a bit too liberal for a
group that struggled for a year to get consensus on its charter, so as long
as we are quoting the charter, lets just stick with the fact that visited
domain is part of deliverable 6 and not 2 or 3 and that was a quite
conscious choice, I might say.

Adding a level of hierarchy for every conceivable application just to serve
roaming is both wasteful, extra complication and is violating the existing
service models, not to mention that you MAY end up adding roundtrips to the
signaling, if people insist on adding anti-replay and other measures (we
already see Dan has raised these issues).

We are not talking about fixing AAA model, but lets not forget that we are a
AAA based key management group (see Russ's draft), we do abide by governing
AAA models, and yes, we do need to deal with AAA flaws as we uncover this,
since this is also a security group.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 6:11 PM
To: Madjid Nakhjiri
Cc: 'M. Vanderveen'; 'Sam Hartman'; [email-masked]; 'Russ Housley'
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM: EMSK
Hierarchy Changes

regards,
Lakshminath

> Visited domain keys were brought in to "make the key hierarchy
symmetrical",
> I am suggesting to take the visited domain consideration off from
signaling

---

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

Hi Madjid,
While ordering and prioritization of charter items are generally useful,
designing something without thinking about the bigger picture and other
use cases (especially known use cases) leads to an inextensible design.
In general, the goal is to have a design that is extensible for future,
even unanticipated, use cases. However, sometimes, unexpected use cases
appear late, leading to certain restrictions. 

Here is a case, where we've clearly gone through the list and found that
in order to make the key hierarchy extensible to support local domains
(not necessarily inter-administrative, but, just local to address faster
re-authentication) and to support local service keying (even though this
is not in the HOKEY charter), we need to use DSRKs as we agreed to at
the Interim meeting. Arguing that we now need to go back and stop
looking at the bigger picture and just design for one charter
deliverable at a time doesn't seem to be the best approach. 

As we've realized, if TCP were designed specifically for Telnet and FTP,
HTTP would have never happened as we know it today :) 

Vidya

> Sent: Thursday, February 15, 2007 1:53 PM
> To: Dondeti, Lakshminath
> Cc: 'Sam Hartman'; [email-masked]; 'Madjid Nakhjiri'
> promise:) It was not my idea:) I am sure you had a good 
> reason for consuming AD s bandwidth for this.
> 
> Again, rough consensus is achieved on the mailing list. And I 
> already mentioned that the symmetry is no longer there (see 
> my other email).
> 
> Also "_could_ have been part of deliverable 2" is a bit too 
> liberal for a group that struggled for a year to get 
> consensus on its charter, so as long as we are quoting the 
> charter, lets just stick with the fact that visited domain is 
> part of deliverable 6 and not 2 or 3 and that was a quite 
> Adding a level of hierarchy for every conceivable application 
> just to serve roaming is both wasteful, extra complication 
> and is violating the existing service models, not to mention 
> that you MAY end up adding roundtrips to the signaling, if 
> people insist on adding anti-replay and other measures (we 
> We are not talking about fixing AAA model, but lets not 
> forget that we are a AAA based key management group (see 
> Russ's draft), we do abide by governing AAA models, and yes, 
> we do need to deal with AAA flaws as we uncover this, since 
> this is also a security group.
> 
> Madjid
> 
> Subject: Re: [HOKEY] why visited domains?? Channel binding/ 
> lying MITM: EMSK Hierarchy Changes
> 
> Sorry for the oversight in not cc'ing Russ.  I was going yo 
> when the issue about domino effect came about.
> 
> 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:
> domains
> > as deliverable 6, not delieverable 2 (EMSK hierarchy) and not 
> > deliverable
> 3
> > (key hierarchy). 
> > 
> > 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.
> > 
> > and key hierarchy for the moment and just make derivation 
> of USRK from
> EMSK
> protected as if a bank vault would be protected:
> >> design exists and being able to clearly explain what can be 
> >> traded-off for efficiency and at what cost.
> >>
> >> Lakshminath
> >>
> >> Dan Harkins wrote:
> >> with  >> correctness and the like. End result is no one will 
> >> implement our
> > specs.
> >>  >> 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
> >>  >>
> >>  >> 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
> > 
> >>  >>
> >> precisely
> >>  >>> 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
> >>  >> delivered at the same time (e.g., in the RADIUS 
> Access-Accept).  
> >> A  >> separate key request would increase the latency of the
> > reauthentication

---

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

Hi Vidya,

The IETF follows its chartering procedure to avoid something that is
generally called "boiling the ocean":) We work at one problem at a time with
a defined scope, simply to get in time. The charter has taken 1 year to
form, so lets not go into "extensible for future" things.

To answer to your analogies: If people wanted to wait for IPv6, we would
never have had the Internet!

So again, support of roaming into visited domain is not "looking at the big
picture" it is looking at the view with at a 30 degree angle. Not every
keying problem needs to deal with roaming and thus the proposed complexity
in the hierarchy. 

We are not going back to anything, any interim meeting decision needs to be
supported by the WG on mailing list. These are the IETF guidelines on
interim meetings. I suggest you look at those.

Having said all this, In SJ, I already gave a solution for roaming by saying
that USRK coming off EMSK can be used to derive per-domain USRKs, so that
per-domain USRKs are children to USRK and that way the service model is
preserved. The only argument for the use of DSRK was the symmetry of the key
hierarchy, which is no longer true.

Again, in my other email to Michaela, I have suggested to include Domain
server ID in the USRK derivation, that way you would have both domains and
usages at the same level, without forcing the rest of the world to deal with
roaming. I think that is both simple and extensible.

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 2:57 PM
To: Madjid Nakhjiri; Dondeti, Lakshminath
Cc: Sam Hartman; [email-masked]
Subject: RE: [HOKEY] why visited domains?? Channel binding/ lying

Hi Madjid,

Vidya