Subject: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 13 May 2014 04:37:51 -0700

Adrian Farrel has entered the following ballot position for
charter-ietf-ace-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-ace/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Although I would prefer this to be written with fewer words, the
charter text is basically OK. However, there are couple of things
that need to clarified so I am raising a "Block". I hope we can
sort this out with a few simple changes.

   This working group therefore aims to produce a standardized 
   solution for authentication and authorization to enable
   authorized access to resources in constrained environments.

There are several mentions of "resources" and "resource servers" in the
text, but no clarity about what a resource is and what access to a 
resource means.

Reading the charter I don't see clearly that this work is limited to
specific protocols or specific places in the stack. I sense that the
intention is not to work on all protocols in constrained environments
but I don't think that is what the text actually says. I think that
the intention is to limit the work to the applications protocols with
their related transport protocols (withness CoAP and HTTP with DTLS
and TLS). Could this be called out more specifically?

---

From: Likepeng <[email-masked]>
Date: Tue, 13 May 2014 17:33:49 +0000

Hi Adrian and all,

>There are several mentions of "resources" and "resource servers" in the text, but no clarity about what a resource is and what access to a resource means.

About the "resource", we can take the definition from RFC2616:

   resource
      A network data object or service that can be identified by a URI,
      as defined in section 3.2. Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size, and
      resolutions) or vary in other ways.

For example, resources can be temperature sensors on a data collection node, or a list of alarms on a home security controller. [RFC6690]

Maybe we can add two explanations: one is that resources can be identified by a URI, two is that resources are hosted on the resource server.

"Access to a resource" means Get, Put, Post and Delete to a resource.

Here is the change proposal:

OLD
This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments.

NEW
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.
END

>Reading the charter I don't see clearly that this work is limited to specific protocols or specific places in the stack. I sense that the intention is not to work on all protocols in constrained environments but I don't think that is what the text actually says. I think that the intention is to limit the work to the applications protocols with their related transport protocols (withness CoAP and HTTP with DTLS and TLS). Could this be called out more specifically?

Yes, the main target of the solution is to work with CoAP/DTLS, but we also want it to be applicable for HTTP/TLS. Other protocols are out of the current scope.

Here is the change proposal:

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

NEW
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 work is limited to CoAP and HTTP with DTLS and TLS. Other application protocols with their related transport protocols are out of scope.
END

Does this solve your concern?

Thanks,

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2014年5月13日 19:38
收件人: The IESG
抄送: [email-masked]
主题: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Although I would prefer this to be written with fewer words, the charter text is basically OK. However, there are couple of things that need to clarified so I am raising a "Block". I hope we can sort this out with a few simple changes.

There are several mentions of "resources" and "resource servers" in the text, but no clarity about what a resource is and what access to a resource means.

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 13 May 2014 19:37:20 +0100

Hi,

> >There are several mentions of "resources" and "resource servers" in the text,
> but no clarity about what a resource is and what access to a resource means.
> 
> For example, resources can be temperature sensors on a data collection node,
or
> a list of alarms on a home security controller. [RFC6690]
> 
> Maybe we can add two explanations: one is that resources can be identified by
a
> URI, two is that resources are hosted on the resource server.
> 
> This working group therefore aims to produce a standardized solution for
> authentication and authorization to enable authorized access to resources in
> constrained environments.
> 
> NEW
> 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.
> END

Yes, OK. Good.
I think "hosted on a resource server" clinches it for me.
My main worry was that I could assign a URI to an interface or LSP. But this
text closes the concern.

> >Reading the charter I don't see clearly that this work is limited to specific
> protocols or specific places in the stack. I sense that the intention is not
to work
> on all protocols in constrained environments but I don't think that is what
the text
> actually says. I think that the intention is to limit the work to the
applications
> protocols with their related transport protocols (withness CoAP and HTTP with
> DTLS and TLS). Could this be called out more specifically?
> 
> Yes, the main target of the solution is to work with CoAP/DTLS, but we also
want
> it to be applicable for HTTP/TLS. Other protocols are out of the current
scope.
> 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.
> 
> NEW
> 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 work
is
> limited to CoAP and HTTP with DTLS and TLS. Other application protocols with
> their related transport protocols are out of scope.
> END

How about...

Other applications protocol with their related transport protocols, and other
protocols at other layers in the stack, are out of scope.

Thanks for engaging.
Adrian

---

From: Likepeng <[email-masked]>
Date: Tue, 13 May 2014 20:07:18 +0000

>Other applications protocol with their related transport protocols, and other protocols at other layers in the stack, are out of scope.

Looks good to me.

Thanks,

Kind Regards
Kepeng

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2014年5月14日 2:37
收件人: Likepeng; 'The IESG'
抄送: [email-masked]
主题: RE: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

Hi,

or
a
> This working group therefore aims to produce a standardized solution 
> for authentication and authorization to enable authorized access to 
> resources in constrained environments.
> 
> NEW
> 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.
> END

Yes, OK. Good.
I think "hosted on a resource server" clinches it for me.
My main worry was that I could assign a URI to an interface or LSP. But this text closes the concern.

> >specific
to work
the text
applications
> protocols with their related transport protocols (withness CoAP and 
> HTTP with DTLS and TLS). Could this be called out more specifically?
> 
want
scope.
> 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.
> 
> NEW
> 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 work
is
> limited to CoAP and HTTP with DTLS and TLS. Other application 
> protocols with their related transport protocols are out of scope.
> END

How about...

Other applications protocol with their related transport protocols, and other protocols at other layers in the stack, are out of scope.

Thanks for engaging.
Adrian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 May 2014 16:48:25 -0400

>>Other applications protocol with their related transport protocols,
>> and other protocols at other layers in the stack, are out of scope.
>
> Looks good to me.

Great; I've made the edits to address Adrian's and Alissa's comments,
and they're in version -00-01.

I've also changed the responsible AD to Kathleen Moriarty: unless
other ADs object, the WG will go into the Sec Area, not App, and
Kathleen will handle it.

Barry

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 May 2014 23:16:17 +0200

The resource edit is good.

Re: the scoping - for my personal purposes, the -00 text was more balanced to how I would have liked to see the group's scope set. It clearly laid out what the group's main focus is (CoAP and DTLS) but allowed exploration on whether solutions fit other purposes as well. The reason that I care about this is that I have worked on and want to work on data object security, as well as transport layer security. It is not clear to me why an authorisation solution needs to restrict itself to being used on the latter only.

This is indeed my personal opinion only, but I thought it would be useful to share as a datapoint of someone who wanted to work on this space.

Jari

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 May 2014 17:22:42 -0400

> Re: the scoping - for my personal purposes, the -00 text was more
> balanced to how I would have liked to see the group's scope set. It
> clearly laid out what the group's main focus is (CoAP and DTLS) but
> allowed exploration on whether solutions fit other purposes as well.
> The reason that I care about this is that I have worked on and want to
> work on data object security, as well as transport layer security. It
> is not clear to me why an authorisation solution needs to restrict
> itself to being used on the latter only.

I understand, but I think it's always been the intent for this work to
start at the App layer only, and to consider looking at other
protocols and layers later.  I would want us to get this work done
first in any case, and then re-charter to go further.

If you disagree with that plan, let's talk about it and see where it brings us.

Barry

---

From: Göran Selander <[email-masked]>
Date: Wed, 14 May 2014 05:24:46 +0000

Adrian, and all

>and TLS). Could this be called out more specifically?

I understand the concern that the work would not be sufficiently focused
unless restricting to specific protocols or protocol layers. I¹m fine with
restricting to HTTP and CoAP for access to resources, but I like to
understand exactly what is meant by limiting the work to TLS/DTLS.

As I understand the problem, it is about a multi-party protocol where a
third party supports a client and a server, which are constrained, to
perform authenticated and authorized access. The third party is assumed to
have established a key/security association at least with the server to
perform this. Compare section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00

The fact that the client and server are constrained implies in particular
that a DTLS handshake has a significant performance impact. If we really
want it to support the constrained devices, we would use the established
security association(s) and allow the third party to also be involved in
authentication and key establishment between client and resource server.
Compare e.g. OAuth 2.0 MAC Tokens
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-04

Now, the 00-01 version of the charter says:

"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 work is limited to CoAP and HTTP
with DTLS and TLS. Other application protocols with their related
transport protocols, and other protocols at other layers in the stack,
are out of scope."

When I first read ³other protocols Š are out of scope" I wondered if this
multi-party protocol mentioned above is at all in scope. Maybe we could
reformulate to make this clear?

Assuming that the multi-party protocol is in scope, what is this protocol
allowed to do? Only support with authorization information, or also
support client-server with authentication and/or key establishment?

If the latter is true, must the client-server anyway run DTLS? Or can the
multi-party protocol in some aspect replace overlapping functionality in
DTLS (and thereby reduce its performance impact)?

Göran

---

From: Corinna Schmitt <[email-masked]>
Date: Wed, 14 May 2014 08:29:00 +0200

Dear Barry,

I had the same understanding as you when writing our draft on two-way 
authentication.
 From my side it is the best to start with the App layer in order to 
allow layer changes below without effecting the solution.
Looking on the other layers can be done later.

Regards,
Corinna

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 14 May 2014 09:09:26 +0200

>> Other applications protocol with their related transport protocols, and other protocols at other layers in the stack, are out of scope.

Would this place work with CoAP + Object Security (instead of DTLS) out
of scope?

/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: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 May 2014 11:10:57 +0100

I have no attachment to the specific transports, and would be happy with the
constraint being voiced as security or application layer protocols.

My mention of DTLS and TLS was just picking up the text that was already there.

A

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: 14 May 2014 06:25
> To: Adrian Farrel; The IESG
> Cc: [email-masked]
> Subject: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with
BLOCK)

---

From: Göran Selander <[email-masked]>
Date: Wed, 14 May 2014 13:12:07 +0000

Adrian, thanks for clarification.

I don’t want to reopen this, but I think that the latest changes are a bit
misleading, in particular

"Note that the work is limited to CoAP and HTTP with DTLS and TLS. Other
application protocols with their related
transport protocols, and other protocols at other layers in the stack, are
out of scope.”

There is at least the multi-party protocol (referenced to as as “Existing
authentication and authorization protocols” in the preceding paragraph of
the charter) in scope. Its functionality may potentially complement or
overlap DTLS/TLS (e.g. providing keys, security context etc.) If we
consider this functionality out of scope at this stage we are making a
safe bet that the solution will not be optimal for constrained
environments.

So, the limitation to CoAP and HTTP is fine. DTLS and TLS as working
assumption/default security protocol is OK, but I think we should be open
to optimisations.

What do others think about this?

Göran

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 May 2014 10:46:52 -0400

> I don't want to reopen this, but I think that the latest changes are a bit
> out of scope."
> There is at least the multi-party protocol (referenced to as as "Existing
> authentication and authorization protocols" in the preceding paragraph of

I think you make a reasonable point: we've perhaps gone too far in the
attempt to restrict the layers we're working on -- there's a
difference between focusing on DTLS and TLS... and putting
consideration of anything else out of scope.  On the other hand, we
*do* want the WG to focus its work on the initial solution for now,
and not spend its time veering off.

Perhaps this works better?:

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.  Other application protocols and protocols at other
layers in the stack are out of scope.
END

Barry

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 May 2014 09:56:13 -0500

On Wed, May 14, 2014 at 9:46 AM, Barry Leiba <[email-masked]>wrote:

> are
I support this.
Why not allow EAP?

Regards,

Behcet

---

From: Göran Selander <[email-masked]>
Date: Wed, 14 May 2014 15:15:31 +0000

>layers in the stack are out of scope.

Fine by me.

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 May 2014 17:33:38 +0200

> layers in the stack are out of scope.

The question is a good summary of a potential problem with the new text above (as much as I support what it is trying to do) — the point of ACE is *not* to cover everybody’s favorite security protocol.

Grüße, Carsten

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 May 2014 19:07:17 +0100

wfm

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry
> Leiba
> Sent: 14 May 2014 15:47
> To: Göran Selander
> Cc: [email-masked]; The IESG; [email-masked]
BLOCK)

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 May 2014 13:27:31 -0500

On Wed, May 14, 2014 at 10:33 AM, Carsten Bormann <[email-masked]> wrote:

> The question is a good summary of a potential problem with the new text
> above (as much as I support what it is trying to do) — the point of ACE is
> *not* to cover everybody’s favorite security protocol.
>
>
My intention was not to ask a question, it was a comment in support of the
proposed new text.

Behcet

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 May 2014 14:45:12 -0400

Thank you, it appears we are all in agreement then with the update.

-- 

Best regards,
Kathleen

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 May 2014 10:37:18 +0200

> protocols and layers later.

Well, what I wanted to look at was on the applications layer (e.g., data object security), not on other layers.

> I would want us to get this work done

I do agree with the plan, but my point was that the original charter version was on that plan as well while still recognising the applicability of the results to other things. My opinion is that the previous version was better, and would probably get more of us interested in working on the topic.

Jari

---

From: Likepeng <[email-masked]>
Date: Sun, 18 May 2014 20:52:21 +0000

>I do agree with the plan. 
Glad to see we are on the same page for the plan.

How about this rewording?
The working group will not work on other application protocols with their related transport protocols, and other protocols at other layers in the stack, until the work on CoAP and HTTP with DTLS and TLS is completed.

I think the important message we want to convey is, we will not work on authentication and authorization for application protocols like OMA DM, transport protocols like SMS /USSD etc.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Jari Arkko
发送时间: 2014年5月15日 16:37
收件人: Barry Leiba
抄送: [email-masked] Farrel; The IESG; [email-masked]
主题: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

Jari

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 May 2014 22:26:58 +0100

Sorry to be a pain, but that is a definite "no" from me.

That says...
The WG will (or can) work on security for routing protocols once it has finished
with CoAP and HTTP with DTLS and TLS.

How about...

The working group must complete the CoAP and HTTP with DTLS and TLS and be
rechartered before taking on work on other application protocols with their
related transport protocols. Work on other protocols at other layers in the
stack is out of scope.

Thanks,
Adrian

> From: Ace [mailto:[email-masked]] On Behalf Of Likepeng
> Sent: 18 May 2014 21:52
> To: Jari Arkko; Barry Leiba
> Cc: [email-masked] Farrel; The IESG; [email-masked]
BLOCK)
> The working group will not work on other application protocols with their
related
> transport protocols, and other protocols at other layers in the stack, until
the
> work on CoAP and HTTP with DTLS and TLS is completed.
> 
> I think the important message we want to convey is, we will not work on
> authentication and authorization for application protocols like OMA DM,
> transport protocols like SMS /USSD etc.
> 
> Kind Regards
> Kepeng
> 
> -----邮件原件-----
> Well, what I wanted to look at was on the applications layer (e.g., data
object
> security), not on other layers.
> 
> I do agree with the plan, but my point was that the original charter version
was on
> that plan as well while still recognising the applicability of the results to
other
> things. My opinion is that the previous version was better, and would probably
> get more of us interested in working on the topic.
> 
> Jari
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 May 2014 23:46:03 +0200

> related transport protocols. Work on other protocols at other layers in the

That sounds like a plan to eventually conquer those other application protocols.
Is this really what we tell people we are planning to do?
If addressing application protocols outside the REST turns out to be useful, we can recharter at any time without seemingly making such a promise now.

Grüße, Carsten

(Should have called it ACRE, not ACE…)

---

From: Robert Cragie <[email-masked]>
Date: Mon, 19 May 2014 09:26:41 +0100

+1

I also think this is workable plan going forward.

Robert

(+1 to ACRE as well :-)

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 May 2014 08:49:06 +0100

Carsten, I agree with you, and *I* am happy with the text currently on the web
page.

But others are not happy so I am looking for middle ground.

A

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: 18 May 2014 22:46
> To: [email-masked]
> Cc: Likepeng; Jari Arkko; Barry Leiba; The IESG; [email-masked]
BLOCK)
> If addressing application protocols outside the REST turns out to be useful,
we
> can recharter at any time without seemingly making such a promise now.
> 
> Grüße, Carsten
>

---

From: Likepeng <[email-masked]>
Date: Mon, 19 May 2014 09:49:02 +0000

>The working group must complete the CoAP and HTTP with DTLS and TLS and be rechartered before taking on work on other application protocols with their related transport protocols. Work on other protocols at other layers in the stack is out of scope.

Fine with me.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2014年5月19日 5:27
收件人: Likepeng; 'Jari Arkko'; 'Barry Leiba'
抄送: 'The IESG'; [email-masked]
主题: RE: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

That says...
The WG will (or can) work on security for routing protocols once it has finished with CoAP and HTTP with DTLS and TLS.

How about...

The working group must complete the CoAP and HTTP with DTLS and TLS and be rechartered before taking on work on other application protocols with their related transport protocols. Work on other protocols at other layers in the stack is out of scope.

Thanks,
Adrian

BLOCK)
related
> until
the
> I think the important message we want to convey is, we will not work 
> on authentication and authorization for application protocols like OMA 
> DM, transport protocols like SMS /USSD etc.
> 
> Kind Regards
> Kepeng
> 
> -----邮件原件-----
> > I understand, but I think it's always been the intent for this work 
> > to start at the App layer only, and to consider looking at other 
object
> > I would want us to get this work done first in any case, and then 
> > re-charter to go further.
> >
> > If you disagree with that plan, let's talk about it and see where it 
> > brings
us.
was on
other
> things. My opinion is that the previous version was better, and would 
> probably get more of us interested in working on the topic.
> 
> Jari
>

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 19 May 2014 12:23:46 +0200

>> The working group must complete the CoAP and HTTP with DTLS and TLS and be rechartered before taking on work on other application protocols with their related transport protocols. Work on other pr…

I'd rather like the charter to concentrate on what we want to do now and
not speculate about things we might want to do after rechartering.

Thanks,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 19 May 2014 12:05:08 +0000

Sorry for re-iterating, but I’m still missing the multi-party protocol
which provides the authorization information and supports client-server
with key establishment.

http://www.ietf.org/mail-archive/web/ace/current/msg00572.html
http://www.ietf.org/mail-archive/web/ace/current/msg00577.html

I read the current draft, as well as the proposal below, as if this
protocol is explicitly out of scope, which I interpret that the WG is not
going to work on things related to authorization at all.

Göran

On 18/05/14 23:26, "Adrian Farrel" <[email-masked]> wrote:

>>probably

---

From: Likepeng <[email-masked]>
Date: Mon, 19 May 2014 12:32:55 +0000

Hi Goran and all,

It seems that we were in agreement about Barry's proposed text:
http://www.ietf.org/mail-archive/web/ace/current/msg00577.html
http://www.ietf.org/mail-archive/web/ace/current/msg00583.html

NEW

Only Jari prefers the original text (-00 version). 

So if Jari can live with Barry's proposal, maybe we can move on with that one.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
发送时间: 2014年5月19日 20:05
收件人: [email-masked]; Likepeng; 'Jari Arkko'; 'Barry Leiba'
抄送: 'The IESG'; [email-masked]
主题: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

Sorry for re-iterating, but I’m still missing the multi-party protocol which provides the authorization information and supports client-server with key establishment.

I read the current draft, as well as the proposal below, as if this protocol is explicitly out of scope, which I interpret that the WG is not going to work on things related to authorization at all.

Göran

On 18/05/14 23:26, "Adrian Farrel" <[email-masked]> wrote:

>The WG will (or can) work on security for routing protocols once it has 
>finished with CoAP and HTTP with DTLS and TLS.
>
>How about...
>
>The working group must complete the CoAP and HTTP with DTLS and TLS and 
>be rechartered before taking on work on other application protocols 
>with their related transport protocols. Work on other protocols at 
>other layers in the stack is out of scope.
>
>Thanks,
>Adrian
>
>
>> on authentication and authorization for application protocols like 
>> OMA DM, transport protocols like SMS /USSD etc.
>> 
>> Kind Regards
>> Kepeng
>> 
>> -----邮件原件-----

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 May 2014 15:05:15 +0300

> So if Jari can live with Barry's proposal, maybe we can move on with that one.
...
> I think the important message we want to convey is, we will not work on authentication and authorization for application protocols like OMA DM, transport protocols like SMS /USSD etc.

To clarify my position, I have been commenting as someone interested on this topic. About things that I would be willing to spend my time on around this WG. I do not think it would be appropriate for me to use my AD powers to force changes related to my preferences into the charter unless it is seriously broken. Group consensus should be the rule. So if I'm in the minority, feel free to ignore me :-)

In any case, I fully agree with what you said above about OMA DM, USSD, and so on; I do not want to work on those.

But I do believe that if we are creating an authorisation solution for constrained devices, it should have at least a little bit of generality in it. And I do not believe achieving this would be hard. Here's an example of something I would like to do: the basic setup in the working group is to be able to authorise a <trusted device> to instruct, say, a <thermostat> to maintain a particular temperature. This is a very transport-related way of looking at the problem, however. I would like to do things like sending the <thermostat> a <temperature schedule> that is signed by the <home owner>, and authorising the <thermostat> to trust information from that source. So my interests are not just in transport layer security, but in data object security. You can imagine various ways of implementing this, say S/MIME or JOSE signed pieces of information delivered over CoAP or HTTP. The details don't really matter at this point, but a reason I wanted to participate in this work was to make sure that our authz designs can do that later.

Can I live with the above text? Not sure, because I'm not sure how to interpret it. For instance, if the WG produced a solution that was able to do authz for CoAP/HTTP when used with DTLS, TLS, or JOSE, would that fall inside our outside what the text says? I think probably inside, because the second sentence allows looking at other security protocols as long as the focus is maintained. 

If I can suggest an edit, I'd say:

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

Jari

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 May 2014 09:48:51 -0400

> Can I live with the above text? Not sure, because I'm not sure how
> to interpret it. For instance, if the WG produced a solution that was
> able to do authz for CoAP/HTTP when used with DTLS, TLS, or
> JOSE, would that fall inside our outside what the text says? I think
> probably inside, because the second sentence allows looking at
> other security protocols as long as the focus is maintained.
>

For what it's worth, I like Jari's adjustment.

Barry

---

From: Robert Cragie <[email-masked]>
Date: Wed, 21 May 2014 13:38:42 +0100

I like it too and it captures the sentiment of the charter as I see it.

Robert

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 May 2014 11:36:45 -0500

Me too as long as it allows all architectures in draft-tschofenig-ace-overview.

Behcet