Subject: Re: [Ace] ACE Charter Proposal v0.5

From: Margaret Wasserman <[email-masked]>
Date: Tue, 18 Mar 2014 09:37:57 -0400

Publishing the requirements and use cases in an RFC is NOT the same thing as gating our other work on publishing those things first -- I would object to a phased charter that requires us to publish our use cases and requirements as RFCs before we do any protocol work, and I like the idea of using a wiki to collect and refine them.

We should remember, though, that we will need to involve a wide range of IETF participants, including multiple IETF security experts, to be successful.  Not all of those people will have worked in the IoT/embedded space, so documenting the use cases and requirements early in the process (on a wiki page is fine) will be essential to allowing that wider set of IETF participants to engage constructively.

I'd personally like to see the use cases and requirements captured in an achival form that can be referenced later, because I think the use cases, in particular, might be useful for later work.  I'd be perfectly happy with publishing them as RFCs later in the process, though.

If people would rather try to capture the major use cases and motivations in the protocol spec instead, I guess that would work for me, but I would somewhat prefer an uncluttered protocol spec that refers to supporting informational documents.  

Margaret

-------- Original message --------
From Zach Shelby <[email-masked]> 
Date: 03/14/2014  11:31 AM  (GMT-05:00) 
To [email-masked] 
Cc [email-masked] 
Subject Re: [Ace] ACE Charter Proposal v0.5 
 
As I mentioned in the BoF, my advice would be to just use a wiki to collect use cases and requirements.

Now, if we want to waste the first half year brining such drafts through the RFC process then go ahead. From my experience these kinds of work items are just a WG black hole. You can always document the assumed use cases within the actual technical specification to make it clear what problem it is trying to solve.

Zach

On Mar 14, 2014, at 8:02 AM, Robert Cragie <[email-masked]> wrote:

> +1 to both Margaret's statements.
>
> Robert
>
> On 13/03/2014 10:55 AM, Margaret Wasserman wrote:
>> Personally, I would also rather see the use cases and requirements published as informationalRFCs.  I think that a wiki might be a good way to collect them at first, but I would prefer to be sure that we have consensus on the problem(s) we are trying to solve.  I also think it will be useful to have these things in archival form later.
>>
>> I do not think the other work of the group should be gated on the requirements, though, as I think that it makes sense to explore how existing technologies could or couldn't meet the requirements to insure that our requirements are reality-based.
>>
>> Margaret
>>
>>
>>
>> -------- Original message --------
>> From Likepeng <[email-masked]>
>> Date: 03/13/2014 4:28 AM (GMT-05:00)
>> To Hannes Tschofenig <[email-masked]>,Göran Selander <[email-masked]>,Zach Shelby <[email-masked]>
>> Cc [email-masked]
>> Subject Re: [Ace] ACE Charter Proposal v0.5
>>
>>
>> My personal opinion is that the use case and requirements document can help people to understand what kind of issues we are trying to resolve.
>>
>> I can see some values to publish it into RFCs. If it is a wiki page, we will have less people to review it or improve it.
>>
>> Especially the use case and requirement document is already in a good shape and it is referenced several times in the mailing list to introduce our work to outside.
>>
>> Thanks,
>>
>> Kind Regards
>> Kepeng
>>
>> > -----邮件原件-----
>> > 发件人: Ace [mailto:[email-masked]] 代表 Hannes Tschofenig
>> > 发送时间: 2014年3月13日 4:33
>> > 收件人: Göran Selander; Zach Shelby
>> > 抄送: [email-masked]
>> > 主题: Re: [Ace] ACE Charter Proposal v0.5
>> >
>> > Hi Goeran,
>> >
>> > I read a little bit between the lines of your mail and your main concern is that
>> > you want to have an RFC published with your name on it.
>> > A wiki page to document the requirements, and use cases is not good enough
>> > for you.
>> >
>> > For you putting the draft text on a WG wiki feels like wasted time.
>> > It is just a different form of documenting the work.
>> >
>> > My experience with use cases and requirements has not been great in the IETF.
>> > In essence everyone quickly moves on once the group decides about a
>> > particular solution direction. It then becomes very hard (for the
>> > chairs) to finish the requirements work since nobody wants to review or look
>> > at them anymore.
>> >
>> > Use cases and requirements are great during the initial part of the work to get
>> > an understanding of the main challenges.
>> >
>> > Having said that I will leave it to the group to decide what they want to do:
>> > RFCs or Wiki page
>> >
>> > Ciao
>> > Hannes
>> >
>> > PS: Regarding your other comment about pointing to the constraint nature to
>> > every item. We can do that if you feel better but the entire charter page
>> > already says 10 times that we are focusing on the constraint space.
>> > I am sure that the reader will have understood that when they get to the task
>> > list.
>> >
>> >
>> > On 03/12/2014 10:32 AM, Göran Selander wrote:
>> > > Hannes, Zach and all,
>> > >
>> > > I must say I don¹t find the task list of the current charter very helpful:
>> > >
>> > > ³The working group has the following tasks (in this order):
>> > >
>> > > 1) The working group Wiki pages will be used to document use cases,
>> > > requirements, and protocol design criteria. This work will guide the
>> > > identification of suitable protocol mechanisms.
>> > >
>> > > 2) Selection of an authentication and authorization protocol for
>> > > constrained environments.
>> > >
>> > > 3) Evaluation of the candidate solution for use with HTTP/TLS and
>> > > proxy deployments.²
>> > >
>> > > This list does not give much more details about the work to be
>> > > conducted than is already given by the title of the WG. To a person
>> > > not having followed the discussion, the impression is that the work
>> > > starts from scratch and there is no clear understanding of what to do.
>> > >
>> > > If we can¹t formulate the problem statement and first step towards a
>> > > solution in some degree of detail before starting the WG that will
>> > > anyway be the first task to do, so let¹s try to get something in writing.
>> > >
>> > >
>> > > "1) The working group Wiki pages will be used to document use cases,
>> > > requirements, and protocol design criteria. This work will guide the
>> > > identification of suitable protocol mechanisms."
>> > >
>> > > This is hiding the fact that there has been 6 months of work on the
>> > > use case and requirements draft (the first version of this draft was
>> > > submitted to CoRE in IETF88), which no one has disagreed is setting
>> > > the stage for this work. Look at parallel threads on this mailing list
>> > > where people ask whether their particular security-for-IoT draft fits
>> > > into ACE. The answer Hannes is giving is correctly: the scope of this
>> > > work is what is outlined by the use case and requirements draft. I
>> > > don¹t mind using the Wiki as a working tool but this does not give
>> > > traceability a year later. And I don¹t see the point if copying the
>> > > use case document into a Wiki page - read the draft and provide your
>> > comments!
>> > >
>> > > When it comes to protocol design criteria, I agree that more work is
>> > > needed, for which the Wiki may be suitable. Nevertheless I insist on
>> > > documenting the design criteria and its rationale since that provides
>> > > a means for traceability. Make it a milestone to have a draft with
>> > > assumptions and design criteria  (you may include ³architecture² in
>> > > this document). This work is anyway a pre-requisite for coming to a
>> > > solution, and once you have this content, the candidate solutions are
>> > > much easier evaluated.
>> > >
>> > > So, change 1) to state something like
>> > >
>> > > "1¹ )
>> > > a) complete the work on use case and requirements
>> > > b) use Wiki pages for listing assumptions and protocol design
>> > > criteria, document the result in a draft"
>> > >
>> > > Proxy deployment aspects fits well into 1b)  [more in separate
>> > > upcoming mail]
>> > >
>> > >
>> > > 2) Selection of an authentication and authorization protocol for
>> > > constrained environments.
>> > >
>> > > Here I¹m missing among other things the specific problem statement.
>> > > The preliminary conclusions from the use case and requirements draft
>> > > formed the basis for the problem statement as presented in the BOF: We
>> > > lack a mechanism for dynamic and fine grained access control for
>> > > constrained environments.
>> > >
>> > > The process here should be to:
>> > > "2¹) identify suitable protocol mechanisms and match candidate
>> > > authentication and authorization protocols against requirements and
>> > > design criteria, in particular addressing dynamic and fine grained
>> > > access control suitable for CoAP resource access requests in constrained
>> > environments."
>> > >
>> > >
>> > >
>> > > 3) Evaluation of the candidate solution for use with HTTP/TLS and
>> > > proxy deployments.²
>> > >
>> > >
>> > > As mentioned above, proxy deployments could be considered as part of
>> > 1¹b).
>> > > In 2¹) it is already stated that in particular we should consider CoAP
>> > > on interface (II). As for use of other protocols besides CoAP that
>> > > issue is orthogonal to this so I leave that out from this discussion.
>> > >
>> > >
>> > >
>> > > Göran
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On 11/03/14 16:49, "Zach Shelby" <[email-masked]> wrote:
>> > >
>> > >> Hannes,
>> > >>
>> > >> I am happy with this charter with one exception. The proxy item here
>> > >> seems to be more of a distraction than anything else, and will
>> > >> probably result in increased complexity. Was proxy support maybe just
>> > >> a misunderstanding? Do we really see the need for a proxy in the
>> > >> middle of I or III?
>> > >>
>> > >> I think what we really want here is to make sure that e.g. even
>> > >> through I is based on HTTP/TLS, II and III for example can run
>> > >> CoAP/DTLS. In other words, some interfaces can be constrained while
>> > >> others are not. I think the charter already covers this fine.
>> > >>
>> > >> So my proposal would be to remove the mention of protocol translation
>> > >> proxies. If we really see the need for this some day in the future,
>> > >> it could be tackled then.
>> > >>
>> > >> Zach
>> > >>
>> > >> On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig
>> > >> <[email-masked]> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> I have taken the feedback from the meeting and the recent
>> > >>> discussions on the mailing list and produced a new strawman proposal.
>> > >>>
>> > >>> The changes include:
>> > >>> * Added the focus on DTLS/CoAP with an indication that we will check
>> > >>> a candidate solution for suitability with HTTP/TLS.
>> > >>> * Added text to indicate that we will also verify the suitability of
>> > >>> the solution for use with protocol translation proxies.
>> > >>> * Simplified the task list by removing solution specific items.
>> > >>> * Merged several items on the task list (use cases, requirements,
>> > >>> and protocol design guidelines). Followed the suggestion to use of a
>> > >>> Wiki for capturing those.
>> > >>>
>> > >>> What do you think?
>> > >>>
>> > >>> -----
>> > >>>
>> > >>> Draft Charter V0.5 - Authentication and Authorization for
>> > >>> Constrained Environment (ACE)
>> > >>>
>> > >>> The IETF has recently developed protocols for use in environments
>> > >>> where network nodes are limited in CPU, memory, and power. It was
>> > >>> 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 devices and networks. An example of such
>> > >>> a protocol is the Constrained Application Protocol (CoAP).
>> > >>> components
>> > >>> As in other environments, authentication and authorization question
>> > >>> also arise in environments with constrained nodes and networks. For
>> > >>> example, a door lock has to authorize the person seeking access
>> > >>> using a "digital key". Where are the authorization decisions 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 granted to other persons temporarily?
>> > How can access be revoked?
>> > >>> These types of questions have been answered by existing protocols
>> > >>> for use cases outside the constrained environment. But in
>> > >>> constrained environment, additional requirements pose challenges for
>> > >>> the use of various security protocols.
>> > >>>
>> > >>> 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 are motivated by the main deployment use cases they were
>> > designed for.
>> > >>>
>> > >>> Requirements derived from use cases indicate the suitability of
>> > >>> already existing work, such as OAuth, as a solution for constrained
>> > >>> environments. These protocols were, however, not optimized for
>> > >>> constrained environments. Additional requirements that need to be
>> > >>> taken into account are the lack of a suitable user-interface for
>> > >>> obtaining the consent of the user and the inability of embedded
>> > >>> devices to contact an authorization server in real-time with every
>> > >>> access request due to intermittent connectivity, etc.
>> > >>>
>> > >>> This working group therefore aims for a standardized solution for
>> > >>> authentication and authorization to enable authorized access to
>> > >>> resources in constrained environments. As a starting point, the
>> > >>> working group will assume that access to resources offered by a
>> > >>> resource server by a client devices takes place using CoAP and is protected
>> > by DTLS.
>> > >>> Both resource server and client may be resource constraint. This
>> > >>> access will be mediated by an authorization server, which does not
>> > >>> suffer from the same resource limitations.
>> > >>>
>> > >>> Existing authentication and authorization protocols are used and
>> > >>> re-applied for use with constrained devices, where applicable. This
>> > >>> requires relevant specifications to be reviewed for suitability,
>> > >>> selecting a subset of them, restricting the options within each of
>> > >>> the specifications. Some functionalities may, however, not be
>> > >>> available in existing protocols and for those cases new
>> > >>> functionality has to be standardized. Thus, existing work can be
>> > >>> leveraged and the 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 IoT devices offering increased security.
>> > >>>
>> > >>> Once progress in identifying suitable candidate solutions has been
>> > >>> made the working group will verify whether the same mechanism are
>> > >>> also applicable beyond the use of CoAP and DTLS. In particular, the
>> > >>> ability to use the developed solution over HTTP and TLS will be
>> > investigated.
>> > >>> Furthermore, to guarantee smooth transition the integration with
>> > >>> existing deployment will be studied. This particularly concerns the
>> > >>> use of protocol translation proxies.
>> > >>>
>> > >>> To be successful this working group requires expertise in security,
>> > >>> privacy, and a good understanding of usability in the constrained
>> > >>> environment space. 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 (in this order):
>> > >>>
>> > >>> 1) The working group Wiki pages will be used to document use cases,
>> > >>> requirements, and protocol design criteria. This work will guide the
>> > >>> identification of suitable protocol mechanisms.
>> > >>>
>> > >>> 2) Selection of an authentication and authorization protocol for
>> > >>> constrained environments.
>> > >>>
>> > >>> 3) Evaluation of the candidate solution for use with HTTP/TLS and
>> > >>> proxy deployments.
>> > >>>
>> > >>> -----
>> > >>>
>> > >>> Ciao
>> > >>> Hannes
>> > >>>
>> > >>> <signature.asc>_______________________________________________
>> > >>> Ace mailing list
>> > >>> [email-masked]
>> > >>> https://www.ietf.org/mailman/listinfo/ace
>> > >>
>> > >> Zach Shelby
>> > >> Director of Technology
>> > >> ARM Internet of Things BU
>> > >> www.arm.com
>> > >> mobile: +1 (408) 203-9434
>> > >> Skype: zdshelby
>> > >> LinkedIn: fi.linkedin.com/in/zachshelby/
>> > >>
>> > >>
>> > >> -- IMPORTANT NOTICE: The contents of this email and any attachments
>> > >> are confidential and may also be privileged. If you are not the
>> > >> intended recipient, please notify the sender immediately and do not
>> > >> disclose the contents to any other person, use it for any purpose, or
>> > >> store or copy the information in any medium.  Thank you.
>> > >>
>> > >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> > >> Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
>> > >> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
>> > >> England & Wales, Company No:  2548782
>> > >>
>> > >> _______________________________________________
>> > >> Ace mailing list
>> > >> [email-masked]
>> > >> https://www.ietf.org/mailman/listinfo/ace
>> > >
>> > > _______________________________________________
>> > > Ace mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/ace
>> > >
>>
>> _______________________________________________
>> Ace mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>>
>> _______________________________________________
>> Ace mailing list
>>
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ace
>
> <smime.p7s>_______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Likepeng <[email-masked]>
Date: Wed, 19 Mar 2014 08:53:26 +0000

>I would object to a phased charter that requires us to publish our use cases and requirements as RFCs before we do any protocol work.

Let’s remove “in this order” before the task list in the charter.

>I'd be perfectly happy with publishing them as RFCs later in the process, though.

OK, got it.

Kind Regards
Kepeng

发件人: Ace [mailto:[email-masked]] 代表 Margaret Wasserman
发送时间: 2014年3月18日 21:38
收件人: Zach Shelby; [email-masked]
抄送: [email-masked]
主题: Re: [Ace] ACE Charter Proposal v0.5

Margaret

-------- Original message --------
From Zach Shelby <[email-masked]<mailto:[email-masked]>>
Date: 03/14/2014 11:31 AM (GMT-05:00)
To [email-masked]<mailto:[email-masked]>
Cc [email-masked]<mailto:[email-masked]>
Subject Re: [Ace] ACE Charter Proposal v0.5

Zach

On Mar 14, 2014, at 8:02 AM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

>> From Likepeng <[email-masked]<mailto:[email-masked]>>
>> To Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>,Göran Selander <[email-masked]<mailto:[email-masked]>>,Zach Shelby <[email-masked]<mailto:[email-masked]>>
>> Cc [email-masked]<mailto:[email-masked]>
>> > 抄送: [email-masked]<mailto:[email-masked]>
>> > > On 11/03/14 16:49, "Zach Shelby" <[email-masked]<mailto:[email-masked]>> wrote:
>> > >
>> > >> Hannes,
>> > >>
>> > >> <[email-masked]<mailto:[email-masked]>> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> [email-masked]<mailto:[email-masked]>
>> > >> www.arm.com<http://www.arm.com>
>> > >> [email-masked]<mailto:[email-masked]>
>> > > [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com<http://www.arm.com>
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

[email-masked]<mailto:[email-masked]>

---

From: Göran Selander <[email-masked]>
Date: Thu, 20 Mar 2014 09:04:11 +0000

From: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Reply-To: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 18 March 2014 14:37
To: Zach Shelby <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] ACE Charter Proposal v0.5

Publishing the requirements and use cases in an RFC is NOT the same thing as gating our other work on publishing those things first -- I would object to a phased charter that requires us to publish our use cases and requirements as RFCs before we do any protocol work,

I agree

and I like the idea of using a wiki to collect and refine them.

I agree and I do think we already have a document on a first set of use cases and requirements to put in the hands of those security experts. Disregarding the wrapping (draft or Wiki) I have heard very few comments about content or structure.

I support that. And we could use a Wiki first and then copy into a draft. What I’d like to know is what are the concerns about the current draft or could we reuse the structure and have the Wiki as a medium for editing this draft?

Göran