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

From: Margaret Wasserman <[email-masked]>
Date: Thu, 13 Mar 2014 06:55:19 -0400

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 02:37:37 +0100

On 03/13/2014 11:55 AM, Margaret Wasserman wrote:
> 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.

Thanks for your feedback, Margaret.

Btw, as part of the current charter we are not planning to capture what
existing technologies could or couldn't meet the requirements.

Would you see that as being useful?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Mar 2014 10:37:05 -0400

I propose that there be a use case Informational ID, which over time,
will transform into a roadmap/architectural document.  It will not be
published "prior" to the standards track documents, but since it will
be referenced by them all, they won't go forward either without it.

(this is essentially how homenet has turned out, but we didn't do it
intentionally... )

I agree with Hannes that we the use cases/requirements can be hard to
complete and the approach of "no desert until you finish your veggies"
sometimes works, but as often as not, it just means it takes a long time.

Pick someone to edit the use case document who really wants an RFC credit,
and their personal motiviation will get it done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 16:45:57 +0100

Hi Michael,

> be referenced by them all, they won't go forward either without it.

That's an interesting idea from a document management point of view.

It unfortunately does not answer the question when to start the solution
work. I fear that it will be difficult to come up with a good answer.

Of course I see the value to identify the key assumptions/requirements
(as we, for example, have done during the BOF) to cut through the
solution space. I had gotten the impression that a number of the folks
in the group are already very much bought into their own solution
approach and a lot of discussion on requirements/use cases will not
necessarily change their mind. I hope I am wrong.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Mar 2014 12:28:45 -0400

> work. I fear that it will be difficult to come up with a good answer.

Every piece of solution has to reference some part of problem space.

If the problem space (document) is incomplete, then that part/feature of the
solution has some problem with motivation.

This would seem to be the Agile approach: cycles.
When the cycle becomes empty, we are done.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Mar 2014 17:41:38 +0100

> work. I fear that it will be difficult to come up with a good answer.

This is a design problem, so you start solution work in parallel with understanding the feasible objectives.
(The solution space informs the objectives as much as the objectives inform the solutions.)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 17:50:07 +0100

I think that this approach is in-line with what Michael suggested.

Goeran (and others), is that OK for you as well?

The use cases/requirements/etc. document would then get roughly
published at the same time as the solution spec.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Mar 2014 18:22:42 +0100

> published at the same time as the solution spec.

That is a good goal.

Recalling my experience as a co-chair of 6LoWPAN, we managed to get out a use cases (RFC 6568) and a requirements (RFC 6606) document only after the main work was done (RFC 4944, RFC 6282; only RFC 6775 came in even later).  Of course we had them around as drafts much of the time we were working on the solutions, but it was hard to sustain the energy to actually publish the informational documents in the end.  It helped that we had a short early “problem statement, assumptions and goals” document out (RFC 4919), which solidified some of the terms that got used later, without trying to be the definitive requirements set.

I’m with Margaret in that I’d also 

> rather see the use cases and requirements published as informationalRFCs.

We just have to be aware that it’s not easy to keep up the energy on these.

(We also have to be wary of “requirements engineering”, i.e. manipulation of the requirements to favor one or the other solution.
Fortunately, we never tried to establish formal “requirements” in 6LoWPAN, so we circumvented this cliff.)

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Mar 2014 15:02:45 +0000

+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.
>
> existing technologies could or couldn't meet the requirements to 
> insure that our requirements are reality-based.
>
> Margaret
>
>
>
> To Hannes Tschofenig <[email-masked]>,Göran Selander 
> <[email-masked]>,Zach Shelby <[email-masked]>
> Cc [email-masked]
> 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,
> >

---

From: Zach Shelby <[email-masked]>
Date: Fri, 14 Mar 2014 08:31:47 -0700

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:

> <smime.p7s>_______________________________________________
> Ace mailing list
> [email-masked]

Zach Shelby
Director of Technology

-- 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

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Mar 2014 15:45:54 +0000

Use a Wiki to collect use cases and requirements, refine and produce a 
concise list. Then that could be cut and pasted into a single RFC - or 
if preferred, put into an annex in a technical specification - as long 
as the work has an endpoint and is captured in some document and not 
left in some nebulous Wiki. Someone mentioned homenet - I would not want 
to see that process emulated at all.

Robert

---

From: Zach Shelby <[email-masked]>
Date: Fri, 14 Mar 2014 09:39:03 -0700

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

> left in some nebulous Wiki.

Sure, I do think that would work.

Zach Shelby
Director of Technology

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 19 Mar 2014 11:06:42 +0100

> be referenced by them all, they won't go forward either without it.
...
> and their personal motiviation will get it done.

+1

I would do it "for the honour".

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 19 Mar 2014 12:42:07 +0100

> I would do it "for the honour".

I would contribute.

Steffi