Subject: [AAA-DOCTORS] Fwd: Auto-discard notification

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Jun 2014 16:47:15 +0200

-------- Original Message --------
Subject: 	Auto-discard notification
Date: 	Tue, 3 Jun 2014 07:39:54 -0700
From: 	<[email-masked]>
To: 	<[email-masked]>

The attached message has been automatically discarded.

Subject: Re: Revised charter proposal: charter-ietf-ace-00-02
From: Kathleen Moriarty <[email-masked]>
To: Likepeng <[email-masked]>
Cc: Benoit Claise <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "The IESG" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 3 Jun 2014 10:39:39 -0400
List-Id: <aaa-doctors.ietf.org>

I believe there is agreement on the proposed changes.  I'll make the
updates later in the day (it's about 11:30 my time, maybe at 4) in case
anyone wants to chime in.  If we are all in agreement, I'll have it sent
for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <[email-masked]> wrote:

>  Hi Kathleen and all,
>
>
>
> This is what I have now:
>
>
>
> Change #1: (Proposed by Kepeng, confirmed by Benoit)
>
> OLD
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
>
>
> NEW
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> REST architecture is widely used for such constrained environments.
>
> END
>
>
>
> Change #2: (Proposal from Rene, supported by Stefanie)
>
> OLD:
>
> Requirements derived from use cases indicate the suitability of existing
>
> work as a solution for constrained environments
>
>
>
> NEW:
>
> Requirements derived from use cases may indicate that existing work is
>
>  useful as basis for as a solution for constrained environments
>
>
>
> Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet)
>
> OLD:
>
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is maintained.
>
> Other application protocols and protocols at other layers in the stack are out of scope.
>
>
>
> NEW
>
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is maintained.
>
> The group is scoped to work only on the web protocols and data carried within them.
>
> END
>
>
>
> Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie)
>
> OLD:
>
> Jul 2014 Submit "Use cases and Requirements" as a WG item.
>
> Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.
>
>
>
> NEW
>
> Dec 2014 Submit "Use cases and Requirements" as a WG item.
>
> Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for
>
> publication as an Informational RFC.
>
> END
>
>
>
> I think we covered all of the IESG review comments.
>
>
>
> If there is any open issue, please let us know.
>
>
>
> Thanks,
>
>
>
> Kind Regards
>
> Kepeng
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> Charter charter-ietf-ace-00-02
>
> Authentication and Authorization for Constrained
>
> Environment (ACE)
>
>
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> REST architecture is widely used for such constrained environments.
>
> It has been observed that Internet protocols can be applied to these
>
> constrained environments, often only requiring minor tweaking and
>
> profiling. In other cases, new protocols have been defined to address
>
> the specific requirements of constrained environments. An example of
>
> such a protocol is the Constrained Application Protocol (CoAP).
>
>
>
> As in other environments, authentication and authorization questions
>
> also arise in constrained environments. For example, a door lock has to
>
> authorize the person seeking access using a "digital key". Where is the
>
> authorization policy stored? How does the digital key communicate with
>
> the lock? Does the lock interact with an authorization server to obtain
>
> authorization information? How can access be temporarily granted to
>
> other persons? How can access be revoked? These types of questions have
>
> been answered by existing protocols for use cases outside constrained
>
> environments, however in constrained environments, additional and
>
> different requirements pose challenges for the use of various security
>
> protocols. In particular, the need arises for a dynamic and fine grained
>
> access control mechanism, where clients and/or resource servers are
>
> constrained.
>
>
>
> The IETF has a long history in developing three-party authentication and
>
> authorization protocols for distributed environments. Examples include
>
> Kerberos, the Public Key Infrastructure (PKI), the Authentication,
>
> Authorization and Accounting (AAA) infrastructure,and the Web
>
> Authorization Protocol (OAuth). All these protocols enjoy widespread
>
> deployment on the Internet. Although they all aim to solve a similar
>
> goal, at an abstract level, they offer quite different functions and
>
> utilize different message exchanges. These differences result from the
>
> main deployment use cases they were designed for respectively.
>
>
>
> Requirements derived from use cases may indicate that existing work is
>
> useful as basis for as a solution for constrained environments.
>
> These protocols,
>
> however, were not optimized for constrained environments. Additional
>
> requirements that need to be taken into account are the lack of a
>
> suitable user-interface and the inability of embedded devices to contact
>
> an authorization server in real-time with every resource access request
>
> due to intermittent connectivity, etc.
>
>
>
> This working group therefore aims to produce a standardized solution for
>
> authentication and authorization to enable authorized access (GET, PUT,
> POST,
>
> DELETE) to resources identified by a URI and hosted on a resource
>
> server in constrained environments. As a starting point, the working
>
> group will assume that access to resources at a resource server by a
>
> client device takes place using CoAP and is protected by DTLS. Both
>
> resource server and client may be constrained. This access will be
>
> mediated by an authorization server, which is not considered to be
>
> constrained.
>
>
>
> Existing authentication and authorization protocols will be evaluated
>
> and re-used where applicable to build the constrained-environment solution.
>
> This requires
>
> relevant specifications to be reviewed for suitability, selecting a
>
> subset of them and restricting the options within each of the
>
> specifications. Some functionality, however, may not be available in
>
> existing protocols, in which case the solution may also involve new
>
> protocol work. Leveraging existing work means the working group benefits
>
> from available security analysis, implementation, and deployment
>
> experience. Moreover, a standardized solution for federated
>
> authentication and authorization will help to stimulate the deployment
>
> of constrained devices that provide increased security.
>
>
>
> Once progress in identifying suitable candidate solutions has been made,
>
> the working group will verify whether the same mechanisms are also
>
> applicable beyond the use of CoAP and DTLS, which are the two main
>
> protocols the group will focus on for access to resources. In
>
> particular, the ability to use the developed solution over HTTP and TLS
>
> will be investigated. Note that the initial focus is on CoAP and HTTP with
> DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is
> maintained.
>
> The group is scoped to work only on the web protocols and data carried
> within them.
>
> Furthermore, to guarantee smooth transition, the
>
> integration with existing deployments will be studied, particularly
>
> concerning the use of protocol translation proxies.
>
>
>
> This work does not make the assumption that the party offering
>
> application layer services is always the same party offering network
>
> access services.
>
>
>
> The working group has the following tasks:
>
>
>
> 1) Produce use cases and requirements
>
>
>
> 2) Identify authentication and authorization mechanisms suitable for
>
> resource access in constrained environments.
>
>
>
> Milestones:
>
>
>
> Dec 2014 Submit "Use cases and Requirements" as a WG item.
>
> Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.
>
> Apr 2015 Optionally, submit "Use cases and Requirements" document
>
> to the IESG for publication as an Informational RFC.
>
> Jul 2016 Submit "Authentication and Authorization Solution"
>
> specification to the IESG for publication as a Proposed Standard.
>
>
>
> Proposed Milestones
>
> No milestones for charter found.
>
>
>
>
>
>
>
> *发件人:* Kathleen Moriarty [mailto:[email-masked]]
> *发送时间:* 2014年6月3日 14:30
> *收件人:* Likepeng
> *抄送:* Benoit Claise; [email-masked]; [email-masked]; The IESG;
> [email-masked]
> *主题:* Re: Revised charter proposal: charter-ietf-ace-00-02
>
>
>
> Hi Kepeng,
>
>
>
> If we are at a point where I can update the charter, seems that way,
> please send the latest version that has been agreed upon and I'll take care
> of the update.
>
>
>
> Thanks.
>
>
>
> On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <[email-masked]> wrote:
>
> Hi Benoit,
>
>
>
> >Not only would I keep "AAA",
>
>
>
> OK.
>
>
>
> >but I would propose
>
>
>
> >OLD:
>
> >Existing authentication and authorization protocols will be used where
>
> applicable to build the constrained-environment solution.
>
>
>
> >NEW:
>
> Existing authentication and authorization protocols will be evaluated and
> re-used where
>
> applicable to build the constrained-environment solution.
>
>
>
> OK, fine with me.
>
>
>
> Thanks for the feedback.
>
>
>
> Kind Regards
>
> Kepeng
>
>
>
> *发件人:* Benoit Claise [mailto:[email-masked]]
> *发送时间:* 2014年6月3日 12:16
>
> *收件人:* Likepeng; Kathleen Moriarty; [email-masked]
>
> *抄送:* [email-masked]; The IESG; [email-masked]
>
> *主题:* Re: Revised charter proposal: charter-ietf-ace-00-02
>
>
>
> Hi,
>
> Hello all,
>
>
>
> Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet.
>
>
>
> Please take a look and let us know if you have any further comments.
>
>
>
> @Adrian and @Benoit, please check if the proposed texts can resolve your comments.
>
>
>
> Thanks,
>
> Kind Regards
>
> Kepeng
>
>
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Compared with charter-ietf-ace-00-01 on the webpage, the changes are:
>
>
>
> (1)      Add one clarification sentence about REST architecture:
>
> OLD
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> REST architecture is widely used for such constrained environments.
>
>
>
> NEW
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> REST architecture is widely used for such constrained environments.
>
> END
>
>  Considering that OLD is
>
> OLD
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> ... fine with me
>
>
>
>
>
> (2)     Remove “AAA protocol” from the charter:
>
> OLD
>
> The IETF has a long history in developing three-party authentication and
>
> authorization protocols for distributed environments. Examples include
>
> Kerberos, the Public Key Infrastructure (PKI), the Authentication,
>
> Authorization and Accounting (AAA) infrastructure, and the Web
>
> Authorization Protocol (OAuth).
>
>
>
> NEW
>
> The IETF has a long history in developing three-party authentication and
>
> authorization protocols for distributed environments. Examples include
>
> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth).
>
> END
>
> We have AAA-doctors telling: maybe RADIUS is applicable?
> Personally, I don't know and it doesn't matter at this point.
> We received feedback such as:
>
> Let's be clear here: It was never said (in the charter or anywhere else in
> the group to my knowledge) that RADIUS (or indeed any other AAA protocol)
> would not run on constrained devices (RFC 7228). The charter simply said
> the protocols were not optimised for constrained devices. That does not
> preclude considering any protocol for suitability for constrained devices
> either a) as is, b) in a restricted way or c) in an adapted way.
>
> So, at this stage, I don't think any protocols should be excluded from
> consideration and should certainly not be eliminated on a hunch that they
> might be "too big". Let's do the assessment properly at the appropriate
> time. As a reminder - the focus now is to complete the charter.
>
> Or
>
> >>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.
>
> In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter.
>
>
>
> In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.
>
> ... which I read as: let's consider the AAA protocols, and evaluate if
> they would work in constrained devices.
> I don't understand the logic: why do you want to remove AAA from the
> charter?
> Not only would I keep "AAA", but I would propose
>
> OLD:
> Existing authentication and authorization protocols will be used where
> applicable to build the constrained-environment solution
>
> NEW:
> Existing authentication and authorization protocols will be evaluated and
> re-used where
> applicable to build the constrained-environment solution
>
> Regards, Benoit
>
>
>
>
>
> (3) Clarify the scope:
>
> OLD:
>
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is maintained.
>
> Other application protocols and protocols at other layers in the stack are out of scope.
>
>
>
> NEW
>
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is maintained.
>
> The group is scoped to work only on the web protocols and data carried within them.
>
> END
>
>
>
> (4)     Update milestones for the use case & requirements document:
>
> OLD:
>
> Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.
>
>
>
> NEW
>
> Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.
>
> END
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Charter charter-ietf-ace-00-02
>
> Authentication and Authorization for Constrained
>
> Environment (ACE)
>
>
>
> The IETF has recently developed protocols for use in constrained
>
> environments, where network nodes are limited in CPU, memory and power.
>
> REST architecture is widely used for such constrained environments.
>
> It has been observed that Internet protocols can be applied to these
>
> constrained environments, often only requiring minor tweaking and
>
> profiling. In other cases, new protocols have been defined to address
>
> the specific requirements of constrained environments. An example of
>
> such a protocol is the Constrained Application Protocol (CoAP).
>
>
>
> As in other environments, authentication and authorization questions
>
> also arise in constrained environments. For example, a door lock has to
>
> authorize the person seeking access using a "digital key". Where is the
>
> authorization policy stored? How does the digital key communicate with
>
> the lock? Does the lock interact with an authorization server to obtain
>
> authorization information? How can access be temporarily granted to
>
> other persons? How can access be revoked? These types of questions have
>
> been answered by existing protocols for use cases outside constrained
>
> environments, however in constrained environments, additional and
>
> different requirements pose challenges for the use of various security
>
> protocols. In particular, the need arises for a dynamic and fine grained
>
> access control mechanism, where clients and/or resource servers are
>
> constrained.
>
>
>
> The IETF has a long history in developing three-party authentication and
>
> authorization protocols for distributed environments. Examples include
>
> Kerberos, the Public Key Infrastructure (PKI), and the Web
>
> Authorization Protocol (OAuth). All these protocols enjoy widespread
>
> deployment on the Internet. Although they all aim to solve a similar
>
> goal, at an abstract level, they offer quite different functions and
>
> utilize different message exchanges. These differences result from the
>
> main deployment use cases they were designed for respectively.
>
>
>
> Requirements derived from use cases indicate the suitability of existing
>
> work as a solution for constrained environments. These protocols,
>
> however, were not optimized for constrained environments. Additional
>
> requirements that need to be taken into account are the lack of a
>
> suitable user-interface and the inability of embedded devices to contact
>
> an authorization server in real-time with every resource access request
>
> due to intermittent connectivity, etc.
>
>
>
> This working group therefore aims to produce a standardized solution for
>
> authentication and authorization to enable authorized access (GET, PUT, POST,
>
> DELETE) to resources identified by a URI and hosted on a resource
>
> server in constrained environments. As a starting point, the working
>
> group will assume that access to resources at a resource server by a
>
> client device takes place using CoAP and is protected by DTLS. Both
>
> resource server and client may be constrained. This access will be
>
> mediated by an authorization server, which is not considered to be
>
> constrained.
>
>
>
> Existing authentication and authorization protocols will be used where
>
> applicable to build the constrained-environment solution. This requires
>
> relevant specifications to be reviewed for suitability, selecting a
>
> subset of them and restricting the options within each of the
>
> specifications. Some functionality, however, may not be available in
>
> existing protocols, in which case the solution may also involve new
>
> protocol work. Leveraging existing work means the working group benefits
>
> from available security analysis, implementation, and deployment
>
> experience. Moreover, a standardized solution for federated
>
> authentication and authorization will help to stimulate the deployment
>
> of constrained devices that provide increased security.
>
>
>
> Once progress in identifying suitable candidate solutions has been made,
>
> the working group will verify whether the same mechanisms are also
>
> applicable beyond the use of CoAP and DTLS, which are the two main
>
> protocols the group will focus on for access to resources. In
>
> particular, the ability to use the developed solution over HTTP and TLS
>
> will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>
> Other security protocols may be considered as long as the primary focus is maintained.
>
> The group is scoped to work only on the web protocols and data carried within them.
>
> Furthermore, to guarantee smooth transition, the
>
> integration with existing deployments will be studied, particularly
>
> concerning the use of protocol translation proxies.
>
>
>
> This work does not make the assumption that the party offering
>
> application layer services is always the same party offering network
>
> access services.
>
>
>
> The working group has the following tasks:
>
>
>
> 1) Produce use cases and requirements
>
>
>
> 2) Identify authentication and authorization mechanisms suitable for
>
> resource access in constrained environments.
>
>
>
> Milestones:
>
>
>
> Jul 2014 Submit "Use cases and Requirements" as a WG item.
>
> Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.
>
> Dec 2014 Optionally, submit "Use cases and Requirements" document
>
> to the IESG for publication as an Informational RFC.
>
> Jul 2016 Submit "Authentication and Authorization Solution"
>
> specification to the IESG for publication as a Proposed Standard.
>
>
>
> Proposed Milestones
>
> No milestones for charter found.
>
>
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>

-- 

Best regards,
Kathleen