>
> > > Based on the above, how about the following
definition?
> > >
> > > "Channel Binding
> > >
> > > A secure mechanism for ensuring that a chosen
set of channel
> > > properties (such as authenticator identifiers
and properties) are
> > > agreed upon by the EAP peer and
server."
> >
> >After Jari's email, I created a thread
"Channel Binding
> analysis" for
> >further discussion. I still believe three party
agreement
> is essential
> >for Channel Binding. To me the two party agreement
mentioned above
> >looks similar to issueing a Kerberos ticket that is
never
> verified by
> >the consumers of the ticket.
>
> The text mentions authenticator identifiers and
properties,
> which presumably were agreed upon by the authenticator
that
> sent them (unless it's a
> forgery). However, there are also properties which
don't
> relate to the
> authenticator itself (such as Calling-Station-Id) but
are
> transmitted by the
> authenticator (e.g. to the backend server). Are there
any
> cases where a
> property to be verified by Channel Bindings is *not*
> transmitted by the authenticator? Would the following
work?
>
I cannot presently think of a property that needs
verification and is
not transmitted by the authenticator.
> "A secure mechanism for ensuring that a subset of
the
> parameters transmitted by the authenticator (such as
> authenticator identifiers and properties) are agreed
upon by
> the EAP peer and server."
>
This definition works for me.
> I'm not sure what the definition of a "channel
property" is
> in this case.
> One could argue for example that the Calling-Station-Id
is
> not a property of the channel -- but its verification
is
> still considered part of Channel Bindings.
>
The channel property definition is fuzzy to me as well. But,
perhaps we
don't need more detail in the EAP keying document itself. A
subsequent
channel binding document should get into more detail to
clarify things
like this.
Vidya
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|