Issue 352: Channel Binding Issue

The text of Issue 352 is shown below.

The suggested substitute text is ok as far as it goes.

As I read the referenced document, it requires changes to
EAP methods, much 
the same as the transportation approach does.  The peer and
server have to 
negotiate what channel bindings are mixed in with the keying
material, 
effectively producing "mixed" MSKs/EMSKs.  
Since the EAP method is really 
just outputing an MSK/EMSK as usual (albeit with channel
bindings mixed in), 
no new AAA attributes or communication flow is required.

Did I read the document correctly?
------------------------------------------------------------
-----------------------------------------------------
Issue 352: Channel Binding Issue
Submitter name: Yoshihiro Ohba
Submitter email address: yohbatari.toshiba.com
Date Submitted: April 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04216.html
Document: Keying-12
Comment type: T
Priority: 1
Section: 5.11
Rationale/Explanation of issue:

Reference [I-D.draft-ohba-eap-aaakey-binding] should be
obsoleted by
its successor, i.e., [I-D.draft-ohba-eap-channel-binding]
which
provides more generic, complete and extensible way of
channel binding.
Note that pre-configuration of the parameter set on AS is an
important
property to achieve Channel Binding in 3-party key
management.

Change:

"  It is also possible to achieve Channel Bindings
without transporting
   data over EAP.  For example, see
[I-D.draft-ohba-eap-aaakey-binding].
   In this approach the authenticator informs the backend
server about
   the Channel Binding parameters using AAA, and the backend
server
   calculates transported keying material based on this
parameter set,
   making it impossible for the peer and authenticator to
complete the
   Secure Association Protocol if there was a mismatch in
the
   parameters."

to:

"  It is also possible to achieve Channel Bindings
without
   transporting data over EAP.  For example, see
   [I-D.draft-ohba-eap-channel-binding].  In this approach
the backend
   server calculates transported keying material based on
the
   parameter set pre-configured for the authenticator,
making it
   impossible for the peer and authenticator to complete the
Secure
   Association Protocol if there was a mismatch in the
parameters."


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

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

On Mon, May 01, 2006 at 06:48:34PM -0700, Bernard Aboba
wrote:
> The text of Issue 352 is shown below.
> 
> The suggested substitute text is ok as far as it goes.
> 
> As I read the referenced document, it requires changes
to EAP methods, much 
> the same as the transportation approach does.  The peer
and server have to 
> negotiate what channel bindings are mixed in with the
keying material, 
> effectively producing "mixed" MSKs/EMSKs.  
Since the EAP method is really 
> just outputing an MSK/EMSK as usual (albeit with
channel bindings mixed 
> in), no new AAA attributes or communication flow is
required.
> 
> Did I read the document correctly?

Thank you for reading the document.  And the answer is, if
the
generated "mixed" MSKs are carried in the
existing AAA attributes
instead of carrying the MSKs, then no AAA attributes or
communication
flow is required for EAP keying.

[Note, however, if the "mixed" MSKs/EMSKs are
used outside the scope
of EAP keying (e.g., handover keying), then new AAA
attributes or
communication flow may be needed.  This all depends on what
requirements on out-of-the-scope usages will be.]

Regards,
Yoshihiro Ohba




>
------------------------------------------------------------
-----------------------------------------------------
> Issue 352: Channel Binding Issue
> Submitter name: Yoshihiro Ohba
> Submitter email address: yohbatari.toshiba.com
> Date Submitted: April 25, 2006
> Reference: http://lists.frascone.com/pipermail/eap/msg04216.html
> Document: Keying-12
> Comment type: T
> Priority: 1
> Section: 5.11
> Rationale/Explanation of issue:
> 
> Reference [I-D.draft-ohba-eap-aaakey-binding] should be
obsoleted by
> its successor, i.e.,
[I-D.draft-ohba-eap-channel-binding] which
> provides more generic, complete and extensible way of
channel binding.
> Note that pre-configuration of the parameter set on AS
is an important
> property to achieve Channel Binding in 3-party key
management.
> 
> Change:
> 
> "  It is also possible to achieve Channel
Bindings without transporting
>   data over EAP.  For example, see
[I-D.draft-ohba-eap-aaakey-binding].
>   In this approach the authenticator informs the
backend server about
>   the Channel Binding parameters using AAA, and the
backend server
>   calculates transported keying material based on this
parameter set,
>   making it impossible for the peer and authenticator
to complete the
>   Secure Association Protocol if there was a mismatch
in the
>   parameters."
> 
> to:
> 
> "  It is also possible to achieve Channel
Bindings without
>   transporting data over EAP.  For example, see
>   [I-D.draft-ohba-eap-channel-binding].  In this
approach the backend
>   server calculates transported keying material based
on the
>   parameter set pre-configured for the authenticator,
making it
>   impossible for the peer and authenticator to complete
the Secure
>   Association Protocol if there was a mismatch in the
parameters."
> 
> 
>
____________________________________________________________
_____
> 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

>Thank you for reading the document.  And the answer is,
if the
>generated "mixed" MSKs are carried in the
existing AAA attributes
>instead of carrying the MSKs, then no AAA attributes or
communication
>flow is required for EAP keying.

It might be worth saying a few words about this in the
paragraph.  Overall, 
I'm not sure whether the Channel Binding text in the
document is all that 
consistent/comprehesive.


____________________________________________________________
_____
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 02, 2006 at 12:26:42PM -0700, Bernard Aboba
wrote:
> >Thank you for reading the document.  And the answer
is, if the
> >generated "mixed" MSKs are carried in
the existing AAA attributes
> >instead of carrying the MSKs, then no AAA
attributes or communication
> >flow is required for EAP keying.
> 
> It might be worth saying a few words about this in the
paragraph.  

I agree on adding a few words on this in the paragraph.

> Overall, 
> I'm not sure whether the Channel Binding text in the
document is all that 
> consistent/comprehesive.


I agree with your opinion here as well.  Let me quote some
questionable part in Section 5.11 of eap-keying-13 below:


"
As noted in [RFC3748] Section 7.15, this vulnerability can
be
addressed by EAP methods that support a protected exchange
of channel
properties such as endpoint identifiers, including (but not
limited
to): Called-Station-Id [RFC2865][RFC3580],
Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
"

I'd mention that Channel Binding description in RFC3748 is
somewhat
obsolete according to the recent discussion on the AAA
server's
requirement on pre-configurating Channel Binding parameters.
 Do we
need this paragraph?  Or instead we may have some explicit
text here
to obsolete Channel Binding description in RFC3748.


"
Using such a protected exchange, it is possible to match the
channel
properties provided by the authenticator via out-of-band
mechanisms
against those exchanged within the EAP method.  For example,
see the
discussion in Section 1.4 as well as
[I-D.arkko-eap-service-identity-
auth].
"

According to the the AAA server's requirement on
pre-configurating
Channel Binding parameters, I don't see the usefulness of
[I-D.arkko-eap-service-identity-auth].  Do we really need
this
paragraph?


"
The main difference between these approaches is that Channel
Binding
support within an EAP method may require upgrading or
changing the
EAP method, impacting both the peer and the server.   Where
Channel
Bindings are implemented in AAA,  the peer, authenticator
and the
backend server need to be upgraded, but the EAP method need
not be
modified.
"

If we have only one Channel Binding method, we don't need
this
comparison.


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

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