issue 357: Channel Binding Definition

As Yoshi has pointed out, it may be possible to handle
channel bindings by 
mixing keys so that comparison may not be required.  How
about this?

"Channel Binding

A mechanism for ensuring the correctness of channel
properties (such as 
endpoint identifiers) provided to the EAP peer,
authenticator and server. "

-----------------------------------------------------------
Issue 357: Channel Binding Definition
Submitter name: Vidya Narayanan
Submitter email address: vidyanqualcomm.com
Date Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04227.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 1.2
Rationale/Explanation of issue:

The document defines channel binding
as a communication within an EAP method - this seems a bit
restrictive,
given that channel binding information could be carried
out-of-band as
well. The only requirement is that the information be
integrity
protected between the peer and server.

Requested change:
Change wording to:

"The communication of integrity-protected
channel properties such as endpoint identifiers which can be
compared to values communicated via out of band mechanisms
(such as
via a AAA or lower layer protocol)."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Re: do all the three parties have to be involved in
the binding? I believe that is essential for the
definition to say this.

Re: the data that is subject to channel binding. I think it
is
clear that not all data known by the parties needs to be
bound. Traditionally, we've only talked about security
or billing related information, such as the NAS identity
and type and cost of service. A large number of other
parameters may be known by some of the parties, but
not relevant from a verification perspective.

Re: do all the parties share the same data? I tend to
agree with Vidya here that its sufficient to for the
verifier to check that the data it gets is correct. But
this issue is also related to policies of what the parties
want to be verified. If the server wants to verify FOO
but the client does not send it, we're not helping. This
leads me to think that the channel bindings, if we ever
get them deployed, are going to have use a well
standardized set of parameters or else we have a policy
management problem in our hands. But see below for
a process comment.

Process comment: Lets try to focus on the definition
of channel bindings rather than their implementation
in this discussion. EAP keying framework does not
define how to implement them, or whether to pick
solution 1, 2, or 3.

Suggested text:

"Channel Binding

A secure mechanism for ensuring that a chosen set of
channel properties (such as endpoint identifiers) are
agreed upon by the EAP peer,  authenticator and
server."

Vidya: note that the "chosen set" may be
different
in different situations, depending on what information
is available.

--Jari


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

This looks good to me.

>Suggested text:
>
>"Channel Binding
>
>A secure mechanism for ensuring that a chosen set of
>channel properties (such as endpoint identifiers) are
>agreed upon by the EAP peer,  authenticator and
>server."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

At 07:18 AM 5/8/2006, Jari Arkko wrote:
>Re: do all the three parties have to be involved in
>the binding? I believe that is essential for the
>definition to say this.
>
>Re: the data that is subject to channel binding. I think
it is
>clear that not all data known by the parties needs to be
>bound. Traditionally, we've only talked about security
>or billing related information, such as the NAS identity
>and type and cost of service. A large number of other
>parameters may be known by some of the parties, but
>not relevant from a verification perspective.
>
>Re: do all the parties share the same data? I tend to
>agree with Vidya here that its sufficient to for the
>verifier to check that the data it gets is correct. But
>this issue is also related to policies of what the
parties
>want to be verified. If the server wants to verify FOO
>but the client does not send it, we're not helping.
This
>leads me to think that the channel bindings, if we ever
>get them deployed, are going to have use a well
>standardized set of parameters or else we have a policy
>management problem in our hands. But see below for
>a process comment.
>
>Process comment: Lets try to focus on the definition
>of channel bindings rather than their implementation
>in this discussion. EAP keying framework does not
>define how to implement them, or whether to pick
>solution 1, 2, or 3.
>
>Suggested text:
>
>"Channel Binding
>
>A secure mechanism for ensuring that a chosen set of
>channel properties (such as endpoint identifiers) are
>agreed upon by the EAP peer,  authenticator and
>server."

This is confusing to me.  I was under the assumption that
the peer 
and the server should agree that they have the same view of
the 
authenticator (perhaps with the provision that the server
may have a 
superset of the information than the peer has).  What does
the 
authenticator need to agree on?  Does it matter?

regards,
Lakshminath


>Vidya: note that the "chosen set" may be
different
>in different situations, depending on what information
>is available.
>
>--Jari
>
>
>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

>Suggested text:
>
>"Channel Binding
>
>A secure mechanism for ensuring that a chosen set of
>channel properties (such as endpoint identifiers) are
>agreed upon by the EAP peer,  authenticator and
>server."

I'm ok with this.  Any objections?


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

I agree.  

Note that agreement just by EAP peer and server would not be
sufficient.  Authenticator's agreement by running SAP for
proof of
possession of a key that is generated by the peer and server
and
somehow bound to the chosen set of properties would be
required.
Otherwise, it seems possible for an attacker to sit between
the peer
and legitimate authenticator and do something wrong by
spoofing some
of the properties of the legitimate authenticator.

Yoshihiro Ohba



On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard Aboba
wrote:
> >Suggested text:
> >
> >"Channel Binding
> >
> >A secure mechanism for ensuring that a chosen set
of
> >channel properties (such as endpoint identifiers)
are
> >agreed upon by the EAP peer,  authenticator and
> >server."
> 
> I'm ok with this.  Any objections?
> 
> 
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> http:/
/lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.
frascone.com/pipermail/eap
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

At 08:39 PM 5/8/2006, Yoshihiro Ohba wrote:
>I agree.
>
>Note that agreement just by EAP peer and server would
not be
>sufficient.  Authenticator's agreement by running SAP
for proof of
>possession of a key that is generated by the peer and
server and
>somehow bound to the chosen set of properties would be
required.
>Otherwise, it seems possible for an attacker to sit
between the peer
>and legitimate authenticator and do something wrong by
spoofing some
>of the properties of the legitimate authenticator.

How?  The attacker won't have the key (MSK) to do something
like 
that.  Perhaps you might explain the attack in detail.
Thanks.

regards,
Lakshminath


>Yoshihiro Ohba
>
>
>
>On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard Aboba
wrote:
> > >Suggested text:
> > >
> > >"Channel Binding
> > >
> > >A secure mechanism for ensuring that a chosen
set of
> > >channel properties (such as endpoint
identifiers) are
> > >agreed upon by the EAP peer,  authenticator
and
> > >server."
> >
> > I'm ok with this.  Any objections?
> >
> >
> >
____________________________________________________________
_____
> > To unsubscribe or modify your subscription
options, please visit:
> > http:/
/lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.
frascone.com/pipermail/eap
> >
>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

At 06:39 PM 5/8/2006, Bernard Aboba wrote:
>>Suggested text:
>>
>>"Channel Binding
>>
>>A secure mechanism for ensuring that a chosen set of
>>channel properties (such as endpoint identifiers)
are
>>agreed upon by the EAP peer,  authenticator and
>>server."
>
>I'm ok with this.  Any objections?

I am not sure about the authenticator involvement, have
asked Jari 
that question and awaiting response.  It's about the EAP
server and 
peer agreeing about the authenticator's identity and
perhaps other 
things about the authenticator, no?

regards,
Lakshminath



>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

On Tue, May 09, 2006 at 12:58:21AM -0700, Lakshminath
Dondeti wrote:
> At 08:39 PM 5/8/2006, Yoshihiro Ohba wrote:
> >I agree.
> >
> >Note that agreement just by EAP peer and server
would not be
> >sufficient.  Authenticator's agreement by running
SAP for proof of
> >possession of a key that is generated by the peer
and server and
> >somehow bound to the chosen set of properties would
be required.
> >Otherwise, it seems possible for an attacker to sit
between the peer
> >and legitimate authenticator and do something wrong
by spoofing some
> >of the properties of the legitimate authenticator.
> 
> How?  The attacker won't have the key (MSK) to do
something like 
> that.  Perhaps you might explain the attack in detail.
Thanks.

In case there is no SAP between the peer and authenticator
(e.g.,
wired 802.1X), the attacker does not need to have the key. 
In that
case, agreement just by EAP peer and server is useless. 
What I'd like
to mention is that Channel Binding makes sense only if
keying meterial
exported by an EAP method is used by SAP.

Yoshihiro Ohba


> 
> regards,
> Lakshminath
> 
> 
> >Yoshihiro Ohba
> >
> >
> >
> >On Mon, May 08, 2006 at 06:39:05PM -0700, Bernard
Aboba wrote:
> >> >Suggested text:
> >> >
> >> >"Channel Binding
> >> >
> >> >A secure mechanism for ensuring that a
chosen set of
> >> >channel properties (such as endpoint
identifiers) are
> >> >agreed upon by the EAP peer, 
authenticator and
> >> >server."
> >>
> >> I'm ok with this.  Any objections?
> >>
> >>
> >>
____________________________________________________________
_____
> >> To unsubscribe or modify your subscription
options, please visit:
> >> http:/
/lists.frascone.com/mailman/listinfo/eap
> >>
> >> Arhives: http://lists.
frascone.com/pipermail/eap
> >>
>
>________________________________________________________
_________
> >To unsubscribe or modify your subscription options,
please visit:
> >http:/
/lists.frascone.com/mailman/listinfo/eap
> >
> >Arhives: http://lists.
frascone.com/pipermail/eap
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap