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

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

Taking Amendment V in the interest of time :-)
The guidelines in the BCP are clear. No need to bother the ADs.

----- Original Message ----
From: Lakshminath Dondeti <[email-masked]>
To: M. Vanderveen <[email-masked]>
Cc: Dan Harkins <[email-masked]>; [email-masked]; [email-masked]; Russ Housley <[email-masked]>; Sam Hartman <[email-masked]>
Sent: Monday, February 12, 2007 12:23:23 PM
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>

____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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