[Emu] Review of draft-clancy-emu-chbind-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emu] Review of draft-clancy-emu-chbind-01
In general I think the document is a good start. I think it needs some
work in a few areas
1. Section 1
- The following sentence is a bit odd:
"Here, a Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using oneFrom emu-bounces at ietf.org Wed Jul 23 16:38:05 2008
Return-Path: <emu-bounces at ietf.org>
X-Original-To: emu-archive at megatron.ietf.org
Delivered-To: ietfarch-emu-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 360333A6778;
Wed, 23 Jul 2008 16:38:05 -0700 (PDT)
X-Original-To: emu at core3.amsl.com
Delivered-To: emu at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1E78B3A67B0
for <emu at core3.amsl.com>; Wed, 23 Jul 2008 16:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Level:
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iNlXwlq-iX3s for <emu at core3.amsl.com>;
Wed, 23 Jul 2008 16:38:02 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
by core3.amsl.com (Postfix) with ESMTP id 6C4CE3A63C9
for <emu at ietf.org>; Wed, 23 Jul 2008 16:38:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,240,1215388800"; d="scan'208";a="130741989"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
by sj-iport-6.cisco.com with ESMTP; 23 Jul 2008 23:38:46 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6NNckrm012205;
Wed, 23 Jul 2008 16:38:46 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6NNckYI026902;
Wed, 23 Jul 2008 23:38:46 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 23 Jul 2008 16:38:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 23 Jul 2008 16:39:19 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE506320756 at xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-clancy-emu-chbind-01
thread-index: AcjtHVOvdC9viqHLQ7WosWfQU7VLwg==
From: "Joseph Salowey (jsalowey)" <jsalowey at cisco.com>
To: <emu at ietf.org>
X-OriginalArrivalTime: 23 Jul 2008 23:38:46.0018 (UTC)
FILETIME=[3FCB4620:01C8ED1D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8819; t=1216856326;
x=1217720326; c=relaxed/simple; s=sjdkim3002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jsalowey at cisco.com;
z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey at ci
sco.com> |Subject:=20Review=20of=20draft-clancy-emu-chbind-01
|Sender:=20; bh=7d70dCIn6eBoJdA5wf3cg45JbmHfIuZqwhGS/DQJyp4=;
b=FgqgHVzjUG6F6tqCPUljzJdyDN8mglfBlClb0L4mDj8XTLbWq++GWXJ1fM
qxNIguVUPUoiEvj/bviCa1zDfafVHMQRhV+8Fn8ABDoQlLZ2Ks6jmEOdFMbG
YVO703pRBj;
Authentication-Results: sj-dkim-3; header.From=jsalowey at cisco.com; dkim=pass (
sig from cisco.com/sjdkim3002 verified; );
Cc: draft-clancy-emu-chbind at tools.ietf.org
Subject: [Emu] Review of draft-clancy-emu-chbind-01
X-BeenThere: emu at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>,
<mailto:emu-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/emu>
List-Post: <mailto:emu at ietf.org>
List-Help: <mailto:emu-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>,
<mailto:emu-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: emu-bounces at ietf.org
Errors-To: emu-bounces at ietf.org
In general I think the document is a good start. I think it needs some
work in a few areas
1. Section 1
- The following sentence is a bit odd:
"Here, a Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using one set of
set of
credentials, while representing contrary information to EAP clients."
The credentials are often different, it is the service that the AAA
server expects the NAS to provide vs. what is actually provided.
"Here, the backend AAA infrastructure may expect the Network Access
Server (NAS) or pass-through authenticator to provide one set of
services, while the NAS may represent contrary service offerings to EAP
clients."
- I would prefer if referred to the general solution technique before
referencing [AAAPAY]. For example in the last paragraph:
"This document uses a process in which the EAP client provides
information about the characteristics of the service provided by the
authenticator to the AAA server protected within the EAP method,
allowing the server to verify the authenticator is providing valid
information to the peer. The server can also respond back with
additional information that could be useful for the client to decide
whether or not to continue its session with the authenticator. "AAA
Payloads" defined in [AAAPAY] proposes a mechanism to carry this
information."
2. Section 3
Channel bindings [RFC5056] seek to enforce a stronger security
relationship between the three entities, by allowing the client and
server to compare their relative perception of the authenticator's
identity in a secure channel.
[Joe] Identity is only one aspect of channel binding issues. Often the
client does not really care or know much about the authenticator
identity, it cares about the characteristics of the services provided by
the authenticator.
This document defines how to use "AAA
Payloads" [I-D.clancy-emu-aaapay] within EAP methods to implement
channel bindings.
[Joe] Here again I would prefer to reference the general technique of
communicating information with [AAAPAY] as an example.
Unlike [RFC5056], channel binding in EAP context
does not ensure binding different layers of a session but rather the
information advertized to client and authentication server by an
authenticator acting as pass-through device during an EAP session.
[Joe] It goes beyond just advertisement from the authenticator to AAA
server. The AAA server must have an expectation of what the
authenticator should provide. Without this the value of channel
bindings is greatly diminished. Since the AAA server must have an
expectation of what is provided advertisement from the authenticator to
the AAA is not necessary.
It is preferable to use this idea, rather than hashing identity
information directly into keys, for a number of reasons:
o It allows for fuzzy comparisons of entity names, rather than
requiring absolute. This can facilitate deployment and debugging.
[Joe] An example, where comparison is useful is when more than one value
for a service characteristic is valid. If the exact information is not
communicated in the AAA protocol then the AAA server needs to compare
what is provided by the EAP client with a set of valid choices. It is
also useful when you do not want things to fail, but would rather track
down the problem after the fact. I think this bullet could be reworded,
perhaps 'fuzzy' is not the best term.
o Any EAP method that provides mutual authentication and key
derivation can easily add channel binding as proposed in this
draft. On the other hand, including identities into key
derivations requires the modification of EAP methods. For
instance, many EAP methods specify how MSK and other keying
material is derived and adding channel binding by adding
identifiers would need to be specified for each method
individually.
[Joe] This is one way to achieve this, but it could also be done in the
AAA server outside the EAP method. It is more likely that channel
bindings will be exported outside a method and evaluated by the other
AAA subsystems instead of the method itself.
o Client and authentication server may communicate on different
layers with the authenticator and thus receive different
identifie credentials, while representing contrary information to EAP clients."
The credentials are often different, it is the service that the AAA
server expects the NAS to provide vs. what is actually provided.
"Here, the backend AAA infrastructure may expect the Network Access
Server (NAS) or pass-through authenticator to provide one set of
services, while the NAS may represent contrary service offerings to EAP
clients."
- I would prefer if referred to the general solution technique before
referencing [AAAPAY]. For example in the last paragraph:
"This document uses a process in which the EAP client provides
information about the characteristics of the service provided by the
authenticator to the AAA server protected within the EAP method,
allowing the server to verify the authenticator is providing valid
information to the peer. The server can also respond back with
additional information that could be useful for the client to decide
whether or not to continue its session with the authenticator. "AAA
Payloads" defined in [AAAPAY] proposes a mechanism to carry this
information."
2. Section 3
Channel bindings [RFC5056] seek to enforce a stronger security
relationship between the three entities, by allowing the client and
server to compare their relative perception of the authenticator's
identity in a secure channel.
[Joe] Identity is only one aspect of channel binding issues. Often the
client does not really care or know much about the authenticator
identity, it cares about the characteristics of the services provided by
the authenticator.
This document defines how to use "AAA
Payloads" [I-D.clancy-emu-aaapay] within EAP methods to implement
channel bindings.
[Joe] Here again I would prefer to reference the general technique of
communicating information with [AAAPAY] as an example.
Unlike [RFC5056], channel binding in EAP context
does not ensure binding different layers of a session but rather the
information advertized to client and authentication server by an
authenticator acting as pass-through device during an EAP session.
[Joe] It goes beyond just advertisement from the authenticator to AAA
server. The AAA server must have an expectation of what the
authenticator should provide. Without this the value of channel
bindings is greatly diminished. Since the AAA server must have an
expectation of what is provided advertisement from the authenticator to
the AAA is not necessary.
It is preferable to use this idea, rather than hashing identity
information directly into keys, for a number of reasons:
o It allows for fuzzy comparisons of entity names, rather than
requiring absolute. This can facilitate deployment and debugging.
[Joe] An example, where comparison is useful is when more than one value
for a service characteristic is valid. If the exact information is not
communicated in the AAA protocol then the AAA server needs to compare
what is provided by the EAP client with a set of valid choices. It is
also useful when you do not want things to fail, but would rather track
down the problem after the fact. I think this bullet could be reworded,
perhaps 'fuzzy' is not the best term.
o Any EAP method that provides mutual authentication and key
derivation can easily add channel binding as proposed in this
draft. On the other hand, including identities into key
derivations requires the modification of EAP methods. For
instance, many EAP methods specify how MSK and other keying
material is derived and adding channel binding by adding
identifiers would need to be specified for each method
individually.
[Joe] This is one way to achieve this, but it could also be done in the
AAA server outside the EAP method. It is more likely that channel
bindings will be exported outside a method and evaluated by the other
AAA subsystems instead of the method itself.
o Client and authentication server may communicate on different
layers with the authenticator and thus receive different
identifiers that rs that may belong to the same device. A server may be
able to recognize which different identifiers belong to the same
device (e.g. by performing a table look up). This scenario cannot
be solved by hashing identities into keys.
[Joe] I'm not sure what this means.
3. Seciton 4
I think the discussion in this section is a little off target. There is
a trust relationship between the authenticator and the AAA. The AAA
trusts that the authenticator will provide the expected set of services
to the client. The AAA needs to know what services it expects an
authenticator to provide. This knowledge may be distributed across
several AAA servers in the case of a proxy relationship. The trust is
rooted in the authentication between AAA servers and authenticator. The
EAP client is trusting that all of this works correctly and its trust is
rooted in a relationship with the AAA server hosting the EAP Server.
The issue here is that the AAA server and client have no way to verify
correct behavior of the authenticator. This is the gap that channel
bindings is trying to fill.
The text is misleading in that at some points it suggests that the AAA
server needs to trust info2. This is only partially true since trusting
info2 would allow the authenticator to advertise whatever it wants to
both sides. Later in the text this is clarified, the AAA server needs
to have access to some information that allows it to determine if info1
and info2 are within the set of acceptable values. It is not necessary
for the AAA to receive info2 from the authenticator since it needs to
know the set of acceptable values. It may help in some schemes for the
AAA to receive what the authentication has chosen if there is more than
one element in the set of acceptable values for a particular
characteristic.
I think this document should discuss a bit more on who actually verifies
the channel bindings. While EAP carries the channel bindings the EAP
method may not be the best place to carry out this evaluation. This
would typically be done in a AAA server which has more authorization
information available to it. If there is a proxy chain the evaluation
may be done at various points in the chain so the channel binding
information needs to be communicated down the chain from the EAP server.
There probably should also be some discussion on the implications of
having the EAP server collocated with the authenticator.
I think this section could use a bit more work.
4. Section 5
The introduction described a situation where an access point advertises
a different SSID than it should be allowed to, wouldn't this be
something to include in the example?
5. Section 6
This section needs to make recommendations for requirements for EAP
methods, AAA protocols and lower layers. Something like the following:
EAP method Support - EAP methods MUST be able to carry type x of data
integrity protected from client to server. EAP methods SHOULD provide a
mechanism to carry protected data from server to client. EAP methods
MUST export channel binding data to the AAA subsystem on the EAP server.
EAP methods MUST be able to import channel binding data from the lower
layer on the EAP peer.
AAA protocol support - The AAA subsystem MUST be able to process channel
binding data returned from the EAP method. It must be possible to pass
the channel binding data in AAA attributes to proxy AAA if a proxy AAA
will need to evaluate the data. I'm pretty sure that this is not the
only consideration.
Lower Layer Support - I don't think we want to define the requirements
for every lower layer in this section or in the document. I think we
need to list some requirements as to what would make good candidates for
lower layer parameters to use as channel bindings. Indicate that there
MUST be a way to convey this in the EAP method and MUST be a way to send
it in the AAA protocol unless the channel binding can be evaluated
entirely on the AAA that hosts the EAP server (home AAA).
I think we can provide an other sections of the document such as an
apmay belong to the same device. A server may be
able to recognize which different identifiers belong to the same
device (e.g. by performing a table look up). This scenario cannot
be solved by hashing identities into keys.
[Joe] I'm not sure what this means.
3. Seciton 4
I think the discussion in this section is a little off target. There is
a trust relationship between the authenticator and the AAA. The AAA
trusts that the authenticator will provide the expected set of services
to the client. The AAA needs to know what services it expects an
authenticator to provide. This knowledge may be distributed across
several AAA servers in the case of a proxy relationship. The trust is
rooted in the authentication between AAA servers and authenticator. The
EAP client is trusting that all of this works correctly and its trust is
rooted in a relationship with the AAA server hosting the EAP Server.
The issue here is that the AAA server and client have no way to verify
correct behavior of the authenticator. This is the gap that channel
bindings is trying to fill.
The text is misleading in that at some points it suggests that the AAA
server needs to trust info2. This is only partially true since trusting
info2 would allow the authenticator to advertise whatever it wants to
both sides. Later in the text this is clarified, the AAA server needs
to have access to some information that allows it to determine if info1
and info2 are within the set of acceptable values. It is not necessary
for the AAA to receive info2 from the authenticator since it needs to
know the set of acceptable values. It may help in some schemes for the
AAA to receive what the authentication has chosen if there is more than
one element in the set of acceptable values for a particular
characteristic.
I think this document should discuss a bit more on who actually verifies
the channel bindings. While EAP carries the channel bindings the EAP
method may not be the best place to carry out this evaluation. This
would typically be done in a AAA server which has more authorization
information available to it. If there is a proxy chain the evaluation
may be done at various points in the chain so the channel binding
information needs to be communicated down the chain from the EAP server.
There probably should also be some discussion on the implications of
having the EAP server collocated with the authenticator.
I think this section could use a bit more work.
4. Section 5
The introduction described a situation where an access point advertises
a different SSID than it should be allowed to, wouldn't this be
something to include in the example?
5. Section 6
This section needs to make recommendations for requirements for EAP
methods, AAA protocols and lower layers. Something like the following:
EAP method Support - EAP methods MUST be able to carry type x of data
integrity protected from client to server. EAP methods SHOULD provide a
mechanism to carry protected data from server to client. EAP methods
MUST export channel binding data to the AAA subsystem on the EAP server.
EAP methods MUST be able to import channel binding data from the lower
layer on the EAP peer.
AAA protocol support - The AAA subsystem MUST be able to process channel
binding data returned from the EAP method. It must be possible to pass
the channel binding data in AAA attributes to proxy AAA if a proxy AAA
will need to evaluate the data. I'm pretty sure that this is not the
only consideration.
Lower Layer Support - I don't think we want to define the requirements
for every lower layer in this section or in the document. I think we
need to list some requirements as to what would make good candidates for
lower layer parameters to use as channel bindings. Indicate that there
MUST be a way to convey this in the EAP method and MUST be a way to send
it in the AAA protocol unless the channel binding can be evaluated
entirely on the AAA that hosts the EAP server (home AAA).
I think we can provide an other sections of the document such as an
appendix tpendix to detail the specifics of some lower layers. These may also
belong in a separate document(s).
Cheers,
Joe
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www.ietf.org/mailman/listinfo/emu
o detail the specifics of some lower layers. These may also
belong in a separate document(s).
Cheers,
Joe
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
