From nobody Sun Jan 3 11:12:40 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6B1A002D for ; Sun, 3 Jan 2016 11:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGqoV9V_6snE for ; Sun, 3 Jan 2016 11:12:32 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3A91A002C for ; Sun, 3 Jan 2016 11:12:31 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id e32so151113871qgf.3 for ; Sun, 03 Jan 2016 11:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b1bAbAOK4XUuLxUsAogCBdaWSI6WlGxebm+XO1s5aus=; b=WFWXPk22W4ZSYCbwHvNrn+aLYgW/mh2fWzgh1PS5ix0Q3MaDA39mEzzA4AQ2Jb+IHt vzueOgWgK3evwn5e3XpQUnDvo/lbs4DrdlK0hWg7w9523futANYTeRf5L25dyUi47mEc mJnfxUG8iGUrDtk9tlLShPD092vcn6VpY9YYhQoVRTTZht4eF6jmW/kVpVuzg0V/25Rv t8yNHOWZeH3jQ+tkTSZyAxIKOlO5wCl7ian097DcFIVy7BdXK1HGdw3SN+HaHzxKVRhJ E2/6TzYFfVT+khmT8wMqSMEQfza0L/69wFTJQu+NhCAhyEJ36B1XE3XDKTxkYmAtcGYe uVsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b1bAbAOK4XUuLxUsAogCBdaWSI6WlGxebm+XO1s5aus=; b=LOu6flZB7BX8vvk0fPVJJF+cpFDGDxCoFdJV2Mh2926pcjnLQ59k+48xwsYM56ubBD g3j1ecMKV/QpZ/LJTdPpiRFPuKU11q0gfKDuTSnWVLs5CDeQvCDm3qRTJsLNYDvAelb7 4tx5bVfouOGwPOdA1de4by2CBxIkx/mRPQ4FaCrRX6jytSDwTk0VahTvu/G0fZEhwW+8 OfXlrMD/ioYME/DXlRpzxJvRlt2vYUL4lp5yQ49e1ulW95PuqzlN7tv/ivbGNGj+jXjB Td9Cv45pipaah3VfKnEu07qtEe0xR73Wsthbz0Oe1qv8PlIrd8W2soEZo52BSQ9pK72f 2LEQ== X-Gm-Message-State: ALoCoQl2WqEa4A6Tg5rUmXRuloEoCALWJ7Wket1RqPs8Kp5hHZgGhDQyrUduOeKBuVvTyxznqf9NONPi5EUohs6fYmCjEAv2NQ== MIME-Version: 1.0 X-Received: by 10.140.153.73 with SMTP id 70mr118564287qhz.30.1451848350755; Sun, 03 Jan 2016 11:12:30 -0800 (PST) Received: by 10.55.145.65 with HTTP; Sun, 3 Jan 2016 11:12:30 -0800 (PST) In-Reply-To: <567EC179.8090709@ericsson.com> References: <20151221183426.14428.78357.idtracker@ietfa.amsl.com> <567EC179.8090709@ericsson.com> Date: Sun, 3 Jan 2016 20:12:30 +0100 Message-ID: From: Samuel Erdtman To: Mohit Sethi Content-Type: multipart/alternative; boundary=001a1139de4e370357052872c966 Archived-At: Cc: =?UTF-8?Q?G=C3=B6ran_Selander?= , Samuel Erdtman , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= , ace@ietf.org, Hannes Tschofenig , Ludwig Seitz Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 19:12:37 -0000 --001a1139de4e370357052872c966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mohit, Thanks for your detailed review. see comments inline. On Sat, Dec 26, 2015 at 5:34 PM, Mohit Sethi wrote: > Hi > > Here is my review of the OAuth draft. Comments are listed here > section-wise. > ---------------------------------------------------------------------- > > 1. Introduction > > - Managing authorization of users, services and their devices with the > help of dedicated authorization servers (AS) > - MS: Managing authorization of users, services and devices with ..... (i= t > was not clear who "their" refers to? Do the devices belong to the users o= r > the services?) > Samuel: I see your point, an interpretation could be that it is either or (user or service), depending on the situation, I think some of the other authors needs to pitch in here to share there understanding. > > - In its simplest form the authorization task can be described as grantin= g > access to a resource hosted on a device, the resource server (RS). > - MS: In its simplest form the authorization task can be described as > granting access to a requesting client, for a resource hosted on a device= , > the resource server (RS). > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > - We envision that end consumers and enterprises will want to manage thei= r > Internet of Things (IoT) devices in the same style and this desire will > increase with the number of exposed services and capabilities provided by > applications hosted on the IoT devices. > - MS: We envision that end consumers and enterprises will want to manage > access-control and authorization for their Internet of Things (IoT) devic= es > in the same style. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. - Also, I am not sure if I understand how this desire would increase the > services and capabilities provided by applications hosted on IoT devices. > Perhaps this could be elaborated. ?? > > Samuel: The formulation might be a bit fuzzy, my interpretation is the other way around as services and capabilities of applikations increases the desire to protect them will increase. How about changing the formulation of the second part of the sentence from "and this desire will increase with the number of exposed services and capabilities provided by applications hosted on the IoT devices" to ". As service and capabilities of IoT devices are increasing the desire to protect in the same way will increase"? > - constrained in various ways including processing, memory, code, energy, > etc., as > - MS: constrained in various ways including processing, memory, > code-size, energy, etc., as > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > - with different kinds of constrainedness > - MS: with different kinds of constraints > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > - for example to support lower the over-the-wire message size and smaller > code size > - MS: for example to support smaller over-the-wire message size and > smaller code size > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > > > 3.2 CoAP > > - Where HTTP uses headers and query-strings to convey additional > - MS: While HTTP uses headers and query-strings to convey additional > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > > 3.3 Object Security > - Whereas OSCOAP integrity protects specific CoAP message meta-data like > request/response code > - MS: While OSCOAP integrity protects specific CoAP message meta-data lik= e > request/response code > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > > > 4. Protocol Interactions > - For the description in this document we assume that the client has been > registered to an AS. Registration means that the two share credentials, > configuration parameters and that some form of authorization has taken > place. These credentials are used to protect the token request by the > client and the transport of access tokens and client information from AS = to > the client. > - MS: To me this fairly complex and needs to be described better. I > understand that this document may not standardize how the client discover= s > and registers to an AS, but there still needs to be some description on h= ow > this is done in practice. While currently a client can discover an RS > (resource-server) using a resource directory or DNS Service discovery, ho= w > does it find out which AS is responsible for the given RS. In the web-wor= ld > this works rather well with re-directs but I am not sure how this would > work in the scenarios described in the draft. I see a related issue on gi= t > as well: https://github.com/LudwigSeitz/ace-oauth/issues/22 > > Samuel: It is a good comment and as you have notised there is a registered issue related to the topic, I have added your comment and linked to this email > - The client may include permissions it seeks to obtain, and information > about the type of credentials it wants to use (i.e., symmetric or > asymmetric cryptography). > - MS: The client MAY include permissions it seeks to obtain, and > information about the type of credentials it wants. > - I also think that the text should probably say SHALL/SHOULD instead of > MAY. The client should include the permission it seeks. > Samuel: I think the reason for MAY is to really keep the amount of data to a minimum but keeping the possibility. In addition to key type, scope would be a natural thing to include. However I live with SHOULD, bet before we change it would be good if others could express there opinions on the topic. > > - Communication security between client and RS may be based on > pre-provisioned keys/security contexts or dynamically established to the = RS > via the PoP token; and to the client via the client information. > - MS: Communication security between client and RS may be based on > pre-provisioned keys/security contexts or dynamically established. The RS > authenticates the client via the PoP token; and the client authenticates > the RS via the client information. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > - which conveys authorization information to the RS that may be used for > subsequent resource requests, and > - MS: which conveys authorization information to the RS that may be used > by the client for subsequent resource requests, and > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > > > 5.1 Communication Security Protocol > - The client and the RS might not have any prior knowledge about each > other, therefore the AS needs to help them to establish a security contex= t > or at least a key. The AS does this by indicating communication security > protocol ("csp") and additional key parameters in the client information. > - MS: How does the client know about AS in the first place? Refers to my > previous comment on how can a client discover the AS? > Samuel: This is something we need to workout by resolving https://github.com/LudwigSeitz/ace-oauth/issues/22, it might be that it should be defined in this specification or in other. > > - configured more tightly with additional client information parameters, > like x5c, x5t or x5t#S256. > - MS: some explanation on how these parameters can be used would be > beneficial. Or a reference to where I can find more information. > Samuel: x5c, x5t or x5t#S256 are attributes form the JOSE (JWS, https://tools.ietf.org/html/rfc7515) specification defining a way to referee to certificates. I have added a reference to the them in the document. However it might be good to describe them further and the use in this context, it relates a bit to https://github.com/LudwigSeitz/ace-oauth/issues/25 > > - To use OSCOAP and OSCON requires security context to be established, > which can be provisioned with PoP token and client information > - MS: To use OSCOAP and OSCON requires security context to be established= , > which can be provisioned inside the PoP token and client information > Samuel: I=C2=B4m sure if this is an improvement, e.g. if the PoP token woul= d be a reference token and introspection used then the security context does not come inside the token but as a response to the introspection request. There is an issue registered regarding reference tokens https://github.com/LudwigSeitz/ace-oauth/issues/11 > > - token is larger than 255 bytes it should not be sent as a CoAP option > - MS: token is larger than 255 bytes it SHALL NOT be sent as a CoAP optio= n > Samuel: I lack in my CoAP knowledge, is there a CoAP limit of 255 then SHALL NOT would be preferable but if it is not it might be preferable to use SHOUL NOT to have a bit of flexibility. > > > 6.1 Client and Resource Server are Offline > > - A: The client first generates a public-private key pair used for > communication security with the RS. > - MS: Does the client generate a new key pair for every RS. Can they be > re-used across RS? I assume key generation can be expensive for some > devices? > Samuel: In general I would say that the client can use the same key pair with multiple RSes, but should know the security and privacy implications. e.g. privacy wise it would be possible for RSes to track the Client in a way that is not desirable and security wise the key would need to rotate more often. I have added an issue to add text regarding this. https://github.com/LudwigSeitz/ace-oauth/issues/26 > > - a value the that the temperature sensor identifies itself with. > - MS: a value that the temperature sensor identifies itself with. > Samuel: Good catch > - The client sends the POST request to /token at AS. The request contain= s > the public key of the client and the Audience parameter set to > "tempSensorInLivingRoom". > - MS: There is no public-key in the request payload of Figure 3? Also som= e > explanation of 'client_id' and 'client_secret' would be useful. I checked > the appendix and didn't find enough information on what is the role of > client_secret? > Samuel: the reason for not having a key in the request could be that the key is symmetric and, but that could be clearer. This relates to the CSP (communication security protocol) that might need to be more specific e.g. DTLS-PreSharedKey or DTLS-RawPublicKey. Some of this is somewhat covered by https://github.com/LudwigSeitz/ace-oauth/issues/4 For 'client_id' and 'client_secret' I don=C2=B4t know if it should be expla= ined here (in this document) or refereed to the OAuth2 description, opinions? > > - MS: Perhaps the role of iat attribute in figure 5 could be explained in > text. > And/or referensed to the description under JOSE, opinions? > > > 6.2 Resource Server Offline > > - The following example shows interactions between a client (AC control > unit > - MS: AC (access-control) control unit can be confusing. Don't use the > acronym. Instead use air-conditioning control unit. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > - The client then sends the PoP token to the /authz-info resource in the > RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between client and > RS, since the token is integrity protected between AS and RS. > - MS: Shouldn't the token also be encrypted? If not, any one on the path > can see the symmetric-key and act on behalf of the real client. > Samuel: The symmetric key in the token would always be encrypted with the key of the audience (RS) if I understand the OAuth2 PoP architecture correct https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 > > > > 6.3 Token Introspection with an Offline client > > - and thus defers to respond the client with a status code until step E > and only acknowledges on the CoAP message layer indicated with a dashed > line). > - MS: Which status code is this? Is it an HTTP status code? CoAP response > code? > Samuel: I=C2=B4m not sure I would like to have something like HTTP 202 Acce= pted but I cannot find such code for CoAP closes thing I find is 2.01 Created. Suggestions? > > > > Appendix A: > - which has an impact of choice of message format and protocol. > - MS: which has an impact on the choice of message format and protocol. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > - protocols contribute to the communication overhead and can in some case= s > can be optimized. > - MS: protocols contribute to the communication overhead and can in some > cases be optimized. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > > > Appendix B: > - In case of introspection it may be useful with access tokens which are > not self-contained. > - MS: In case of introspection, it may be beneficial to utilize access > tokens which are not self-contained. > Samuel: I thinks your proposal is an improvement and has updated the working copy with it. > - Also worth mentioning that this allows for more dynamic revocation. > Samuel: Introspection can be done on self contained tokens too, i.e. checking revocation state of a token. > > > > General comments: > - MS: I like the fact that there can be different deployment scenarios > that can be supported with this architecture. But I am wondering if this > can actual lead to unknown security vulnerabilities? When should a AS giv= e > short-lived access tokens and when should they be long-lived. Can't a > client always pretend that it will be offline and ask for long-lived > tokens. How does the AS check whether a client is really > resource-constrained or not? How can a user configure in the AS who can g= et > short-lived tokens and who can get long-lived tokens? > Samuel: When registering the client dynamically or as a precondition It could be configured what kind of token the client are allowed to request, in the same way as which scopes it can get authorization for. > > - MS: How are the cipher suites negotiated. What happens when the > constrained-client and constrained-RS don't speak the same elliptic curve > parameters? I see there is a related git issue: > https://github.com/LudwigSeitz/ace-oauth/issues/21. Samuel: As you mentioned the issue addresses som of this, then since both client and RS have a relation to AS I think AS should issue tokens and keys that are compatible. This view of things in combination with the referred issue could solve this as I see it. > > > > /--Mohit > > > > > On 12/21/2015 08:34 PM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Authentication and Authorization for >> Constrained Environments Working Group of the IETF. >> >> Title : Authorization for the Internet of Things usin= g >> OAuth 2.0 >> Authors : Ludwig Seitz >> Goeran Selander >> Erik Wahlstroem >> Samuel Erdtman >> Hannes Tschofenig >> Filename : draft-ietf-ace-oauth-authz-00.txt >> Pages : 43 >> Date : 2015-12-21 >> >> Abstract: >> This memo defines how to use OAuth 2.0 as an authorization framework >> with Internet of Things (IoT) deployments, thus bringing a well-know= n >> and widely used security solution to IoT devices. Where possible >> vanilla OAuth 2.0 is used, but where the limitations of IoT devices >> require it, profiles and extensions are provided. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1139de4e370357052872c966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Mohit,

Thanks for yo= ur detailed review. see comments inline.



On Sat, Dec 26, 2015 at 5:3= 4 PM, Mohit Sethi <mohit.m.sethi@ericsson.com> wrot= e:
Hi

Here is my review of the OAuth draft. Comments are listed here section-wise= .
----------------------------------------------------------------------

1. Introduction

- Managing authorization of users, services and their devices with the help= of dedicated authorization servers (AS)
- MS: Managing authorization of users, services and devices with ..... (it = was not clear who "their" refers to? Do the devices belong to the= users or the services?)

Samuel: I see = your point, an interpretation could be that it is either or (user or servic= e), depending on the situation, I think some of the other authors needs to = pitch in here to share there understanding.

=C2=A0=

- In its simplest form the authorization task can be described as granting = access to a resource hosted on a device, the resource server (RS).
- MS: In its simplest form the authorization task can be described as grant= ing access to a requesting client, for a resource hosted on a device, the r= esource server (RS).

Samuel: I thinks y= our proposal is an improvement and has updated the working copy with it.
=C2=A0

- We envision that end consumers and enterprises will want to manage their = Internet of Things (IoT) devices in the same style and this desire will inc= rease with the number of exposed services and capabilities provided by appl= ications hosted on the IoT devices.
- MS: We envision that end consumers and enterprises will want to manage ac= cess-control and authorization for their Internet of Things (IoT) devices i= n the same style.

Samuel: I thinks your= proposal is an improvement and has updated the working copy with it.
=

- Also, I am not sure if I understand how this desire would increase the se= rvices and capabilities provided by applications hosted on IoT devices. Per= haps this could be elaborated. ??


Samuel: The formulation might be a bit= fuzzy, my interpretation is the other way around as services and capabilit= ies of applikations increases the desire to protect them will increase.
How about changing the formulation of the second part of the sentenc= e from "and this desire will increase with the number of exposed servi= ces and capabilities provided by applications hosted on the IoT devices&quo= t; to ". As service and capabilities =C2=A0of IoT devices are increasi= ng the desire to protect in the same way will increase"?


- constrained in various ways including processing, memory, code, energy, e= tc., as
- MS:=C2=A0 constrained in various ways including processing, memory, code-= size, energy, etc., as

Samuel: I thinks= your proposal is an improvement and has updated the working copy with it.= =C2=A0

- with different kinds of constrainedness
- MS: with different kinds of constraints

Samuel: I thinks your proposal is an improvement and has updated the wor= king copy with it.=C2=A0
=C2=A0

- for example to support lower the over-the-wire message size and smaller c= ode size
- MS: for example to support smaller over-the-wire message size and smaller= code size

Samuel: I thinks your propos= al is an improvement and has updated the working copy with it.=C2=A0
<= div>=C2=A0



3.2 CoAP

- Where HTTP uses headers and query-strings to convey additional
- MS: While HTTP uses headers and query-strings to convey additional

Samuel: I thinks your proposal is an improvem= ent and has updated the working copy with it.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

3.3 Object Security
- Whereas OSCOAP integrity protects specific CoAP message meta-data like re= quest/response code
- MS: While OSCOAP integrity protects specific CoAP message meta-data like = request/response code

Samuel: I thinks = your proposal is an improvement and has updated the working copy with it.= =C2=A0
=C2=A0



4. Protocol Interactions
- For the description in this document we assume that the client has been r= egistered to an AS.=C2=A0 Registration means that the two share credentials= , configuration parameters and that some form of authorization has taken pl= ace.=C2=A0 These credentials are used to protect the token request by the c= lient and the transport of access tokens and client information from AS to = the client.
- MS: To me this fairly complex and needs to be described better. I underst= and that this document may not standardize how the client discovers and reg= isters to an AS, but there still needs to be some description on how this i= s done in practice. While currently a client can discover an RS (resource-s= erver) using a resource directory or DNS Service discovery, how does it fin= d out which AS is responsible for the given RS. In the web-world this works= rather well with re-directs but I am not sure how this would work in the s= cenarios described in the draft. I see a related issue on git as well: https://github.com/LudwigSeitz/ace-oauth/issues/22=


Samuel: It is a good comment and as yo= u have notised there is a registered issue related to the topic, I have add= ed your comment and linked to this email

=C2=A0
-=C2=A0 The client may include permissions it seeks to obtain, and informat= ion about the type of credentials it wants to use (i.e., symmetric or asymm= etric cryptography).
- MS: The client MAY include permissions it seeks to obtain, and informatio= n about the type of credentials it wants.
- I also think that the text should probably say SHALL/SHOULD instead of MA= Y. The client should include the permission it seeks.
=
Samuel: I think the reason for MAY is to really keep the amo= unt of data to a minimum but keeping the possibility. In addition to key ty= pe, scope would be a natural thing to include. However I live with SHOULD, = bet before we change it would be good if others could express there opinion= s on the topic.=C2=A0
=C2=A0

- Communication security between client and RS may be based on pre-provisio= ned keys/security contexts or dynamically established to the RS via the PoP= token; and to the client via the client information.
- MS: Communication security between client and RS may be based on pre-prov= isioned keys/security contexts or dynamically established. The RS authentic= ates the client via the PoP token; and the client authenticates the RS via = the client information.

=C2=A0Samuel: I= thinks your proposal is an improvement and has updated the working copy wi= th it.=C2=A0


- which conveys authorization information to the RS that may be used for su= bsequent resource requests, and
- MS: which conveys authorization information to the RS that may be used by= the client for subsequent resource requests, and

=
=C2=A0Samuel: I thinks your proposal is an improvement and has u= pdated the working copy with it.=C2=A0
=C2=A0



5.1 Communication Security Protocol
-=C2=A0 The client and the RS might not have any prior knowledge about each= other, therefore the AS needs to help them to establish a security context= or at least a key.=C2=A0 The AS does this by indicating communication secu= rity protocol ("csp") and additional key parameters in the client= information.
- MS: How does the client know about AS in the first place? Refers to my pr= evious comment on how can a client discover the AS?
Samuel: This is something we need to workout by resolving=C2= =A0https://github.com/LudwigSeitz/ace-oauth/issues= /22, it might be that it should be defined in this specification or in = other.
=C2=A0

- configured more tightly with additional client information parameters, li= ke x5c, x5t or x5t#S256.
- MS: some explanation on how these parameters can be used would be benefic= ial. Or a reference to where I can find more information.
<= div>
Samuel: x5c, x5t or x5t#S256 are attributes form the JOS= E (JWS, https://tools.ietf.= org/html/rfc7515) specification defining a way to referee to certificat= es. I have added a reference to the them in the document. However it might = be good to describe them further and the use in this context, it relates a = bit to=C2=A0= https://github.com/LudwigSeitz/ace-oauth/issues/25
=C2=A0

- To use OSCOAP and OSCON requires security context to be established, whic= h can be provisioned with PoP token and client information
- MS: To use OSCOAP and OSCON requires security context to be established, = which can be provisioned inside the PoP token and client information

Samuel: I=C2=B4m sure if this is an improveme= nt, e.g. if the PoP token would be a reference token and introspection used= then the security context does not come inside the token but as a response= to the introspection request. There is an issue registered regarding refer= ence tokens=C2=A0https://github.com/LudwigSeitz/ace-oauth/issues/11
=C2= =A0

- token is larger than 255 bytes it should not be sent as a CoAP option
- MS: token is larger than 255 bytes it SHALL NOT be sent as a CoAP option<= br>

=C2=A0Samuel: I lack in my CoAP knowled= ge, is there a CoAP limit of 255 then SHALL NOT would be preferable but if = it is not it might be preferable to use SHOUL NOT to have a bit of flexibil= ity.=C2=A0




6.1 Client and Resource Server are Offline

- A: The client first generates a public-private key pair used for communic= ation security with the RS.
- MS: Does the client generate a new key pair for every RS. Can they be re-= used across RS? I assume key generation can be expensive for some devices?<= br>

Samuel: In general I would say that the= client can use the same key pair with multiple RSes, but should know the s= ecurity and privacy implications. e.g.=C2=A0privacy=C2=A0wise it would be p= ossible for RSes to track the Client in a way that is not desirable=C2=A0an= d security wise the key would need to rotate more often. I have added an is= sue to add text regarding this.=C2=A0https://github.com/LudwigSeitz/ace-oauth/issues/26=

=C2=A0

- a value the that the temperature sensor identifies itself with.
- MS: a value that the temperature sensor identifies itself with.

Samuel: Good catch


- The client sends the POST request to /token at AS.=C2=A0 The request cont= ains the public key of the client and the Audience parameter set to "t= empSensorInLivingRoom".
- MS: There is no public-key in the request payload of Figure 3? Also some = explanation of 'client_id' and 'client_secret' would be use= ful. I checked the appendix and didn't find enough information on what = is the role of client_secret?

Samuel: t= he reason for not having a key in the request could be that the key is symm= etric and, but that could be clearer. This relates to the CSP (communicatio= n security protocol) that might need to be more specific e.g. DTLS-PreShare= dKey or DTLS-RawPublicKey. Some of this is somewhat covered by=C2=A0https://github.com/L= udwigSeitz/ace-oauth/issues/4
For=C2=A0'client_id' an= d 'client_secret' I don=C2=B4t know if it should be explained here = (in this document) or refereed to the OAuth2 description, opinions?
=C2=A0

- MS: Perhaps the role of iat attribute in figure 5 could be explained in t= ext.

And/or referensed to the descripti= on under JOSE, opinions?
=C2=A0


6.2 Resource Server Offline

- The following example shows interactions between a client (AC control uni= t
- MS: AC (access-control) control unit can be confusing. Don't use the = acronym. Instead use air-conditioning control unit.
Samuel: I thinks your proposal is an improvement and has updat= ed the working copy with it.=C2=A0
=C2=A0

- The client then sends the PoP token to the /authz-info resource in the RS= .=C2=A0 This is a plain CoAP request, i.e. no DTLS/OSCOAP between client an= d RS, since the token is integrity protected between AS and RS.
- MS: Shouldn't the token also be encrypted? If not, any one on the pat= h can see the symmetric-key and act on behalf of the real client.

Samuel: The symmetric key in the token would alw= ays be encrypted with the key of the audience (RS) if I understand the OAut= h2 PoP architecture correct=C2=A0https://tools.ietf.org/html/draft-ietf-o= auth-pop-architecture-07
=C2=A0



6.3 Token Introspection with an Offline client

- and thus defers to respond the client with a status code until step E and= only acknowledges on the CoAP message layer=C2=A0 indicated with a dashed = line).
- MS: Which status code is this? Is it an HTTP status code? CoAP response c= ode?

Samuel: I=C2=B4m not sure I would = like to have something like HTTP 202 Accepted but I cannot find such code f= or CoAP closes thing I find is 2.01 Created. Suggestions?
=C2=A0<= /div>



Appendix A:
- which has an impact of choice of message format and protocol.
- MS:=C2=A0 which has an impact on the choice of message format and protoco= l.

Samuel: I thinks your proposal is an= improvement and has updated the working copy with it.=C2=A0
=C2= =A0

- protocols contribute to the communication overhead and can in some cases = can be optimized.
- MS: protocols contribute to the communication overhead and can in some ca= ses be optimized.

Samuel: I thinks your= proposal is an improvement and has updated the working copy with it.=C2=A0=
=C2=A0


Appendix B:
- In case of introspection it may be useful with access tokens which are no= t self-contained.
- MS: In case of introspection, it may be beneficial to utilize access toke= ns which are not self-contained.

Samuel= : I thinks your proposal is an improvement and has updated the working copy= with it.
=C2=A0
- Also worth mentioning that this allows for more dynamic revocation.

Samuel: Introspection can be done on self co= ntained tokens too, i.e. checking revocation state of a token.
= =C2=A0



General comments:
- MS: I like the fact that there can be different deployment scenarios that= can be supported with this architecture. But I am wondering if this can ac= tual lead to unknown security vulnerabilities? When should a AS give short-= lived access tokens and when should they be long-lived. Can't a client = always pretend that it will be offline and ask for long-lived tokens. How d= oes the AS check whether a client is really resource-constrained or not? Ho= w can a user configure in the AS who can get short-lived tokens and who can= get long-lived tokens?

Samuel: When re= gistering the client dynamically or as a precondition It could be configure= d what kind of token the client are allowed to request, in the same way as = which scopes it can get authorization for.
=C2=A0

- MS: How are the cipher suites negotiated. What happens when the constrain= ed-client and constrained-RS don't speak the same elliptic curve parame= ters? I see there is a related git issue: https://= github.com/LudwigSeitz/ace-oauth/issues/21.

=
Samuel: As you mentioned the issue addresses som of this, then since b= oth client and RS have a relation to AS I think AS should issue tokens and = keys that are compatible. This view of things in combination with the refer= red issue could solve this as I see it.
=C2=A0



/--Mohit




On 12/21/2015 08:34 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0 This draft is a work item of the Authentication and Authorization fo= r Constrained Environments Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Authorization for the Internet of Things using OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Ludwig Seitz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Goeran Selander
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Erik Wahlstroem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Samuel Erdtman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ace-oauth-authz-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-12-21

Abstract:
=C2=A0 =C2=A0 This memo defines how to use OAuth 2.0 as an authorization fr= amework
=C2=A0 =C2=A0 with Internet of Things (IoT) deployments, thus bringing a we= ll-known
=C2=A0 =C2=A0 and widely used security solution to IoT devices.=C2=A0 Where= possible
=C2=A0 =C2=A0 vanilla OAuth 2.0 is used, but where the limitations of IoT d= evices
=C2=A0 =C2=A0 require it, profiles and extensions are provided.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-ace-oauth-authz/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ac= e-oauth-authz-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a1139de4e370357052872c966-- From nobody Sun Jan 3 13:04:12 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC61A01FA for ; Sun, 3 Jan 2016 13:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mT89En0aj3k for ; Sun, 3 Jan 2016 13:04:09 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBC41A01EC for ; Sun, 3 Jan 2016 13:04:07 -0800 (PST) Received: from NG-EX03.ad.nexusgroup.com (10.75.28.103) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 3 Jan 2016 22:04:49 +0100 Received: from NG-EX02.ad.nexusgroup.com (10.75.28.43) by NG-EX03.ad.nexusgroup.com (10.75.28.103) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 3 Jan 2016 22:04:44 +0100 Received: from NG-EX02.ad.nexusgroup.com ([fe80::a98c:2117:1e11:3a3a]) by NG-Ex02.ad.nexusgroup.com ([fe80::a98c:2117:1e11:3a3a%12]) with mapi id 15.00.0995.028; Sun, 3 Jan 2016 22:04:47 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Michael Richardson Thread-Topic: [Ace] CBOR Web Token (CWT) spec for the ACE working group Thread-Index: AdEvDD/qhV0xKgF3TQ+OV37TSTGCSw== Date: Sun, 3 Jan 2016 21:04:47 +0000 Message-ID: <7B5F6CDD-51C6-4C86-B7AB-6CA77981296D@nexusgroup.com> References: <5684531C.1090608@sandelman.ca> In-Reply-To: <5684531C.1090608@sandelman.ca> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <23BC8C9854F33D498E4D9BAC4328F1B3@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] CBOR Web Token (CWT) spec for the ACE working group X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 21:04:11 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJdCdzIHZlcnkgbXVjaCBhcHByZWNpYXRlZC4NCg0KU2Vl IGNvbW1lbnRzIGJlbG93Lg0KDQo+PiBPbiAzMCBEZWMgMjAxNSwgYXQgMjI6NTcsIE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+IA0KPj4gT24gMTIv MDQvMTUgMjI6NDYsIE1pa2UgSm9uZXMgd3JvdGU6DQo+PiBBZnRlciBpbnB1dCBmcm9tIG1hbnkg aW50ZXJlc3RlZCBwZW9wbGUsIElFVEYgU2VjdXJpdHkgQXJlYSBEaXJlY3Rvcg0KPj4gS2F0aGxl ZW4gTW9yaWFydHkgZGVjaWRlZA0KPj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9jb3NlL2N1cnJlbnQvbXNnMDA4MTAuaHRtbD4gdGhhdA0KPj4gdGhlIHJpZ2h0IHBsYWNl IGZvciB0aGUgQ0JPUiBXZWIgVG9rZW4gKENXVCkgd29yayBpcyB0aGUgQUNFIHdvcmtpbmcNCj4+ IGdyb3VwIDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvYWNlL2NoYXJ0ZXIvPi4gIFRv ZGF5IEVyaWsNCj4+IFdhaGxzdHLDtm0gcG9zdGVkIGEgbmV3IGRyYWZ0IG9mIHRoZSBDQk9SIFdl YiBUb2tlbiAoQ1dUKSBzcGVjaWZpY2F0aW9uDQo+PiB0aGF0IGlzIGludGVuZGVkIGZvciBBQ0Uu DQo+IA0KPiBUaGFuayB5b3UuIEkgcmVhZCB0aGUgZG9jdW1lbnQgdG9kYXkuICBJIGhhZG4ndCBy ZWFkIGl0IGJlZm9yZS4NCj4gVGhlIGFwcGVuZGl4IGlzIGFwcHJlY2lhdGVkLCB0aGUgbGFjayBv ZiByZXBldGl0aW9uIHdpbGwgbWFrZSBiZSBnbyBhbmQNCj4gZGlnIGludG8gcmVmZXJlbmNlcywg YnV0IHRoYXQncyBva2F5Lg0KPiANCj4gSSB3b25kZXIgaWYgdGhlIHJlc3VsdCBhZnRlciAiVGhp cyBpcyB0aGVuIHBhY2thZ2VkIHNpZ25lZCBhbmQgZW5jcnlwdGVkDQo+IHVzaW5nIENPU0UiIGNv dWxkIGFsc28gYmUgYWRkZWQgdG8gdGhlIGFwcGVuZGl4Pw0KDQpZZXMuIEkgYWxzbyB0aGluayBp dCBzaG91bGQgYmUgYWRkZWQuDQoNCg0KPiANCj4gaW4gZmlndXJlIDcsIEkgZG9uJ3QgdGhpbmsg aXQncyB1c2VmdWwgdG8gc2hvdyB0aGUgXHggZXhwYW5zaW9uIG9mDQo+IHdoYXQgaXMgZXNzZW50 aWFsbHkgYSBiaW5hcnkgdmFsdWU6DQo+IA0KPiBiYWM1YjExY2FkOGY5OWY5YzcyYjA1Y2Y0Yjll MjZkMjQ0ZGMxODlmNzQ1MjI4MjU1YTIxOWE4NmQ2YTA5ZWZmICMNCj4gIlx4QkFceEM1XHhCMVx4 MUNceEFEXHg4Rlx4OTlceEY5XHhDNytceDA1XHhDRktceDlFJlx4RDJEXHhEQ1x4MThceDlGdFIo JVohXHg5QVx4ODZceEQ2XHhBMFx4OUVceEZGIg0KPiANCj4gKGFuZCBpdCBydWlucyB0aGUgZm9y bWF0dGluZy4uLikNCj4gUGVyaGFwcyB0aGlzIGlzIGF1dG9tYXRpY2FsbHkgZG9uZSBieSBhIHRv b2wuDQoNCldlIGNvdWxkIHByb2JhYmx5IGFkZCBhIHRleHQgc2F5aW5nIGl0cyB0cnVuY2F0ZWQg Zm9yIHJlYWRhYmlsaXR5LiANCg0KQWRkZWQgYm90aCB0byBhIGlzc3VlIHRyYWNrZXIuDQoNCi8g RXJpaw0KDQoNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBBY2UgbWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K From nobody Mon Jan 4 10:58:08 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B01A6F62 for ; Mon, 4 Jan 2016 10:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kTzhG_NO5wo for ; Mon, 4 Jan 2016 10:58:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C201A6F8A for ; Mon, 4 Jan 2016 10:58:01 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.18]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M4WuC-1a1gqJ2mXk-00yl94 for ; Mon, 04 Jan 2016 19:57:59 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <568AC0B6.6030104@gmx.net> Date: Mon, 4 Jan 2016 19:57:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JkiVGhxpkn4jUm3Je3RMaQlXNPxfflH4Q" X-Provags-ID: V03:K0:wP7pl7hDwV5/VPi+j5Q+HIDwsVoblzqkSEHztznYUzTIcD6RPp5 xksXrTigZ3gvBFsnq8V5Sl4T+2mWQ7fwRikAvSXviYvqveomYuaWTT6OVkBefWYhz3D/pjW Tbsau73PPqZ5piMXatQQwmnXlJraHUTc7JGsjqVwtZTQ3kRvT4veEsf3xuZFmcBscBQrhJw 3B+oLA/RNXtvpeJrjR7Uw== X-UI-Out-Filterresults: notjunk:1;V01:K0:i7CLSWC5nco=:o22fU7AS6Ffan0Iw5T+ihn jfR4UwKGWoEoTMOz393A/OopDflIERy1M+pHCD4fXLDoyf/5K069gOumFa6h7GuFNFn45Gpe/ vJQcB7OG930ev/Y90aGd8jHf9fGyCDiVpYevmbAt9tx1u9CuK3BHx95CzXiMGX1TiOoucjUl7 ihKM++uHusX7i0BgxXWiG+4q7m+OctrwtR8lmqZrtaebZgQ74c6bN/rN1+gccNyb2kWI4ZY+c A6Cqfqd/nkYuCYcVGFeTugt4Pw33BuvGfvDAlK2bG6vC8aX9d5VC7A9V6639VuUm2K6g1++PQ xpOG/MqlkgRsevwkhxTe9Zx8YlegD5wbOW0i7WicYxLwUjSZlul7y4fPwu+ZFeKp6pJ2Ji1n5 P3sVnGimUSvxnSIOLOXSPZsc5ry5w3MYzjDsJ9MlNfEbyXPFhpy6wj+NxZP6SNDHb4TXQKGXv 3DKsMIlW7UAmykz1f4BYIUhGz0qxtrUkHdte9XkgGv+4l4F1PO/xk/s2QKT4FXlhU2m1KgOQL Al9/H+5ux6TAJY+5nYHABtmXAX6SWkAup4nDGrZkQCnkBsClCx9WqkWCpUTaAlTMbvJbyEb9q qjAM2pfcHxU203aV5w4n42Fv27nsy+8WAR9Xx87frr5FUTR5MhffZqkzG9Z6xC/4PYGcdgdDM S9fcDTgXUUqwq7/KLCb62tBqzjrOg3Piod71h/oVXDIiHTtb71M2KbQ5Q1OCF/XGuUJt1H/bL DXPwfA/dTxR0Ty1v+PM68UGDV2c/RAaiq0PjWRbMFUU/hND/uGbz279mDCU= Archived-At: Subject: [Ace] IoT Semantic Interoperability Workshop 2016 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:58:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JkiVGhxpkn4jUm3Je3RMaQlXNPxfflH4Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Happy New Year to everyone in the ACE working group. Because of the vacation period around Christmas you may have missed that the IAB is organizing a workshop on "IoT Semantic Interoperability" in March 2016. All the details can be found at this webpage: https://www.iab.org/activities/workshops/iotsi/ In a nutshell, with this workshop the IAB reaches out to folks who are interested in interoperability at the application layer (and with information and data models in particular). A couple of questions are listed on the webpage. Take a look at it and see whether you have something to contribute to the discussion. Ciao Hannes --JkiVGhxpkn4jUm3Je3RMaQlXNPxfflH4Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWisC2AAoJEGhJURNOOiAtry4H/jUs5kt79faS2nIJcgyF88aJ 8fgFEZXfyKzDYEj8bIK70LF0R0Lk/XI3obUglu0PYDSpj+m4qTfagVFZC7raPjvr 485WRAOQDrFa5gJY2m1fLQVegXdmH40MTVUO3bF+mO+bvV/nSeXcyJu5waOpcvml JIJTfoVUn8zfD54+kEV9QbNiwPhwNpcZzPRXbA8mqEPw9IvyWoh9KwMFta567DYQ PpLM52X71Sasuw027Ujn8th00sgY8skA5x8dHt8kGnwfrxpJz9DKtp/o2+8WZ3Qw nN1EY13wdUivmzqL2A3+jzPx9fxRD0a1E/FxhsMXkzZRdjPWCA0YGCBkFleFiSo= =hVtd -----END PGP SIGNATURE----- --JkiVGhxpkn4jUm3Je3RMaQlXNPxfflH4Q-- From nobody Mon Jan 4 13:31:37 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A661AC3C3; Mon, 4 Jan 2016 13:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd9WCaxRdrSd; Mon, 4 Jan 2016 13:31:26 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8EA1AC3B9; Mon, 4 Jan 2016 13:31:20 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id F21242CA1D; Mon, 4 Jan 2016 13:31:19 -0800 (PST) From: "Jim Schaad" To: Date: Mon, 4 Jan 2016 13:28:34 -0800 Message-ID: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdFHNZjhDG9OzhqoSgyS7pmJRsqwXw== Content-Language: en-us Archived-At: Cc: Ace@ietf.org Subject: [Ace] Should we support padding for Enveloped/Encrypted Messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:31:30 -0000 Padding of content is useful for dealing with traffic analysis attacks. This can be seen as becoming important as it is now part of the basic framework of TLS 1.3. One possible simple analysis that can be performed against sensors is looking for thresholds in reported values. Just looking at the message length, one can tell the difference between '9.0' and '10.0' unless the first item is padded out to the same length. For example using either '09.0' or ' 9.0'. We currently do not have any facility to do a generic padding and it is not clear that we should provide one. The benefit is that it would allow for the ability to reduce the set of traffic analysis attacks. The down side is that we probably need to have some type of length field added to encrypted content for all messages. This means that we potentially have a single byte (or more depending on how it is done) to all messages increasing the length. It is also not clear yet how much the IoT world cares about doing the type of protection in the near term. (It is possible that in time they may start caring.) One possible answer is to add the padding to the end of the current message ala the PKCS#7 padding. There would be N bytes appended to the end of the message, each containing the value of N. The default would be to append a single byte with the value of '1'. The use of padding would be described as being application specific rather than being generic. However the single byte would always need to be paid even if there was not padding done. At this time my inclination is to treat this as a problem that the application should be solving and to simply address it as a security consideration in the COSE message draft. Any comments? I would like to resolve this by the end of this week. Jim From nobody Mon Jan 4 14:08:38 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC41AC40F; Mon, 4 Jan 2016 14:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e6W-QI2eguS; Mon, 4 Jan 2016 14:08:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6A61AC408; Mon, 4 Jan 2016 14:08:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19755BE53; Mon, 4 Jan 2016 22:08:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl_A2bw86q9D; Mon, 4 Jan 2016 22:08:31 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.23.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 00E2EBE4D; Mon, 4 Jan 2016 22:08:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1451945311; bh=9BNp7ZA4d/GBoBlUEAFPvTzirHI4s56X1rtZrPm3TLY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gPuQARudDs0Ep3+vhT1atZ6QSPtXP6U0o2jEK0+dwU3vyduEIrA15vdjnXybaXuOx KGfVnk/8uFrp2l01+vpN93DX2ulYnd0ZfMdqJySZ8N6MzC/iTSVvjFkPrS5XeoCc6q /CxmahsH8mR2dhBiy6ktYk5uMuzxX5D0511kqxOE= To: Jim Schaad , cose@ietf.org References: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <568AED5E.7000408@cs.tcd.ie> Date: Mon, 4 Jan 2016 22:08:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted Messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:08:36 -0000 I would argue to try define a padding mechanism here. As you note, it may be important later and there are some real issues when dealing with constrained use-cases. In fact, in the limit one might want to define a padding-only form for COSE to handle the case where the existence of any traffic defeats any confidentiality protection. (E.g. sensor that fires a packet when temp==20C.) I know that that'd not often be useful but I think there will be times when it will. The argument that applications can best do this is not a bad one, but can be countered. If a node has a common crypto library that ensures that padding can be done consistently across multiple applications, which could be harder if not defined at this layer. (And even more likely, application developers don't care or don't bother or don't know how to do this well.) Cheers, S. PS: FWIW, I'd make the same argument for any protocol - I think we need to define basic padding mechanisms whenever we can now so that we or others can learn how to best use those later. On 04/01/16 21:28, Jim Schaad wrote: > Padding of content is useful for dealing with traffic analysis attacks. This > can be seen as becoming important as it is now part of the basic framework > of TLS 1.3. One possible simple analysis that can be performed against > sensors is looking for thresholds in reported values. Just looking at the > message length, one can tell the difference between '9.0' and '10.0' unless > the first item is padded out to the same length. For example using either > '09.0' or ' 9.0'. > > We currently do not have any facility to do a generic padding and it is not > clear that we should provide one. The benefit is that it would allow for the > ability to reduce the set of traffic analysis attacks. The down side is that > we probably need to have some type of length field added to encrypted > content for all messages. This means that we potentially have a single byte > (or more depending on how it is done) to all messages increasing the length. > It is also not clear yet how much the IoT world cares about doing the type > of protection in the near term. (It is possible that in time they may start > caring.) > > One possible answer is to add the padding to the end of the current message > ala the PKCS#7 padding. There would be N bytes appended to the end of the > message, each containing the value of N. The default would be to append a > single byte with the value of '1'. > > The use of padding would be described as being application specific rather > than being generic. However the single byte would always need to be paid > even if there was not padding done. > > At this time my inclination is to treat this as a problem that the > application should be solving and to simply address it as a security > consideration in the COSE message draft. > > Any comments? I would like to resolve this by the end of this week. > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Wed Jan 13 01:28:43 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169F81ACD09 for ; Wed, 13 Jan 2016 01:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvY3oynYBKlI for ; Wed, 13 Jan 2016 01:28:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D76A1ACD22 for ; Wed, 13 Jan 2016 01:28:37 -0800 (PST) Received: from [192.168.10.141] ([83.65.147.98]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M0cs6-1a2RIo0Rp8-00usQ7 for ; Wed, 13 Jan 2016 10:28:36 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <569618C9.50904@gmx.net> Date: Wed, 13 Jan 2016 10:28:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pv3fF3uAfeVdSmWUK6urwvEGUPUiMW1eW" X-Provags-ID: V03:K0:QeaDBIg85MtFzMYrn7mNkuSyWCKLD6s/Bb+ls7KlAuwzdUjU60k qW0V/eOatEeLfRZRTnuEYzLM1EyGqcpHbSy577ifsiClkOHG0U6MtiBvyyTL7yoNpoVAMyV A+pT8pgPKerT5WkG90uk3qLedC/b4XJ3Q+6R7SYbqzaD1uSql2wrvbLtsQ1U7j+wCqCEUP5 4RRfgwYT4X1wX1AOcvQow== X-UI-Out-Filterresults: notjunk:1;V01:K0:j5JhOtUkZZw=:POp1DZzqH5VXKadh32LIR7 9pGb7KDmrAALJD0FloYS7tCsvCuxfCL9HjEzVZ63NGp7vUspwnbgiJlAs2yTCCYAUSscCVVNm xKHwCsNeeOuJbNOXjimd2XdaLhOf455HddvTiNvEOEkX82PV2e/KEQWBRoixWsVPnVEF3K2l/ USUrodTx4gSvMC2fdxdhpv7Se1Dim57tWt43fuvSZ+po9+gPuGAYm8BWYUZ1BzM/hyLFmBW3t XLT+rP3MoS1mAzjjUR7Cz7i7kZTL06ZWT1cfEtIcqLuBzBjI75w9A08VQ3Pg5v3NBc2tQ+kLz +Ea6Y4tbMmPUKN+Eygpr58v2RDRDcFDsYTYyNYn+jiOm4vFy7x84oEMY3/S2aG3Woivq2lgHZ kih5Td4t1DhtNiKzGaxwBAz6omtVTNWbnjm+TtMEZRpM4pN/fTBFP3KeN5kkgNahXOkxb9yq0 EWB5BI8JtnWFeouepCTsa5tYVado1C42uhQnzWnSdoLvTFO6uOWIq/J0nIFOJ/Zhsb7jQV+dZ Ds0KQfLJWZ1iz/I7rjJngCRc+nSPE/Y3DxyjHG8u4PoaTBS09FcKV5M21dBPqOnMTZFEsf3nF mtJzSsGl+xIKkH71i51++drf0ogzKom2/OmP0vXzyFpZSmeUAn6ckVcewq9R3SHfmbdy3hIBa wcQyqwsz1L1d3RJOW/L+rqHpuXC/seWUh3AAHTyTxihNhjj6mOW1aRHcSl5APtO0bUIojGmq6 oKed3edd//zXA87VGOf5TCK0kP9zKK1+hRDt3cLSYwNlqHBchTqKZD69RsI= Archived-At: Subject: [Ace] ACE Status Update and Planning X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:28:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Pv3fF3uAfeVdSmWUK6urwvEGUPUiMW1eW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, here is a short summary of recent activities and some planning activities. (Below there are also some questions for you.) Let me start with a summary of what happened recently: * A few days before Christmas 'Authorization for the Internet of Things using OAuth 2.0' was published (which reflected the consensus from the ACE f2f meeting in Yokohama and the discussions on the list afterwards). Here is the link: http://www.ietf.org/mail-archive/web/ace/current/msg01603.html A Github repository was created at https://github.com/LudwigSeitz/ace-oauth, which is also used to track open issues. Here is the link to the open issues: https://github.com/LudwigSeitz/ace-oauth/issues * IAB Workshop on Semantic Interoperability To get discussions between different SDOs about interoperability at the object level going the IAB announced a workshop and I posted the announcement to the list, see http://www.ietf.org/mail-archive/web/ace/current/msg01609.html The workshop page itself can be found here: https://www.iab.org/activities/workshops/iotsi/ * CBOR Web Token We had a discussion about the appropriate home for doing the standardization work around the CBOR-based encoding of the JWT and we finally concluded that the best place is the ACE working group. Here is the draft announcement mail Mike distributed: http://www.ietf.org/mail-archive/web/ace/current/msg01593.html We will start a call for adoption any day. * OMA LWM2M Tutorial We ran a tutorial about LWM2M before Christmas and the slides&recording was posted to the list: http://www.ietf.org/mail-archive/web/ace/current/msg01604.html We appreciate volunteers to give talks about other standardization activities. Please drop us a mail if you have time and interest. In an attempt to update the milestones we need your input for planning purposes. * The 'Use Case' document is in AUTH48 and will be published as an RFC soon. * The ACE architecture/actors document needs to be finished and I had a chat with Carsten about the open issues. I am sure that Carsten will post a mail to the list soon. * The 'Authorization for the Internet of Things using OAuth 2.0' specification needs to advance and the issues need to be close. It would be good to get some early implementation work started. There is also a Hackthon at the upcoming IETF meeting. QUESTION: Are you planning to attend the upcoming IETF meeting (and the ACE meeting in particular)? (Drop us a private mail) QUESTION: Are you interested in participating at the hackathon at the upcoming IETF meeting to work on ACE-related topics? (Drop us a private mail) QUESTION: Do you do have resources to contribute to implementation/prototyping efforts in the next few months? (Drop us a private mail) There is also a workshop on OAuth security on the week before the IETF meeting in Berlin, see announcement at http://www.ietf.org/mail-archive/web/oauth/current/msg15339.html. The IoT usage of OAuth could be discussed there if researchers and others do their security analysis. QUESTION: Are you planning to attend the security workshop in July? (Drop us a private mail) We might need to do a bit of document management with to split profiles into separate drafts. This may help us to involve more persons actively in the work. We are also thinking about how to get interoperability testing started and organized. Of course, we will first need to reach a state where the specification is solid enough. I have been reaching out to the OpenID Foundation to find out whether there is a chance to re-use some of their testing and certification infrastructure. Other ideas are also welcome! Please let us know if you think we should be looking into other topics as well as part of the ACE work. Ciao Hannes & Kepeng --Pv3fF3uAfeVdSmWUK6urwvEGUPUiMW1eW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWlhjJAAoJEGhJURNOOiAtkZIIAInn3sAaW7nLQ6i7fBDF992F UApnqwh8CULxbqk0Cfz9XKLMGMFm75Jx0hBnEbVJ2aA81xIoBTsyLRqB3X4GJBd6 eKXnSgBRiHLHmLqWwz75+4X1p8K/2iDFVmy6x4jn/juMjvdgk2Yo/fnVTxqcOmCz r6xez4NbzDafVDHdFtXyUrjuXiue/lcLcVOy0arjle05Qieche5tLygrFxC9gkAC Xl5N0K33503+akPSIYv8Moh1jf1WOjel8s+bI2uNgLU/h6VkmdGWhuENFlKzTlix sXAItkpLbhuwkaFYC+A8ykPDyywbgUn8FoGlR1ipbvxG1tDyb1vqdaXMOL7XxcI= =JNtQ -----END PGP SIGNATURE----- --Pv3fF3uAfeVdSmWUK6urwvEGUPUiMW1eW-- From nobody Wed Jan 13 17:07:31 2016 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A12691A8A75 for ; Mon, 11 Jan 2016 08:34:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111163457.17309.69756.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 08:34:57 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 13 Jan 2016 17:07:30 -0800 Subject: [Ace] Milestones changed for ace WG X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:34:57 -0000 Changed milestone "Submit "An Architecture for Authorization in Constrained Environments" as a WG item.", resolved as "Done". Changed milestone "Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.", resolved as "Done". Changed milestone "Submit "An Architecture for Authorization in Constrained Environments" to the IESG for publication as a Informational RFC.", set due date to March 2016 from December 2015. Changed milestone "Submit "Authentication and Authorization for ACE" specification as a WG item.", set due date to March 2016 from January 2016, resolved as "Done". Changed milestone "Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard.", set due date to May 2016 from March 2016. URL: https://datatracker.ietf.org/wg/ace/charter/ From nobody Fri Jan 15 06:33:31 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D481B2DA5 for ; Fri, 15 Jan 2016 06:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8072ejco7Uc for ; Fri, 15 Jan 2016 06:33:26 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0121.outbound.protection.outlook.com [104.47.2.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC0E1B2D99 for ; Fri, 15 Jan 2016 06:33:24 -0800 (PST) Received: from DB5PR06CA0030.eurprd06.prod.outlook.com (10.162.165.40) by DB4PR06MB265.eurprd06.prod.outlook.com (10.242.231.142) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 14:33:22 +0000 Received: from DB3FFO11FD024.protection.gbl (2a01:111:f400:7e04::156) by DB5PR06CA0030.outlook.office365.com (2a01:111:e400:52c2::40) with Microsoft SMTP Server (TLS) id 15.1.365.19 via Frontend Transport; Fri, 15 Jan 2016 14:33:22 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD024.mail.protection.outlook.com (10.47.217.55) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Fri, 15 Jan 2016 14:33:21 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.111]) by ATDOAGMSX01.itiso.net ([169.254.3.88]) with mapi id 14.03.0248.002; Fri, 15 Jan 2016 15:33:21 +0100 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-somaraju-ace-multicast-01.txt Thread-Index: AQHRT5ts4XdXFGB160KKn8EL8Cn8m578oyFA Date: Fri, 15 Jan 2016 14:33:21 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1E76B8@ATBRAGMSX02.itiso.net> References: <20160115134828.1142.35490.idtracker@ietfa.amsl.com> In-Reply-To: <20160115134828.1142.35490.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD024; 1:pPJxJMy3Kv7D4D2DjmHDZuz2jUE9KTrX7rDXG+OYgsJa/bmMAv693LniMO828rFC4/GW1YFgzNLCHRJ2pNXHpU991H9UjyXYdY0AeFM7wMc9QmDv5T5CVmKibD2y3mSAVUFss2K/N6f6p8JJo6C8FajzbbRY9Jvxpl/JLLumGNIKmzfa6sdWH4rZzjERVGshsGFHcTWQZemo+sMF+/vy+QMRd5r0W9LeAeK312UOub7ZyHem2iljR3JECWgLrUwb5PoCbJ2HP+gx4eVexvjz6fHWUXJTTXzRPKtQfE8gK+2v3jT6ZF4mNIvc/KZeTcaWFZ3Az08vH8oT+9RQLR0jXw== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377424004)(13464003)(189002)(199003)(86362001)(5003600100002)(5001960100002)(2950100001)(106116001)(106466001)(230783001)(23676002)(2920100001)(50986999)(5890100001)(54356999)(19580405001)(19580395003)(33656002)(76176999)(450100001)(189998001)(2906002)(5004730100002)(87936001)(15975445007)(2501003)(110136002)(50466002)(102836003)(53416004)(1096002)(81156007)(6116002)(586003)(2900100001)(107886002)(26826002)(1220700001)(47776003)(2351001)(69596002)(1730700002)(66066001)(11100500001)(92566002)(104016004)(6806005)(55846006)(5008740100001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB265; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB265; 2:6/+kV4x8uvKS4/Zj08b6sbhIk+qQvwP2t6oFSDOE7x6WASyuGniwakVDgJCwrku8Vilev/dvK16/LdwD5pVs7HW5hug0hjvwIaISxeuWLf9E4GEVidSek7HOpDmFw7MVtPOoCXLid3THK4kpytFQWQ==; 3:9u5VTdI0JXvPA/Algq4J1BSafYU35VGvIAfW92QxKRjKxV9fGEKJBqo8dUmMzDkr/7Y4u4Q2Mn2cmCvguCq67rpOmzCVK8SuoGsQQ+GruZDZHOAZwQwCyToiQb9khLRfBH/F9a/AZKkaTIVHC024rkXUv72KSWHysgcqGUsvPS/XzfkusEz8OwUJ634M+vxp0c9joNNLSMEjlcetPkvMS8QzOwtpvV5CoH4utCKicWQ55MJ6e6Ymau9hEBjSuORw1hCNgR/T7anorypJah6n9Q==; 25:3qUCPp6/COs6zvgDLdTh1R2LxLJJm5Cqf/n8kvPztliNNkgOOq4EbJkxfuvnfloOnuLgPO20XirJUbNP7oyoCVyhxYVMU2iQkeHxN3+xP8IKJ1TwuBDRqBIoIscwOU0To4k01msq25KvSb+XmhGzdi08crj/tbCIV3gXx/SoOaR/ZM3EqNkNwGOh6Q7KQZ0NU/gcrvSRBBK6e5GWo6YHtYXJ21BQ6cciKkue/Sgy2ML8iv9kk5KcpDNg9cUd5zRQ X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB265; X-MS-Office365-Filtering-Correlation-Id: 9d0051b8-85d0-430a-f6fc-08d31db8d1d7 X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB265; 20:GBIMfC7R3+QJU81Iyy2tqC13oC3tMxOsbUzFiZae6mgVNy+9lm40aoBcZcaCT4Y1aqOKaum5NoZRm0A40RDYj1ZLGodd4JyTEbOW0T4lGu+8PovugAT4SGiE1KPDyEVKwftHm1ekULIOJy8dwz5mo46R4DAMV/UPZBi8GBDML7UjZ6kTl1n6ggTJYYemA1+s2NQO3Zmo0bAGj0P9tPR2LdmD1+5yFttHgHHPeJCYneuthvgqn6FaN+5LuSeUnJlGL7+oCKCXZP3Xh2BsxH5923VwFExXhXoi4OBvYpM2LJZpexlxe4oupD1+BpC5fVyPUa3BRnCP6papDPZkijWuThI+f3/ge8A9BFpiOkZO9hsKiAVWVAT/jgBDAhuryDbA9wCnP1kLb3rqDViD72CwJ6etv2GTwIMlXyCjNr3YwTGQHts+iR9DLdp2FhVH8MacKXu/COfH7N4fPbCU1nN/I/tbm9kDcA7suX4gz5s6hi4gmVKdbrzFIXUOhwE1lrYu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(13021025)(13018025)(13016025)(13013025)(3002001)(10201501046); SRVR:DB4PR06MB265; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB265; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB265; 4:GJbs6nmMkkiFPW2w5o7vsApAMRtY4tIR/O81sV/S6s7n/OT/J/MwwLxfFvSviyQWgfqTS69Nec7R+q7rMq78+Fwgz/dbyP3CBUQlmZL315+EZlDLPnQP+f/jqGnpECdV5dYtLTPUf2yXDg2fB7pObL8Sdox4CyaNOjESqSocP+37hSV99q1tMFJ4IN4X3jK4clkCSM4J04LDiNR0JCAD3yFE04DzRhckNpiz1gOsE6upI7VZ4IdSiiXDYDSCJGeIpDtcSMndsrBwOL9uobofhKcy8eSAjZq7nzFraN1MhckMhemiceinlnrUPofbpaWIs6X53bG9SzGTYw2sKftwJ38kVzU24YJHCF6XrnvCdTLjs6KkvbQgczkBhvMy0jvrbTR2EbS0B76VLamtRGszxJ+L6GUAC40X/pkhEaZAec/AI1ltloKqY76lPKS/58pQFuMlmOqneqExNr+xq4pGGA== X-Forefront-PRVS: 08220FA8D6 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjRQUjA2TUIyNjU7MjM6S1JpaThBb3Jyb0JyNm0xZzZOWWEvdlp3T3NR?= =?utf-8?B?STlmWFZjTmN0S3dpWTBjQlpidGZOUWU4YjVtKzFaYzBvcXczTzNiTjR2d01Z?= =?utf-8?B?VHlwVDd3d2hoMzhNZ3JsN0N1Vm5ZYldsT1gzeGxNeHBIRkUzZGV2WC9VMjhs?= =?utf-8?B?QmV5U2x5WDdvU2dQNytzeXN0NlZybTJTTXM2SUsxTHpqWEJjekR0eUVEODd1?= =?utf-8?B?S1NSV3RUZ2w3MGhRTHp5VnFZb1YxTGFlREpqMkQySEZJYTZncXNqUE1Ca3Ns?= =?utf-8?B?TzRQK29JMjNtR09GV20wUVN1aFRxYkJBZnFxNWZ6SmJYeU9rYkd6SklrT2R2?= =?utf-8?B?QllQU29jaFh4WEdSaUs1SExRbmVCdlUrY1ovU25nTkFRcDY4VDNSVFRsSTZV?= =?utf-8?B?S1oxQU1EN1VkRW9lM1NnQlFDTmY2QVRwUlpqVzZoaGlsY21pVFFiTE5yVkJ0?= =?utf-8?B?L1hTRHZ4U3EyY0RlQXExWjIwQnZpaE96THNxaFBuTGJGWUNNVDZBd1lnS2xj?= =?utf-8?B?aUJIZXJ1VmxDY1RpeFFoNUFzTzFpaWd1QUszZlFtT3BuMEhrbWtVQjhvS2s5?= =?utf-8?B?WFlZWWFPR2hvUlhPd1BSbGZZR1ZRM3R1aCtmWlJxOVhpWFMzdzVqT3hTZC9C?= =?utf-8?B?Vm0zS2E1TFpNVmEwM3FGcEk4Z0xVM3F4QU1xVlA1TUlZUUdGQXp1Z2hjVGxD?= =?utf-8?B?TWZIMU0ybWo3Vkg3K3FOOVoyb3VpUzdVZnhPQ0trSlBoS1dmRm13QUY3Qlla?= =?utf-8?B?d1RydmF0bDdoZGF2TGRGWk0wVTV1dkZ2UkczcW1oSks1Q1Bic3hsVWZ1NTFz?= =?utf-8?B?VFo3RFNNaG5OdHZ3RkFGVU5XZWphVU9jT2dycEdvNUxPY3BIL1pzc0hFenJZ?= =?utf-8?B?dHlXcVJ3MTJ0b2xReGxueTNheWJzNUhsb2pCWWV4dkZzK3A2U1RQRmdIS1VE?= =?utf-8?B?YkJIN0czNTE4YWM2Q3pQbERJMkpKQTEra05LeTJyTE1pNHJhclJBdFVZYVpv?= =?utf-8?B?Q3NyaU1hYnd6N05aNmtUbm5GeHR1Q3gzaUJlOUJlN1VUQmhzai81UWc4VEN3?= =?utf-8?B?RW5rcU11U2pteUo2K1RJMGV3blNCMk5udnFSNDRpRDhmSURtNkVXN3liViti?= =?utf-8?B?L3Q1S0MxQTVFWkcwb0x5MTZ2aHlhUzdzbWFzR01WaHFvdDd4d3g3VmlYS2E1?= =?utf-8?B?UnUxV0MwUlN5Q0s5WEpwaVNTRGR3Yk1JZ054UEl0TmtpUHdKbVZwVWV0SW5w?= =?utf-8?B?Q0g4aXpUVFBEazU1NkE0MGZYUUlybDlubUNSK1NFalZRaEd2K1hIL1Ztb3Rn?= =?utf-8?B?di85K21ZQzdvY0prV0YzQ1NXdlY3QnB1TVJRZk0yMXYwaFVYZ0xrT0hNRzdr?= =?utf-8?B?cjFTcStUVUo1NWkyZVlXdHZ3WmFYeThkdzhrMzEraVJmZTFva0Q2UEJ5OHh5?= =?utf-8?B?ZmFJckVncnI4QmRBL3RQdGRWNERaT29BdlR1a3ZHZlkySWlFSmZjR1JrWTlI?= =?utf-8?B?K01TRkl1clFoK0dZSkpGaU82MmZjd0dOUEI4Wnl2cnp5THhwOVBTOGhwaUtP?= =?utf-8?B?dG1YM1RVMTNpOFo3eThVRzRkLzh1V1M3VjhFTTFacUw1OVhoS0xhUElqUWx0?= =?utf-8?B?Yi9ueHZEL1JRTHVsWEp2Njd1ZlpDMFM1MmhYaHFIWmdPdkV5Um1nc3RPQ05k?= =?utf-8?B?QllidGFLVjhUaDN6NjI1SFdQbG9ySlRVc3NVOTFhYlBCMWNaY2szaEFaWXJs?= =?utf-8?B?TmxkbHRKUHdxRmFyTjdjTXBnNFpucm9kQkZjZWU1MFBsVVdZbm8vZmgraFlQ?= =?utf-8?B?VUkxZUFvM2FQV2NRSDhRMFFSd0ZOanZBMG85dDRqTnVTMlpCNzM1MHZRQVZq?= =?utf-8?Q?o2qZrZjzG0=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB265; 5:IcvS/Mlyu3EvBS5oe5n61Q/F6JN2pjE7Ak0DNjpn31ut421JezNEInNHVnkc6QFfK3zgTW5VP+GnuEK5KFTQqVOFiAIL3G1WhQqu9CkTlFYERbAwFlO76eTIyxOJKOHRH2NRaiVvGDcBZcx0/Qsagg==; 24:qCYKqbJDYIcfX3zQ16s7Cn+K2UuVKyxB7l7bkpMPQbEkPNrntD7AjR7/CJIDC4ya0dpn2WoYeCHCvdQnuuk6Cw+ug2qYmMMObwSOMh6Bhcc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2016 14:33:21.8031 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB265 Archived-At: Subject: [Ace] FW: New Version Notification for draft-somaraju-ace-multicast-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:33:30 -0000 RGVhciBBbGwsDQp3ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgIlNlY3VyaXR5IGZvciBM b3ctTGF0ZW5jeSBHcm91cCBDb21tdW5pY2F0aW9uIiBkcmFmdC4NCg0KRGVzY3JpcHRpb24gb2Yg Y2hhbmdlcyBmcm9tIHByZXZpb3VzIHZlcnNpb246DQotIFJlb3JnYW5pc2VkIHRleHQvY29udGVu dCBmb3IgY2xhcml0eQ0KLSBGb2N1c3NlZCBvbiB1c2luZyBPYmplY3QgU2VjdXJpdHkgaW5zdGVh ZCBvZiBtdWx0aWNhc3QgRFRMUw0KLSBSZW1vdmVkIHJlZmVyZW5jZXMgdG8gTFdNMk0NCi0gTW9y ZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBvbiBjb250ZW50IG9mIGFjY2VzcyB0b2tlbnMgYW5kIGdy b3VwIG1lc3NhZ2VzDQoNClJlZ2FyZHMsDQpBYmhpbmF2DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQpTZW50OiBGcmVpdGFnLCAxNS4gSsOkbm5lciAyMDE2IDE0OjQ4DQpU bzogU29tYXJhanUgQWJoaW5hdiA8YWJoaW5hdi5zb21hcmFqdUB0cmlkb25pYy5jb20+OyBIYW5u ZXMgVHNjaG9mZW5pZyA8SGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD47IFNhbmRlZXAgUy4gS3Vt YXIgPGlldGYuYXV0aG9yQHNhbmRlZXAta3VtYXIub3JnPjsgSGFubmVzIFRzY2hvZmVuaWcgPEhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+OyBXYWx0ZXIgV2VybmVyIDx3ZXJuZXJAd2VybmVyLW1z LmF0Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zb21hcmFq dS1hY2UtbXVsdGljYXN0LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1z b21hcmFqdS1hY2UtbXVsdGljYXN0LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBIYW5uZXMgVHNjaG9mZW5pZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0DQpSZXZp c2lvbjogICAgICAgMDENClRpdGxlOiAgICAgICAgICBTZWN1cml0eSBmb3IgTG93LUxhdGVuY3kg R3JvdXAgQ29tbXVuaWNhdGlvbg0KRG9jdW1lbnQgZGF0ZTogIDIwMTYtMDEtMTUNCkdyb3VwOiAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxOQ0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zb21h cmFqdS1hY2UtbXVsdGljYXN0LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbWFyYWp1LWFjZS1tdWx0aWNhc3QvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvbWFyYWp1LWFjZS1t dWx0aWNhc3QtMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtc29tYXJhanUtYWNlLW11bHRpY2FzdC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFNv bWUgSW50ZXJuZXQgb2YgVGhpbmdzIGFwcGxpY2F0aW9uIGRvbWFpbnMsIHN1Y2ggYXMgbGlnaHRp bmcsIGhhdmUNCiAgIHN0cmljdCByZXF1aXJlbWVudHMgb24gbGF0ZW5jeSBmb3IgZ3JvdXAgY29t bXVuaWNhdGlvbi4gIEZyb20gYSB1c2VyDQogICBleHBlcmllbmNlIHBvaW50IG9mIHZpZXcgbGF0 ZW5jeSBsZXNzIHRoYW4gMjAwIG1zIGlzIG5lY2Vzc2FyeSBmcm9tDQogICBhbiBhY3Rpb24gdHJp Z2dlcmVkIGJ5IGEgdXNlciB0byB0aGUgdmlzaWJsZSBlZmZlY3RzLiAgVGhpcyBkcmFmdA0KICAg ZGVzY3JpYmVzIHByb2NlZHVyZXMgZm9yIGF1dGhvcml6YXRpb24sIGtleSBtYW5hZ2VtZW50LCBh bmQgc2VjdXJpbmcNCiAgIGdyb3VwIG1lc3NhZ2VzIHdpdGhpbiBhIGxvdyBsYXRlbmN5IGFwcGxp Y2F0aW9uIGRvbWFpbiB3aXRoIGEgc3BlY2lhbA0KICAgZW1waGFzaXMgb24gbGlnaHRpbmcgc3lz dGVtcy4gIFdlIHNwZWNpZnkgdGhlIHVzYWdlIG9mIG9iamVjdA0KICAgc2VjdXJpdHkgYXQgdGhl IGFwcGxpY2F0aW9uIGxheWVyIGZvciBncm91cCBjb21tdW5pY2F0aW9uIGFuZCBhc3N1bWUNCiAg IHRoYXQgQ29BUCBpcyB1c2VkIGFzIHRoZSBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbC4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBi ZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUg b3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNl aXZlZCBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0 IG5laXRoZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSBy ZXNwb25zaWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0 byBzY2FuIG9yIG90aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz Lg0K From nobody Fri Jan 15 06:57:45 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2451F1AD0C8 for ; Fri, 15 Jan 2016 06:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBN80riGgbNY for ; Fri, 15 Jan 2016 06:57:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EA71AD0B4 for ; Fri, 15 Jan 2016 06:57:42 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ln8Tl-1ZfGtV0Gp3-00hMSu for ; Fri, 15 Jan 2016 15:57:40 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569908E2.4060402@gmx.net> Date: Fri, 15 Jan 2016 15:57:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GNnU8US82tqifL3CRH94mA7G6LbnjQD62" X-Provags-ID: V03:K0:2F6q3Jva3Fhs2V3trcLNh9djVOF+10nYErP4njVbyaz+9rKXL4G GfUl/yoi0wGQKdC61EKlxtxLLbSZRIMXMs9FtcWzaTDl4r7tp1F4WK+0cWQh9zaxfK262lm gSQpJRIvVHYwFolNvC2YWkGPyQbPz/oi1u5zMqsF3AaMw78J03sqRvauL55LigeLfHwUgvv eiXpkvkNYFPpRXcS/7Rbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:AsRMSXjmX6U=:5i6qRCJBGHBmgUv3rlc4q9 SUgwlZFCFr4+v5enfEvBEzjo3VryGVXdTgHxaHY4e8PvLNOQXkxI192hEF20/aGsMhPsinYEQ k2+4ZAFLI/HOwY3qXW53FWddl+OGVBRmuJMo9YhD0dzLspSoyrJRnpwSSMzjO4GTTAYE00idb WwJDYLhAzxawATzmO2R5GpEM+sFD20vJVKn/inbtqE/qn1gdLq3LeumVzfSqga3v6xVAW122j OFbfNpxS/ZBFkXvYFcF+//U4gSwRYbluTVqtE2I+ptV2MfLQLWADVcogYrjxC5MG4dZfZp7UZ nqadXi3D8GVED9W5whd1Zv1vrpow5q7yb9lVodmthF/EOdBV8nKrMzqgmSa/jhVtfqbZTLITe w8nrHnybz/OyriL9OTw4EBXxy4leYebnrLwegcm0QSNYgP4mu+0kq0jLgcLIY9F36Swf6Ks5I 1BVvb+Zko44WvGroA0r4XejrrabWgN41oRJuF9C19vJIy3EyHb638knqKlnQ0HhcCpTbv97+c dBFhNYpkkHM/qUDKBnudCEboALGVHPc7qQkufIGHL4JyJBWt8d9VCWY/2R0pIs4r2+ys/6XAo +VqP424/igVTr1VZM6UzbMplnxf+kNuhRr1mU/qRsG1MdAXIvcNWtrASqOEbB2gug5/8ms1dN D82TRUHLK7H01gqraPuB6NijIVy1htmw6fCMPb6Mt2cIvFBMzu5xUo6V05mvQhbYACaSQGHOK p5Q//UKG/Z4ICYOBiKks4iYqJ+EORc8plHszhWikZSEQ3Xv+wT5cjoklctA= Archived-At: Subject: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:57:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GNnU8US82tqifL3CRH94mA7G6LbnjQD62 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the ACE WG meetings we had various talks about object security and as we are moving our work along in the group it would be good to make some plans about it. We need your feedback regarding two issues: 1) Do you believe that object security standardization work (using COSE) should be done in this working group? If it shouldn't be done in this group which other group do you have in mind? Object security in this context refers to ways to protect messages conveyed over CoAP and to also include various CoAP header fields in the protection. 2) What use cases are you interested in? 3) In various meetings Goeran presented OSCOAP, see https://tools.ietf.org/html/draft-selander-ace-object-security-03 We are not entirely sure about the role of https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 which was presented at the last IETF meeting. Here are the slides presented by Carsten: https://www.ietf.org/proceedings/94/slides/slides-94-ace-4.pdf The last slide contains about the difference between OSCOAP and draft-bergmann-ace-dcaf-cose-00. Have people reviewed the documents? What functionality offered by these specifications do you like/dislike? Is functionality missing? Ciao Hannes & Kepeng --GNnU8US82tqifL3CRH94mA7G6LbnjQD62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWmQjjAAoJEGhJURNOOiAtVLcH/RvamEv9liwMW5a62AFqb6+G JqLTuJ0DFpG7ooMXA86bI1sBUOt9Fx2mBfsDmydvXOunzqo0j9mYv2x6DmdGzFDy 4OE2vJOcAsXm2KNh87VT1WRrnVPh4IQtAImpmUjvoLAU0cE201qtUCad2td9r2nm wK4d7XgkKu2yqmbh9kNzUW0o8t6qnPdj+JQnXDTV8O5Ap96drUVx5td179PyzNmV /MzJOcG7k7n+9YRamK3LjKjaVDYKeujquOWhxGQZZv4xE6VDotFZvLx+7bCIUlAG W2b1ZoKiUk2itV2HUk2xUKEogbEmoujjY3C0Vfo2k1lh8ZSjHuEng4+UVgxQdzA= =5E+p -----END PGP SIGNATURE----- --GNnU8US82tqifL3CRH94mA7G6LbnjQD62-- From nobody Fri Jan 15 07:53:06 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932561B2F61 for ; Fri, 15 Jan 2016 07:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efd7KY3UrXtY for ; Fri, 15 Jan 2016 07:53:02 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3931B2F60 for ; Fri, 15 Jan 2016 07:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u0FFquYG028231; Fri, 15 Jan 2016 16:52:56 +0100 (CET) Received: from aung.tzi.org (eduroam-pool5-074.wlan.uni-bremen.de [134.102.48.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3phn8m601zz31RC; Fri, 15 Jan 2016 16:52:56 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <569908E2.4060402@gmx.net> Date: Fri, 15 Jan 2016 16:52:56 +0100 In-Reply-To: <569908E2.4060402@gmx.net> (Hannes Tschofenig's message of "Fri, 15 Jan 2016 15:57:38 +0100") Message-ID: <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 15:53:04 -0000 Hannes Tschofenig writes: > We are not entirely sure about the role of > https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 Who is "We"? Gr=C3=BC=C3=9Fe Olaf From nobody Fri Jan 15 08:02:43 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1E1B2F85 for ; Fri, 15 Jan 2016 08:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIFRMJkXbcK9 for ; Fri, 15 Jan 2016 08:02:34 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894401B2F84 for ; Fri, 15 Jan 2016 08:02:33 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-86-5699181733b8 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.23.02707.71819965; Fri, 15 Jan 2016 17:02:31 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.104]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Fri, 15 Jan 2016 17:02:31 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] Object Security Work in ACE Thread-Index: AQHRT6UZs/cMaFZzZEm3L0Hz2SFve578vQiA Date: Fri, 15 Jan 2016 16:02:31 +0000 Message-ID: References: <569908E2.4060402@gmx.net> In-Reply-To: <569908E2.4060402@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7oK64xMwwg7uf9S2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx+8xq5oIz8hUT7nYyNTA+keti5OCQEDCR 2L5Yr4uRE8gUk7hwbz1bFyMXh5DAYUaJXZeXsEI4SxglXrx5xQxSxSbgIvGg4RETiC0iECRx 4O4CRpBBwgJ6Em+u8EKE9SWmTH3OCmEbSbS0LmUBsVkEVCV+rD8G1sorYCFxe/kRsLiQgJrE /gsL2EDGcAqoSzxbygYSZgS65/upNWDlzALiEreezGeCuFNAYsme88wQtqjEy8f/wFaJAl2w +8kpRoi4osTOs+3MICOZBTQl1u/ShxhjLbFn5VcWCFtRYkr3Q3aIawQlTs58wjKBUXwWkm2z ELpnIemehaR7FpLuBYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+zglt8GOxhfPnc8 xCjAwajEw1ugMSNMiDWxrLgy9xCjBAezkgjvA+GZYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 k2Qaw4QE0hNLUrNTUwtSi2CyTBycUg2MrnP3PVda2ZywVVRXorKy7KLAatWrghpLygVcDR9v 8JNj5HkhpXJ6w9GHIet3NfivO7RWvL0v2Jbvx6a0Yyef3M9cdevqm9XxH6o+bXrPLzVpyyWd vYV9/uK83xV/XBU56qq7KF1VwPnm+/h9hR1mfwofiExNbtu5vfRrvaVd/sPzNZtWOyx6pcRS nJFoqMVcVJwIAInHW8KvAgAA Archived-At: Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 16:02:37 -0000 SGkgSGFubmVzLA0KDQpPbiAyMDE2LTAxLTE1IDE1OjU3LCAiQWNlIG9uIGJlaGFsZiBvZiBIYW5u ZXMgVHNjaG9mZW5pZyINCjxhY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj5IaSBhbGwsDQo+DQo+ZHVyaW5nIHRoZSBB Q0UgV0cgbWVldGluZ3Mgd2UgaGFkIHZhcmlvdXMgdGFsa3MgYWJvdXQgb2JqZWN0IHNlY3VyaXR5 DQo+YW5kIGFzIHdlIGFyZSBtb3Zpbmcgb3VyIHdvcmsgYWxvbmcgaW4gdGhlIGdyb3VwIGl0IHdv dWxkIGJlIGdvb2QgdG8NCj5tYWtlIHNvbWUgcGxhbnMgYWJvdXQgaXQuDQo+DQo+V2UgbmVlZCB5 b3VyIGZlZWRiYWNrIHJlZ2FyZGluZyB0d28gaXNzdWVzOg0KPg0KPjEpIERvIHlvdSBiZWxpZXZl IHRoYXQgb2JqZWN0IHNlY3VyaXR5IHN0YW5kYXJkaXphdGlvbiB3b3JrICh1c2luZyBDT1NFKQ0K PnNob3VsZCBiZSBkb25lIGluIHRoaXMgd29ya2luZyBncm91cD8gSWYgaXQgc2hvdWxkbid0IGJl IGRvbmUgaW4gdGhpcw0KPmdyb3VwIHdoaWNoIG90aGVyIGdyb3VwIGRvIHlvdSBoYXZlIGluIG1p bmQ/DQo+DQo+T2JqZWN0IHNlY3VyaXR5IGluIHRoaXMgY29udGV4dCByZWZlcnMgdG8gd2F5cyB0 byBwcm90ZWN0IG1lc3NhZ2VzDQo+Y29udmV5ZWQgb3ZlciBDb0FQIGFuZCB0byBhbHNvIGluY2x1 ZGUgdmFyaW91cyBDb0FQIGhlYWRlciBmaWVsZHMgaW4gdGhlDQo+cHJvdGVjdGlvbi4NCg0KVGhp cyB3b3JrIGhhdmUgZGlmZmVyZW50IHBhcnRzIHdoaWNoIG1heSBiZWxvbmcgaW4gZGlmZmVyZW50 IFdHcy4NCg0KMS4gT25lIHBhcnQgaXMgb24gZXhwYW5kaW5nIG9uIHRoZSBtb3RpdmF0aW9uLiBB IHNob3J0IGJhY2tncm91bmQgaXMNCnByb3ZpZGVkIGluDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAzI3NlY3Rpb24tMg0K DQpQZW9wbGUgaGFzIHNob3duIGludGVyZXN0IGluIG1ha2luZyB0aGlzIGludG8gYSBtb3JlIGZv cm1hbCBhbmFseXNpcy4gT25lDQpkcmFmdCBpcyBwbGFubmVkIHRvIGJlIHN1Ym1pdHRlZCB0byB0 aGUgQ09SRSBXRyBpbiB0aW1lIGZvciBuZXh0IEYyRg0KbWVldGluZy4NCg0KMi4gQW5vdGhlciBw YXJ0IGlzIHRvIGV4cGFuZCBvbiBob3cgdGhlIENvQVAgaGVhZGVycyBhbmQgb3B0aW9ucyBzaG91 bGQgYmUNCmhhbmRsZWQsIHdoaWNoIGlzIGN1cnJlbnRseSBpbg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMyNzZWN0aW9u LTYNCg0KVGhpcyBpcyBhbHNvIHBsYW5uZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIHByZXZpb3Vz bHkgbWVudGlvbmVkIGRyYWZ0IHRvDQpDT1JFLg0KDQoNCjMuIEEgdGhpcmQgcGFydCBpcyBob3cg dG8gd3JhcCBDb0FQIGhlYWRlcnMsIG9wdGlvbiBhbmQgcGF5bG9hZCBpbnRvIGENCkNPU0Ugb2Jq ZWN0LCBhbmQgaG93IHRvIGNhcnJ5IHRoYXQgQ09TRSBvYmplY3QgaW4gQ29BUC4gVGhpcyBpcyB0 aGUNCnJlbWFpbmRlciBvZiBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAzLCBh bmQgdGhlcmUgbWF5IGJlIG90aGVyDQpwcm9wb3NhbHMgYXMgd2VsbC4gSSB0aGluayB0aGlzIHdv cmsgYmVsb25ncyB0byBDT1JFLg0KDQoNCjQuIEEgZm91cnRoIHBhcnQgaXMgaG93IHRvIGluZGlj YXRlIGluIHRoZSBPQXV0aCBmbG93IHRoYXQgb2JqZWN0IHNlY3VyaXR5DQppcyBnb2luZyB0byBi ZSB1c2VkIGFzIGNvbW11bmljYXRpb24gc2VjdXJpdHkgcHJvdG9jb2wgYmV0d2VlbiBDbGllbnQg YW5kDQpSZXNvdXJjZSBTZXJ2ZXIuIFRoaXMgaXMgZGVzY3JpYmVkIGluIGRyYWZ0LXNlaXR6LWFj ZS1vYXV0aC1hdXRoIHdoaWNoIG9mDQpjb3Vyc2UgYmVsb25ncyB0byBBQ0UuDQoNCg0KNS4gQSBm aWZ0aCBwYXJ0IGlzIGhvdyB0byBlc3RhYmxpc2ggdGhlIHNlY3VyaXR5IGNvbnRleHQgdG8gdXNl IGZvciBvYmplY3QNCnNlY3VyaXR5IGFzIGluIDUuIFRoaXMgaXMgYWRkcmVzc2luZyBvbmUgb2Yg dGhlIHJldmlldyBjb21tZW50cyBvZg0KZHJhZnQtc2VpdHotYWNlLW9hdXRoLWF1dGh6LiBBIGRy YWZ0IGlzIHBsYW5uZWQgZm9yIHRoZSBuZXh0IEYyRiBtZWV0aW5nLg0KSSB0aGluayB0aGlzIGJl bG9uZ3MgaW4gdGhlIEFDRSBXRy4NCg0KDQpEaWQgSSBmb3JnZXQgc29tZXRoaW5nPw0KDQoNCkfD tnJhbg0KDQoNCg0KDQo+DQo+MikgV2hhdCB1c2UgY2FzZXMgYXJlIHlvdSBpbnRlcmVzdGVkIGlu Pw0KPg0KPjMpIEluIHZhcmlvdXMgbWVldGluZ3MgR29lcmFuIHByZXNlbnRlZCBPU0NPQVAsIHNl ZQ0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0 LXNlY3VyaXR5LTAzDQo+DQo+V2UgYXJlIG5vdCBlbnRpcmVseSBzdXJlIGFib3V0IHRoZSByb2xl IG9mDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcmdtYW5uLWFjZS1kY2Fm LWNvc2UtMDANCj53aGljaCB3YXMgcHJlc2VudGVkIGF0IHRoZSBsYXN0IElFVEYgbWVldGluZy4g SGVyZSBhcmUgdGhlIHNsaWRlcw0KPnByZXNlbnRlZCBieSBDYXJzdGVuOg0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQtYWNlLTQucGRmDQo+DQo+ VGhlIGxhc3Qgc2xpZGUgY29udGFpbnMgYWJvdXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBPU0NP QVAgYW5kDQo+ZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS0wMC4NCj4NCj5IYXZlIHBlb3Bs ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnRzPyBXaGF0IGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0 aGVzZQ0KPnNwZWNpZmljYXRpb25zIGRvIHlvdSBsaWtlL2Rpc2xpa2U/IElzIGZ1bmN0aW9uYWxp dHkgbWlzc2luZz8NCj4NCj5DaWFvDQo+SGFubmVzICYgS2VwZW5nDQo+DQoNCg== From nobody Fri Jan 15 08:17:06 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF5C1B2F9E for ; Fri, 15 Jan 2016 08:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRgT2hDjvjhb for ; Fri, 15 Jan 2016 08:17:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF921B2C19 for ; Fri, 15 Jan 2016 08:17:02 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVedf-1afMeh32tz-00Z2Jp; Fri, 15 Jan 2016 17:16:52 +0100 To: Olaf Bergmann References: <569908E2.4060402@gmx.net> <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56991B72.5070409@gmx.net> Date: Fri, 15 Jan 2016 17:16:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="21NMx71fNxMPEFpIU980AqvqktSGBRh1K" X-Provags-ID: V03:K0:wNGHI/uZsHdh8T14klR+Y66BWu7IyisTQh1Ym5eYdH7h5joGflD rJ/aHQU56x3J6BR/T5cbIpxaatR61itoZJBwmT9zGd7TLQUkYIzok7HqGn2Byd2ltPo6Rwg s+xsDnch7ck2bPsH+rsv9NI4G7LMVVZn2ViySEKh1unBy3OOUdsjcjnoXfSv9jwS6CNzX4D fhr1I/RvL+xpgd0Wt9CuQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:8s4PHoBJPOA=:ji4CErwpm1GrAOtPqNyQDr 4iRXJYenKwMSV4PUzIKYcSdP3S7X/su0F4JurDzUmIsqnGmnIsnNMgj5CJ4shh40pRW29V5Ji nguv0wjWIhjnU3qZsZPVc9yYN+BenrBK1ZtQaHvFTGWH7UD0aBJdwAZvm09PyR85oVfLji0IW 81eACniEoD6jXRCJ4O+nFquvLWWR8oOwX68sUVDU/XtC6k4hjgRPsdCZe00LJnHL2jkkTFgF7 CXbeTz1nJemSGOn1qDLcWvpYc2R33D7JMPv3mPLeLUTLxju4UOLphAJHINcDsX2riPJfeKdKD rRa8sXjyP2H1nW12fUJUwiMB5D2IuFOUMrbNO88UdMRgNeqyCiDr1faz312kEPlWcGtmdlEJi fgavprBFcRUMrpvSNIxLbzJ3iSTkKlaVHDjSQyARRakEW6OOwpQhBjzsMg7Sm25byWXBzenCE PIk7FxWaCBGByGLxHJRKynZdZQJIB1WwWO43/UuZodY/j1XI0Dczu5qBYMfYj0Py2/vlppIUO V+ycc9M6q0n71XnhW14ZD5eUmgJx0w6SNFutuHaswbFc5uTZfF61ARz1apJt8veHwp9vypMA/ ZwH0uiW4eX0gXJwI28G9IFZuTpOw46CqgiPnqV1xNtkXSbUm37CGoJNJ6M0RN2NhMrNqk1Yui EfpCPP9/prhuevSUI78EjDvdcQMdoWECmIRnLlf/vbGkrEW+x6jubFvc3uxgFnozp6uLKjMPg nWCY0VerxQC9LS+6PPc2tM3KaD5QsQaN0cw2L4MLh6D1rHpaGp1yYHKsHug= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 16:17:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --21NMx71fNxMPEFpIU980AqvqktSGBRh1K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Olaf, On 01/15/2016 04:52 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> We are not entirely sure about the role of >> https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 >=20 > Who is "We"? We refers to the chairs. Similarly to the CWT discussion we are not even sure which group the work should go. I do, however, believe there are a number of participants who thought that object level security is something to work on. Ciao Hannes >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --21NMx71fNxMPEFpIU980AqvqktSGBRh1K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWmRtzAAoJEGhJURNOOiAtho8H/2pYrPw2t6ql+RR5OXwMj+/W mt4qTTWAynDDoIk+MnlPeVG0z75cKSgeJxFsJnYbYIYiGcceZvBKuu3p+BCCMlDC sKoD8Vx1uVgfwZ7Idr759HnElvvzkdl88Q0c30OjYPLTfjAqW04lPHKGM1G5i8kR e2oNwxIi3Zd0NSXh+tRvJPGDSssn8R2f51hXB7R+ZUAVh6nt2q47PuxxqTERclPO Iy2SODhE+/NDzkXl0XVSeBfwinEDa2fFETig50yrxxTrTaFfOGiEdln8CrnwkCmr iDL27rjY0i3nxKx11t8Yu6yMUMU77jlpcbcML2gu4glwkILHnMPrTnPQiWZRwDM= =2npp -----END PGP SIGNATURE----- --21NMx71fNxMPEFpIU980AqvqktSGBRh1K-- From nobody Fri Jan 15 08:20:55 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9071B2FA0 for ; Fri, 15 Jan 2016 08:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luenVG7IUsdQ for ; Fri, 15 Jan 2016 08:20:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3571B2FB2 for ; Fri, 15 Jan 2016 08:20:45 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lwoiq-1a4viL04C0-016RyC; Fri, 15 Jan 2016 17:20:41 +0100 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "Ace@ietf.org" References: <569908E2.4060402@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56991C56.5000404@gmx.net> Date: Fri, 15 Jan 2016 17:20:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j9iEnBLCvixJP7KTgVSdGRkIIOIQLwwcF" X-Provags-ID: V03:K0:cEHeYwwV/BUri8yXLMOZU6/44waxTtfZwTAfYL2j4KexU/uOYDd X/Pb9LuC63L8piCvarVR/XYIdDatoke7d7R4OgtVGmnHO7h+NhRXrRvvV8/0KGHYqxwNaZm cCW8vDHEyQL8Z7hAv9b1RvsOqTZFv+Ebi4xnkadE7oLCjbkoMTFLfD1tsv8AoP+kak7InRx eb27GETdssZerDWpe2+vA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GKzL2tHOTvw=:I1FCXXYFB6Tf/SYvKXqjQc Ic5dWgpEgR3N3PiPMTW7j3ECYpryOJTeoenPCjHVOUVj1s2YG+AZ8CQ7fi+TZjHmFfjS1QhjF uxcXPid8PuYDopf4CCUpeA3U9Jo0gR24KcGV27PKIPlu60HL1R4IKyLEvC4plz9bLcURRv2jL QKzyiwHL0QAXfNSahHA6+UfpZDmK3fOZPhPPgTp/Y+Dt039aRTHjZe71vOuOcGa4RihZH+iOv QF+hpFG3iJI3D4qt3yMYG30oepbz6uQ7s/ScSXTeADHhWX033pV9R6lXkhqBPMRWntxXnokLT wrc1a5T/AoURb1KwYVcwzgeYLaKuwVQiDRdm1WxV7sw9fMOy09uz0XJmpqwoYurg3zYbzBVb6 8mGs4FC5m8+u1nAi86Tznq1f7qf5TPsqOCorJsmX+LFiub2LdjjXynNNG93ul0uzA6FHhNcv2 CrKTGrdftDzmCHoThuJiS8F7KV2Oy9YueTG6/8yrvIuGxBTpV2kGRJvA1yVOWIJUvwjp/ieiQ TzPJYNXb85qu1OMh85MIdOUhXtTw1NGxfSBdATFJbRUf/YCTCbcb7oEV2+pcnQ2fubKDsv9jf 3MD/ECDRgSzT+SGkyDvcDwCxKiC/8IkU+1g1a4Uf8gvdCIsdF+IpiFPlUjzRdb2D70P9UAAEq X+M59koTYVJbNwccC2doelpsIumSGf4+/QBLHghDJ7H31gY/Eu7MxdkkWbaT9rrnM71XBR+WS o7L6mEX0lyIoUyazbot88vsh9wAJofqDi6Kh8GlL+JY06ctzb6P+AEV6POw= Archived-At: Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 16:20:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j9iEnBLCvixJP7KTgVSdGRkIIOIQLwwcF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick response, Goeran. It might be worthwhile to split the draft (as outlined below) and to submit the pieces to the relevant working groups (and most pieces seem to go to the CORE working group). Ciao Hannes On 01/15/2016 05:02 PM, G=C3=B6ran Selander wrote: > Hi Hannes, >=20 > On 2016-01-15 15:57, "Ace on behalf of Hannes Tschofenig" > wrote: >=20 >> Hi all, >> >> during the ACE WG meetings we had various talks about object security >> and as we are moving our work along in the group it would be good to >> make some plans about it. >> >> We need your feedback regarding two issues: >> >> 1) Do you believe that object security standardization work (using COS= E) >> should be done in this working group? If it shouldn't be done in this >> group which other group do you have in mind? >> >> Object security in this context refers to ways to protect messages >> conveyed over CoAP and to also include various CoAP header fields in t= he >> protection. >=20 > This work have different parts which may belong in different WGs. >=20 > 1. One part is on expanding on the motivation. A short background is > provided in >=20 > https://tools.ietf.org/html/draft-selander-ace-object-security-03#secti= on-2 >=20 > People has shown interest in making this into a more formal analysis. O= ne > draft is planned to be submitted to the CORE WG in time for next F2F > meeting. >=20 > 2. Another part is to expand on how the CoAP headers and options should= be > handled, which is currently in >=20 > https://tools.ietf.org/html/draft-selander-ace-object-security-03#secti= on-6 >=20 > This is also planned to be included in the previously mentioned draft t= o > CORE. >=20 >=20 > 3. A third part is how to wrap CoAP headers, option and payload into a > COSE object, and how to carry that COSE object in CoAP. This is the > remainder of draft-selander-ace-object-security-03, and there may be ot= her > proposals as well. I think this work belongs to CORE. >=20 >=20 > 4. A fourth part is how to indicate in the OAuth flow that object secur= ity > is going to be used as communication security protocol between Client a= nd > Resource Server. This is described in draft-seitz-ace-oauth-auth which = of > course belongs to ACE. >=20 >=20 > 5. A fifth part is how to establish the security context to use for obj= ect > security as in 5. This is addressing one of the review comments of > draft-seitz-ace-oauth-authz. A draft is planned for the next F2F meetin= g. > I think this belongs in the ACE WG. >=20 >=20 > Did I forget something? >=20 >=20 > G=C3=B6ran >=20 >=20 >=20 >=20 >> >> 2) What use cases are you interested in? >> >> 3) In various meetings Goeran presented OSCOAP, see >> https://tools.ietf.org/html/draft-selander-ace-object-security-03 >> >> We are not entirely sure about the role of >> https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 >> which was presented at the last IETF meeting. Here are the slides >> presented by Carsten: >> https://www.ietf.org/proceedings/94/slides/slides-94-ace-4.pdf >> >> The last slide contains about the difference between OSCOAP and >> draft-bergmann-ace-dcaf-cose-00. >> >> Have people reviewed the documents? What functionality offered by thes= e >> specifications do you like/dislike? Is functionality missing? >> >> Ciao >> Hannes & Kepeng >> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --j9iEnBLCvixJP7KTgVSdGRkIIOIQLwwcF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWmRxXAAoJEGhJURNOOiAtDT4H/RzBLFTIzEIlpkY7GOvBqYdR OtFd4X+rBV9YvovfUNhBzElA5lP18RhsEtSUpTt+6/msZMGD0WuVuglFcEjLGJXF kensQv9OoNSXRN5TfmbmHt56m08e3/bkTt5OJ/0lkoXDT3fLDuR/g1KFqESuVr5s JLAQ/stC3IFuCAQpkD6E0dzFTjGWEX/DgoGZtKKFkX/k4I7c3TqVHLkM40X5Nezj CXTGNmDl9rTgia0A4YgzUkSoyh9t4jhARSZ0G4v1R/XHLwLYsdWRf/6YzPl2BJ5W JrW0pPcIpbypc18hc+l8oCAXe9cEJdkxX2wHytqTBzYF+Raa2409hUr97O8BtKc= =R7K2 -----END PGP SIGNATURE----- --j9iEnBLCvixJP7KTgVSdGRkIIOIQLwwcF-- From nobody Fri Jan 15 08:21:36 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E461B2FA6 for ; Fri, 15 Jan 2016 08:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10ww6h9Nsnvh for ; Fri, 15 Jan 2016 08:21:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEDA1B2FA9 for ; Fri, 15 Jan 2016 08:21:32 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LabZr-1Zt3Jk46Rj-00mJkX; Fri, 15 Jan 2016 17:21:24 +0100 To: Olaf Bergmann References: <569908E2.4060402@gmx.net> <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56991C82.8050902@gmx.net> Date: Fri, 15 Jan 2016 17:21:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xh94Ws9VkmFefa0BiiFLXxx2PkWmN6GDW" X-Provags-ID: V03:K0:tILISbwmYSbkmgeQLIg/ZijFdJ7YZ44QDb0lH7Mup+2USEMBaGp /5zrIucpHFnn8kpeDR2t0x4pwyTPckzEfZzr2W6OMKZnhMnQyugThZzQmj2wX40IA5GOYDT zF8TYHoZmb1rvlsitcVXIKd1Tb3k+dCdKK6D5a85QMHKqG875OonjTxs4Oxd1Ty2WfzPA17 cIbNP0ZD1lHb42BepYi3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:tI5nR1HvmZM=:nHdJkIpJ9tW50dO2eNIgZG G/0pY4IkvPdho+b4xdcCUqxH2xFze5uslAnDjLbNqB8n4x+W/kKJ/s67L7Wkdp665imvEDmC3 1f/l7Np9j81GYxiV9VwX4yYuakXNlEhdRuXMaMieofLaW0da2ICgO0QPLKzZQ/chSLyOoUH0v 3rTR5keGZJoAuo0pQSY3kH7J0BjsfYkrUo6m0aRFBlSpJsTKj2x6VY+AOIs4KV2f5ZLhf1QVx 0Z8DAL0HAkXX31dOBKmKBCTs0Dwa6QWFocIN0b0SNwnp/USYgs3Hrkbf+HEhlvDOwaPL/4RQc h88hxox+v3rt/J1Hamg2gmmrgzYxyA2PG5VudRy8YzFrBaIeyCLD0dMracZRm8doryGUQHwBf LtIIhnTUO7Fuer/tVJcLV7o7J+FyxGnkEjoyIroBIs/iGngv3BQ8fbvBCWe891y2yfKFRW+os jyP3Hz8nE0NYm2oByWqLJt3V3/oTqcULq+VTBmx9jckzxz+F5nQZkqb3yejZJkU85dgL7C9JY HRxQHMDHanRjU9CMDQzJbzHPLfLpPhgi1O9vdSy21Tkwc8G7zb8hrFKVCwMiP1gepSVlmmENu 7zGFFANScYzYAizv5DaRlELLiEvJ9Bdrw8tUdHsmbegZVNCZzit0HmdBJxRJeHrtxXqD2nePH 7VLYIcMNJ8NlhCfzK1uSnNmHsEvJyBuj4qUZfwTo+hUTSbZv3PvghbY3fy2IE4JsKTxeOt78P H83T3pE2kBEZcs82IszOkovFmrMIZDTJCyLyJEN61edyhry/MBsp2+vdRGw= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 16:21:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xh94Ws9VkmFefa0BiiFLXxx2PkWmN6GDW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Asking you back: What do you see the role of your document in context of OSCON? Ciao Hannes On 01/15/2016 04:52 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> We are not entirely sure about the role of >> https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 >=20 > Who is "We"? >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --Xh94Ws9VkmFefa0BiiFLXxx2PkWmN6GDW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWmRyDAAoJEGhJURNOOiAt1toH/3Vtbn0T6sisia0C6SMTCXMU 3vkMNKiuXyDZVTqBYmCnpbIiedrkR3t4XNsrcReIXiNqjHW9I5yzT4pooMt9I0iS BJEHbW2Y4N4q2dplKWDcNVu1ukRYpJQgSFgzc35+nQ+MEzX8kmPrjxCMKFzK8lQp SjYNG5b1doHTlCfQ1UAWfrqZ/1E+bgrRhL8v6NjQ9GK3oMJIR1LgFs2VDYkalw+s csRDuUo2CXZMjKrT09oCBr1knxR3U0+klz/e+trafygr5+mQdiUro1+2h8X7zKmH CkONPh9jQvF04FPwbdRflPH/dCIeOSJ1M8ud0uRb3RMj1yQt/JONsfV/U29kz50= =vhkj -----END PGP SIGNATURE----- --Xh94Ws9VkmFefa0BiiFLXxx2PkWmN6GDW-- From nobody Fri Jan 15 22:38:15 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF21A0162 for ; Fri, 15 Jan 2016 22:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HALl_ho0mi5B for ; Fri, 15 Jan 2016 22:38:11 -0800 (PST) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id 009CA1A015F for ; Fri, 15 Jan 2016 22:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1452926289; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=6C1AXibRv7CL1AQ6r7v61ZY8jZYfpGcNScnSnUjjvj0=; b=phsk90tPdjrZB3q6A4Wk5aaOLd5V3SuyhbJ7tplsoyDGzgX7hh/9LuLI4rWkKmI6trFRD8TqFuTyWpUTEegJuOEvTf1ljZsV895eAdNRJtSjBtHL4qxmf0UKMHIIBwgyxMZcThLpoNAGVaOllMFdfXoMnOYsAWs9ActrvQoeEcQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R731e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07405; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_----4SScr3J_1452926274; Received: from 10.22.46.235(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sat, 16 Jan 2016 14:38:00 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 16 Jan 2016 14:37:55 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Doodle for ACE virtual interim meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3535799882_368194" Archived-At: Cc: Hannes Tschofenig , Hannes Tschofenig , Kathleen Moriarty , Stephen Farrell Subject: [Ace] Doodle for ACE virtual interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 06:38:13 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3535799882_368194 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi all, To speed up our progress, Hannes and I plan to have a virtual interim meeting in the end of Feb or early of March. According to our discussion results on the virtual interim meeting, editors can make updates for the drafts before our next F2F meeting in Apr. We proposed four options for the meeting time: 1. 24th Feb, Wednesday, GMT 14:00 ~ 15:00. 2. 25th Feb, Thursday, GMT 14:00 ~ 15:00. 3. 2nd Mar, Wednesday, GMT 14:00 ~ 15:00. 4. 3rd Mar, Thursday, GMT 14:00 ~ 15:00. Please indicate your available time from the doodle poll: http://doodle.com/poll/gcswyngw9hr7573e The initial agenda could be: 1. ACE Actors: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ 2. ACE Oauth Solution: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ 3. AOB. If you have any additions, please let us know. Thanks, Kind Regards Kepeng & Hannes --B_3535799882_368194 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi all,

To speed up our progress, Hannes and I plan to have a virtual interim meeti= ng in the end of Feb or early of March.

According t= o our discussion results on the virtual interim meeting, editors can make up= dates for the drafts before our next F2F meeting in Apr.

We proposed four options for the meeting time:
1. 24th Feb, = Wednesday, GMT 14:00 ~ 15:00.
2. 25th Feb, Thursday, GMT 14:00 ~ 1= 5:00.
3. 2nd Mar, Wednesday, GMT 14:00 ~ 15:00.
4. 3rd M= ar, Thursday, GMT 14:00 ~ 15:00.

Please indicate yo= ur available time from the doodle poll:

The initial agenda could be:
1. ACE Actors:
=
2. ACE Oauth= Solution:


Kind Regards
Kepeng & Hannes

--B_3535799882_368194-- From nobody Mon Jan 18 05:19:49 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC521B351F for ; Mon, 18 Jan 2016 05:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyKu_1bQICpn for ; Mon, 18 Jan 2016 05:19:47 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9C81B3543 for ; Mon, 18 Jan 2016 05:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u0IDJhdk008225; Mon, 18 Jan 2016 14:19:43 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:211:22ff:fedd:aa18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3pkYcb1TNxz31gZ; Mon, 18 Jan 2016 14:19:43 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <569908E2.4060402@gmx.net> <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> <56991B72.5070409@gmx.net> Date: Mon, 18 Jan 2016 14:19:42 +0100 In-Reply-To: <56991B72.5070409@gmx.net> (Hannes Tschofenig's message of "Fri, 15 Jan 2016 17:16:50 +0100") Message-ID: <874mebrpn5.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 13:19:49 -0000 Hannes Tschofenig writes: > Hi Olaf, > > On 01/15/2016 04:52 PM, Olaf Bergmann wrote: >> Hannes Tschofenig writes: >>=20 >>> We are not entirely sure about the role of >>> https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 Since there are a several open issues that have been raised in the reviews and also the COSE specification has evolved, I will need to update that document. It also contains some text on application level security of CoAP messages which I could split out and contribute to a more general document if need be (see below). > Similarly to the CWT discussion we are not even sure which group the > work should go. I do, however, believe there are a number of > participants who thought that object level security is something to work > on. It definitely is. IMO, the question how to secure CoAP messages on the application level is something that belongs to CORE (in cooperation with COSE, obviously) whereas its use in the context of authorization is something that should be done in ACE. Gr=C3=BC=C3=9Fe Olaf From nobody Mon Jan 18 06:50:18 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909D71B37D0 for ; Mon, 18 Jan 2016 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brd1ZWRO_H72 for ; Mon, 18 Jan 2016 06:50:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2D41B37CC for ; Mon, 18 Jan 2016 06:50:12 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMTEM-1aE0Oy0D3m-008J9R for ; Mon, 18 Jan 2016 15:50:10 +0100 To: "Ace@ietf.org" References: <569618C9.50904@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <569CFBA0.5010805@gmx.net> Date: Mon, 18 Jan 2016 15:50:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569618C9.50904@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uEeoT5QooRAkfaGMhE7His7Vax422X719" X-Provags-ID: V03:K0:7QY/quYp1d7SPrUCNWZb2zKtHzr6GbiNlXKNKtHGJM8k2j7nZc/ dyPZLy3nmu26xn7K1VnQd9PxHmYVSVjp1ItCZ4Ip8wA0J3SWyzxqx8rgcWVEL5E0F1PLc60 ewAVyglBSTAlqewSAcaCbe8Bz9+GRIBBQzdx9JAZfB33xyKDa46jXMJcrH9cFC8uisL180H GsE+uaQAYgU0HJxiukzHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:UXlK+Am7xE4=:Vn9dAezwRRgq2c7YEOnOvG qWM/t4j3D9AKBsiMGBtoQunWHa6LS7MviGTRc73O6zg/Ju3PG3Sc+eNQICoE/Efz8Y0wwV9K2 7H/c1cP1JdofeaXo5rMo5UVFjkzs33ui/Pw1O4nq905CcW1IJY/QJLCP3TSci5MI8AGIDVetX CcVd5NjdK9p8vc1gHOXTYrtBcs/BYLiZce359RdGIcr3H3HXJUGth3KsoKHM6IDdnGILAI4Du 3NzGPF7OGzd4Q0+O6Q9IuFexJS3acekrjF6v99nx5gzHWkSiPPej2BltUCT459+2WBZzLE75e guA47Vh/yZdymjTgYu+HTX0qomSU0UthDcmJgG7yXWsSm43bT6vppTc/9D53TZt3l1273/P0H Ag59ofINs7zIrgYlql35colVtEjdQ++gsr5+Q/cTJh29J4VC2h4Nny1awRFjHM77iGUmsl9ty 5Kd7az1cba36o/JT9XHq32dJRePCJq+cF1LK5Fl0KDwlSxpC/kyY/1G4KFKlaITIdl1MsJ/+l qHFCIAywg9yt8b37jDDWSDMnGiglzLrlNe/aZHuOT6yEw3cTR+x9s+DNaywPobGJEwoWD3Kk0 N5CnKu5Lp933SLhvGE0bgCbI2YulZwiRGxKjVDoAlDkgMh5zeqWYPHa4wh2GBFb2Y/fLPTf2A 6ai/F4oj5LxfiaqxbUi1aTpOPi0/bA1Qhb2AEXn7wVxebq11eaukMNwuV8GDBvnStX9IcI3/i X7NcF5OgJfFuHeusIKHUcEONl4mPlfBguZeXdWZp2fBQ9fg0MMugbPowDLw= Archived-At: Subject: Re: [Ace] ACE Status Update and Planning X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 14:50:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uEeoT5QooRAkfaGMhE7His7Vax422X719 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So far, we haven't received any responses. For planning purposes it would be good to get an answer to my questions below: >=20 > QUESTION: Are you planning to attend the upcoming IETF meeting (and the= > ACE meeting in particular)?=20 >=20 > QUESTION: Are you interested in participating at the hackathon at the > upcoming IETF meeting to work on ACE-related topics?=20 >=20 > QUESTION: Do you do have resources to contribute to > implementation/prototyping efforts in the next few months? (Drop us a > private mail) >=20 > QUESTION: Are you planning to attend the OAuth security workshop in Jul= y? > (Drop us a private mail) > Ciao Hannes & Kepeng --uEeoT5QooRAkfaGMhE7His7Vax422X719 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWnPugAAoJEGhJURNOOiAtO2IIAJrpy4ZxodSoGi+aJ4nj8MNX //tVTFcT/8ufxU/eJ16D/1vwNtxml7c4lf9Hm8uGerY1COGTQfbi+UU0329ry1bs kpDzfqp3Ds6RYoq7KHFwh8ofp4pijDp/Wy2cZ3LIHXXIUjyIeFcMlbKw0lP3uKHm Y/hYyF3SWII7AtUAvexvkPmr0em7uZhRSpJzSfiimp+iF3jsNZASYN3FCknBr2nR dmcNEXF57jlA/xJlpzs0qcHdyVHnhvGc3ABDx0expnrve7WGo9AE5marK+HbEulv Sg7Jie3wPG7s3YkfSSGNAp4/Re+AI2WzGnrQGn1g9YOOb41D/s+Cb+JHTAcc48s= =gDa5 -----END PGP SIGNATURE----- --uEeoT5QooRAkfaGMhE7His7Vax422X719-- From nobody Mon Jan 18 06:54:26 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4A1B37E8 for ; Mon, 18 Jan 2016 06:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2M_JYvn4Wk3 for ; Mon, 18 Jan 2016 06:54:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EC01B37E7 for ; Mon, 18 Jan 2016 06:54:22 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEFqW-1aNJrY1Vma-00FR21; Mon, 18 Jan 2016 15:54:12 +0100 To: Olaf Bergmann References: <569908E2.4060402@gmx.net> <871t9ivnzb.fsf@aung.informatik.uni-bremen.de> <56991B72.5070409@gmx.net> <874mebrpn5.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <569CFC93.1090508@gmx.net> Date: Mon, 18 Jan 2016 15:54:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <874mebrpn5.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PTfgbjqPFDG6cE5BG1ihbcoqH8t9VbW94" X-Provags-ID: V03:K0:8yaKkxizhk6C8C6pAgn/xeDUuYYyDQUmdUiJ/Pq5CCdyo7PDoCM mrX0R3WalDlhYwRopOH6qK5uADHqsaLNTF1JzTlo0YW1kKFmakeynIfsFa2TcpDXe/o5KQQ GN99ndzS4s+QjyDGRop9CAiLP+Ckvhqi4a49W3qGj0FsV0UW74SmOvIg7lEDl48LxRJZHG+ 8no+tqN9vie6ZwCLAGftQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:fOKvjZucyiY=:yeORH7EZIl1FYevxucfPZw wX3rLNYZfcJvnhjlV3hFpVx5j1d8LZJNGHKMADpjUhRmVyfiS4e5MPLfNQt5VJ+XioSnO+DGE GFBHMZLGlMWyi6lopa+cMNIW8RLCnMKiYZcDtBGcL1RWeiqX4u9morDKzdWfkS5/hfqPwpiCJ gZEjw2vFu4+sasZad1EhANnsMczNQkdJkhWqsNAafejcT63iwzTpVZjzRs+oe+JHdq5JHNCAH IyAurfy7S1q6RJ0SUt6DoxHb/1kZ61aVhHDt/OQ192YjhmzMvj98AO9coueM1gLmWknIc2AWx FZDgSHmFSgLoxgMdAibkoXGg9b0DdKWQt6OIBFNzogbWKywXdr2dMtIJzcyyy44A4GVgQjhnS GHcgFOrF+BDNxwP93M43dF3WSeyxfIiS9QS7teoAlXyHXFchwX5veZA3DFbtYkoewGdHdxp6Y e73k7dDc8Qd8vpCm9B0eZ8kzOt7fjSWHniUZOYXiCIhV16Ndj+JGJkUSyF2jIyzIaRdKNYcoT iL96kqZ0xEzWoCUBIGM7K4Ajgvnvq9FeS9dmgU9G7kL9ZWMTcsS8uBq7/qDtEvM2gdT1YKlox AFhCvbVYs5uQ1WEC7CwFUOPLvSxzo/FhiAwg14ZxqgIkILpK0uqXrOvjY/aEpvKmvFbGBhm4H /Cux9bxxTcEBjdeiH/Y32sUTuwyRAwUR876rwCkWgativG43owj4ofBmUWoV6KQFRiq7aDywi DBDv52d2U4c7UkGxKiSeBmZFLJ5dz56fPUmExvPSpGVBusAAxTIVnQs5RCk= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Object Security Work in ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 14:54:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PTfgbjqPFDG6cE5BG1ihbcoqH8t9VbW94 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Olaf, thanks for the response. The response from you and from Goeran make it more clear that this work mostly belongs to the CORE working group (which Kepeng and I previously didn't realize). We encourage both of you to update the drafts and to submit them to the CORE working group so that the CORE WG chairs can ask the group for their feedback. Ciao Hannes On 01/18/2016 02:19 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> Hi Olaf, >> >> On 01/15/2016 04:52 PM, Olaf Bergmann wrote: >>> Hannes Tschofenig writes: >>> >>>> We are not entirely sure about the role of >>>> https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 >=20 > Since there are a several open issues that have been raised in the > reviews and also the COSE specification has evolved, I will need to > update that document. It also contains some text on application level > security of CoAP messages which I could split out and contribute to a > more general document if need be (see below). >=20 >> Similarly to the CWT discussion we are not even sure which group the >> work should go. I do, however, believe there are a number of >> participants who thought that object level security is something to wo= rk >> on. >=20 > It definitely is. IMO, the question how to secure CoAP messages on the > application level is something that belongs to CORE (in cooperation wit= h > COSE, obviously) whereas its use in the context of authorization is > something that should be done in ACE. >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 --PTfgbjqPFDG6cE5BG1ihbcoqH8t9VbW94 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWnPyTAAoJEGhJURNOOiAt2vcIAJR69j+q5y5pK+fteKepLos9 WPIjc+9Of6OCh4yTVmf1bm1rzzk25tzKDEXLQV44x/at3LtIxRmKvqbHXUu4WUei iG2I9bNOXh5xWVV13rNZBDfYfoPQegnBkdqGW1Kg2mwv3BdBCQKwnwCMoTGGiofC Dd3uYH/97TrMuW4CSaaQ+v46C9a4vH2lrsDT5L6PS+LLNG+3u//FAXLLAu+Bib6N DOKsHZO1syfDX39tqY2RQioVq7QcqmShX6YTKSwGNty6Mq32Pvh8HzI4pBEtevTV hvdd9Et4PBSizAH6I3op6RB47nIFRuXl5ctUnbpB4UvLFS4e9p+GAivo+Iho0zU= =NKKJ -----END PGP SIGNATURE----- --PTfgbjqPFDG6cE5BG1ihbcoqH8t9VbW94-- From nobody Thu Jan 21 07:16:49 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945E61B31C9 for ; Thu, 21 Jan 2016 07:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldMPT_Hmz0DS for ; Thu, 21 Jan 2016 07:16:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A081B31CE for ; Thu, 21 Jan 2016 07:16:43 -0800 (PST) Received: from [192.168.10.141] ([213.235.249.182]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MgHHO-1ajpQr2KTG-00Nimg; Thu, 21 Jan 2016 16:16:35 +0100 To: Rafa Marin Lopez , Renzo Navas References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56A0F652.1050006@gmx.net> Date: Thu, 21 Jan 2016 16:16:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ij0FGrsE2ILxBXwU0Dfei4RcggbRVKhsn" X-Provags-ID: V03:K0:xfmm1EGMi40sz7yDtUSFPFy7v7XnPn4VZNJvP4gUUlW6e4diNsi AmSIhAQicGyM4MGVAdH+UFhkKxmjG9W7bfPN00Psl79BOXJr9x1z+2YFuAQO87TrpaW+Mbw l2v10dghQUyv+2Klj0wsUocQ8IsUumS7nCG56BqqrTq1dU56pkx8tTMkca3UIx9P90+4lXg aw2Cna14mCQWs/SOCWMVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:lRtt7XiecI0=:dJYk+HtKLcPszRvPeoQbk6 QTNvPCwxJK/UUcmufhxgs+8B/j3a03LSSsqyiQyriMqgyqYnNdvrRTcOW8ob+dcZL7LnDUAqw AJBHPUK4a1nhio1Cvis/ZbBJdg1PRPoHrwQ4qsGYIbza5NTv/FinhTIwHkvbAPYea7xwzFlqZ lDcrgxeF7AY4wlDhPpqiRVWDFbjn0dqqz8dsUGvJ8HdCOIv608UsJJlwxVpImxLNM0L5c+hks KWeRogVs5aXRAqoRbmzN05QdmjP1ad+XnA92v8g38sERsy6deKGiqeoswWZOGTFOWJHqh9vPx VI9poZybwMBlkw6FE2NKalHx7AWe4KW2ysE1WUcPAb9AP5v+C1eTdyXeltPihajAqpD9s3uDn V77Y4SifWROXp9FFT2oon3B/m4VpC3Xnh/ResrPiQhMNTa8aDAVFyc3o89xAmHGroWd3zSdiM sgdBnkbTEiulWG4TPswtyF4MkbWIttri+OmlYE5imeIvixpCdwqg2mXHDl6iBIHtQ0URsJtUC rsGucl25VQC1agC92eBIC0xtbBnmJ0sU1Rp+wnG/VceXz+M4tYIhFFzL4jpay0USa0yvWI4Ld Ft4cLhQdrRc2qfS6ckqP77kfUGiBLJ0mOB+6VfzujBUUXoqyhfWjchfMDJTAajwWwHWkFsZ/o kwEilMgmRuIKy9cRp5+NYiTV9BgapN3jRa3BEgGGwNvfIPw2T8BeiWtmezud5wDIPR5/djksu bhXkYsXhhcSZlUx4XyjHvI5OrIAIim4KowmuHJE3WlRwPpfac0a016f8jGw= Archived-At: Cc: ace Subject: [Ace] Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 15:16:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ij0FGrsE2ILxBXwU0Dfei4RcggbRVKhsn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Renzo, Hi all, thanks for your review comment since you raise a bigger issue. The review feedback was recorded as issue#12 at https://github.com/LudwigSeitz/ace-oauth/issues/12 You are asking what our requirements for the Resource Server (RS) are with regard to the availability of time information (and the accuracy of it). Our solution building blocks currently require time information, such as certificates and access tokens. In your email write-up, see http://www.ietf.org/mail-archive/web/ace/current/msg01554.html, you correctly pointed out that there is a relationship with the validity of the authorization information and with a potential revocation mechanism. Before we start working on solutions I would like to get a sense of the group what the views are. For resource servers do you consider to incorporate a real-time clock and a protocol mechanism that obtains time information? Not having time information at the RS will have the following impact: * The RS somehow has to get information about access tokens where permissions have changed, where the access tokens have been revoked or have otherwise been invalidated since the tokens do not contain validity information. * Time-related information in certificates cannot be checked. In many situations we will have a tradeoff between the availability of time information and the required communication overhead for interacting with an authorization server to obtain up-to-date information about the validity of the credentials. What does the group think? Ciao Hannes On 11/19/2015 10:19 AM, Rafa Marin Lopez wrote: > Hi Renzo: >=20 > I agree with you that if we consider the distribution of a symmetric ke= y between three parties the literature is full of very concise and securi= ty proven protocols.=20 >=20 > Please count on me if some help is required in this area. >=20 > Best Regards.=20 >=20 >=20 >> El 13 nov 2015, a las 17:30, Renzo Navas escribi= =C3=B3: >> >> Good Evening ACE ML, >> >> Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for easy= >> to read doc) I was very interested by the PoP token that offers an >> authenticated fresh key to be used for further secure the comm., >> but I saw a very strong requirement for the RS to have a Time Sync. me= chanism. >> I preview the objective of my mail, is to raise the question: >> >> * Do we want to have a strong requirement for the constrained device >> (RS) on an AA Architecture to have a Time Synchronization mechanism? >> * Are we interested on offering non-time -nonce- based solution for an= >> OAuth PoP Token approach (for example when the token does not expire)?= >> >> >> (those interested on those concerns can read the rest of the mail, >> that is rather long) >> >> Regards >> >> ------------------------------------------------------- >> >> (Long version) >> >> I've been working lately on the Authenticated Key Establishment >> problem (The are two very good reference books [1][2]), focusing on >> solutions with a Trusted Third Party, Symmetric Crypto, and not using >> Time-stamps but Nonces (To avoid having to deal with time >> synchronization).I have no strong Crypto background. >> >> First I want to thank the authors of draft-seitz-ace-oauth-authz-00 , >> very enlightening for the oauth neophytes. >> I'm mostly interested on the authentication problem (auth. key >> establishment), so the Proof-of-Possesion Token is a great >> tool/concept, I took the time to read >> draft-ietf-oauth-pop-architecture-05 and >> draft-ietf-oauth-pop-key-distribution-02 to try to have all the >> background possible. >> >> So from the Authenticated key establishment mechanism point of view a >> new fresh key between C and RS obtained by means of a PoP Token >> mechanism -I think- will be similar to a Denning-Sacco shared key >> protocol ( http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.ht= ml >> . Client is A, AS is S, and RS is B), with the difference that the PoP= >> Token Timestamp have a start and end value that will make the >> "mutiplicity attack" of Denning-Sacco limited on time. >> >> My concern is that we will always need Time sync on the RS, that some >> (most) times will be the constrained node (I think that the Client >> does not need to be Time-aware), is that a MUST requirement? So >> no-time aware devices will not be able to use OAuth PoP Token (or will= >> have to use token introspection, a good fallback solution btw) >> >> Will be of interest offering a PoP Token generation and transport >> mechanisms that offers an authenticated fresh key without the need of= >> Time-awarenness at the RS? >> >> Time awareness at the RS offers great advantages, and maybe also Time >> is always needed in all authorization solutions (to make easy token >> expiration and freshness claims). >> >> But I'm thinking about nonce-based authenticated key establishment. Of= >> course without time information embedded on the token, token >> expiration will be more difficult: >> * we will need token introspection, or >> * the AS will contact the RS to revoke tokens, or >> * we will need on a non-time based solution for revocation that does >> not involve the AS, for example: a pop token/key is valid for use only= >> for one (or N) Resource Requests (of course if the response message >> get lost we are screwed...) >> >> >> So maybe we cannot avoid to have Time-awareness at the RS, for >> Authorization purposes.. >> But for Authentication certainly we can avoid Time, the three most >> recommended by [2] nonce-based protocols are: >> * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven >> provably secure on the strongest model to test auth. key establishment= >> protocols ] [3] >> * Yahalom [a modified version has been proven secure on a weaker model= >> -bellare rogway- than 3PKD] [4] >> * Boyd [Key Agreement: RS, C and AS contribute inputs to generate the >> key] [proof idem yahalom ][5] >> >> The message flows on that three of protocols do not respect OAuth >> flows (I attach an image with the high level message flows, A is the >> initiator always), so that take us apart a bit from OAuth... >> >> This mail is starting to get long so I will try to conclude it, but >> hopefully raise the question: >> >> >> ** Are we interested on offering non-time -nonce- based solution for >> an OAuth PoP Token approach (for example when the token does not >> expire)**? >> >> >> >> If NO, I guess that will need token introspection for RS that cannot >> support time (That mechanism will map to other authenticated key >> establishment protocol and not Denning-Sacco-based ) >> >> if YES, are we interested in adapting a nonce-based auth. key >> establishment protocol to OAuth PoP Token? >> >> >> I hope this questions are useful, >> >> Best regards >> >> Renzo >> >> >> >> [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key >> Establishment and Authentication. Springer-Verlag New York, Inc., >> Secaucus, NJ, USA. >> [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.). >> Springer Publishing Company, Incorporated. >> >> [3] 3PKD - http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_Ma= y_2005.pdf >> [4] Yahalom - https://eprint.iacr.org/2007/188.pdf >> [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf >> __________________________________= _____________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --Ij0FGrsE2ILxBXwU0Dfei4RcggbRVKhsn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWoPZSAAoJEGhJURNOOiAt9qsIAKaYT/vSlS2EJMoJMCvZqwdm 1e8x4l5MQsJCsfMYIvsNnleUv3S56735Lt6hf70ehAqDKy2annuCcqJb921gwzcR XEUbj4rGDsArzQRNXJknoe0qnpuZKySVeNKpUK4CUDnUsBL04V/otxXNt5AO0/z9 5A3tLO6/j3vCB+VtCX/PPEILFdvBVj5NIMKL4kFuqkr7CyaMXIbk/EAOd+YXevnC zuq9BSAL7wolkjvHSB8vG2cowlSSOiX8aabgwSR4RjTNgBW9B6UtWpdw1R+K9y2q aLmsDvi6JWrBUf8GGP6aOcVkgD1BSKAm47VYdXqgHg/vzafRXsEs+Q/TgUuXYf8= =9dVx -----END PGP SIGNATURE----- --Ij0FGrsE2ILxBXwU0Dfei4RcggbRVKhsn-- From nobody Thu Jan 21 09:40:49 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D151B3356 for ; Thu, 21 Jan 2016 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnwTF-T_4pLJ for ; Thu, 21 Jan 2016 09:40:44 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BAA1A1B29 for ; Thu, 21 Jan 2016 09:40:43 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-52-56a1181929a1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.B2.04914.91811A65; Thu, 21 Jan 2016 18:40:42 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.151]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 18:40:41 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Rafa Marin Lopez , Renzo Navas Thread-Topic: [Ace] Time Requirements for Constrained Devices Thread-Index: AQHRVF7CD1Dc53FEtUSqY7x3VJH8Vp8GPPkA Date: Thu, 21 Jan 2016 17:40:41 +0000 Message-ID: References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> In-Reply-To: <56A0F652.1050006@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <860EED4364508240996756D6E852A3ED@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2J7lK6UxMIwg/5jXBbfv/UwWyzdeY/V YsOPH6wWT990MDqweOycdZfdY/Gm/WweS5b8ZPI497KNJYAlissmJTUnsyy1SN8ugStjSdsf poJv6RV/tmY1MC5I7WLk5JAQMJGYeX4bM4QtJnHh3nq2LkYuDiGBw4wSV4++YYZwljBK3Jr+ jxWkik3AReJBwyMmEFtEoFTi864GIJuDgxmo+945LhBTWMBGoqGfG6LCVmLpwv/MELaRxPQn +9lBbBYBVYmOfy/ZQcp5BSwkbrRlQ2yaxShxsOkxG0gNp4C6xIxbe8F6GYGmfz+1Bmwrs4C4 xK0n85kgbhaQWLLnPNT9ohIvH0NcKSqgJ7H7ySlGiLiixNXpy6Gu1JRYv0sfYoy1xKN3U6FG KkpM6X4IdhqvgKDEyZlPWCYwSsxCsm0WQvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kbFealFm cnFxfp5eXmrJJkZgnB7c8lt3B+Pq146HGAU4GJV4eA1uzg8TYk0sK67MPcQowcGsJMLby78w TIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvskxjmJBAemJJanZqakFqEUyWiYNTqoFx2kKN2/ac LbKFShn/dh/NZHz5rX9fnC5HoNdnTZ62hz72KmwXTsizTODnzxW4fbbr4NG4ZMWFLUEZicZz uRZvWPVlvWaDP9Oi5SvmvkhbmbbVvFg+TSQku0f+s+6ezQ8XXH+bbvzNMevDzQn/ZQ8mFUw+ HLt40sOTixLiv865wcrx74CNupKxEktxRqKhFnNRcSIAFpdFPc8CAAA= Archived-At: Cc: ace Subject: Re: [Ace] Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:40:47 -0000 SGkgSGFubmVzLA0KDQpHb29kIGRpc2N1c3Npb24gaW5wdXQsIHNvbWUgY29tbWVudHM6DQoNCllv dSB3cml0ZSBjZXJ0aWZpY2F0ZXMsIGJ1dCBDb0FQIGFsc28gc3VwcG9ydCByYXcgcHVibGljIGtl eXMgYW5kDQpwcmUtc2hhcmVkIGtleXMuIEZvciB0aGVzZSBjYXNlcyB0aGVyZSBpcyBub3QgbmVj ZXNzYXJpbHkgdGltZSByZWxhdGVkDQppbmZvcm1hdGlvbiwgaXMgdGhlcmU/DQoNCklmIHRoZSB1 c2UgY2FzZSBkb2VzIG5vdCBhbGxvdyB0aGUgUlMgdG8gYmUgb25saW5lIHdpdGggQVMgb3IgdGlt ZSBzZXJ2ZXINCmF0IGFsbCB0aW1lcyAoZm9yIHJlYXNvbnMgb2YgY29ubmVjdGl2aXR5IHN1Y2gg YXMgY29udGFpbmVyIHVzZSBjYXNlIGV0Yy4sDQpvciBmb3IgcmVhc29ucyBvZiBjb21tdW5pY2F0 aW9uIGJ1ZGdldCkgdGhlbiB5b3UgYXJlIHJpZ2h0IHRoYXQgaXQgbWF5IG5vdA0KYmUgcG9zc2li bGUgdG8gdmVyaWZ5IGNoYW5nZSBvZiBwZXJtaXNzaW9ucyBhbmQgcmV2b2thdGlvbi4NCg0KQnV0 IHN0aWxsIGl0IG1heSBiZSBwb3NzaWJsZSBmb3IgdGhlIFJTIHRvOg0KLSBpbnZhbGlkYXRlIHNo b3J0IGxpdmVkIGFjY2VzcyB0b2tlbnMgKGNvdW50aW5nIGRvd24gdXNpbmcgaW50ZXJuYWwgY2xv Y2spDQotIHZlcmlmeSB0aGF0IGFjY2VzcyB0b2tlbnMgYXJlIG5vdCByZXBsYXllZCAodXNpbmcg bm9uY2Ugb3Igc2VxdWVuY2UNCm51bWJlcnMpDQp3aGljaCBpcyBzdWZmaWNpZW50IGluIHRlcm1z IG9mIHRpbWVseSBhdXRob3JpemF0aW9uIGluIHNvbWUgY2FzZXMuDQoNCkZ1cnRoZXJtb3JlIGEg Y2xpZW50IG1heSBoYXZlIGFjY2VzcyB0byB0aGUgQVMgZXZlbiBpZiB0aGUgUlMgZG9lc27igJl0 LCBhbmQNCnRocm91Z2ggYSBuZXcgYWNjZXNzIHRva2VuIHByb3ZpZGUgZnJlc2ggaW5mb3JtYXRp b24gdG8gdGhlIFJTLiAoVGhlIFJTDQp3b3VsZCBpbiB0aGlzIGNhc2Ugbm90IGtub3cgdGhhdCBh biBhY2Nlc3MgdG9rZW4gaXMgcmVjZW50LCBidXQgaW4gY2FzZSBvZg0Kc2VxdWVuY2UgbnVtYmVy cyB0aGF0IGl0IGlzIG1vcmUgcmVjZW50IHRoYW4gcHJldmlvdXMuKQ0KDQpJIHRoaW5rIHdlIHNo b3VsZCBzdXBwb3J0IGRlcGxveW1lbnRzIHdoaWNoIGRvZXMgbm90IHJlcXVpcmUgUlMgdG8ga2Vl cA0KZXh0ZXJuYWwgdGltZSwgYW5kIGFjY2VwdCB0aGF0IHRob3NlIGRlcGxveW1lbnRzIHdpbGwg bm90IGJlIGFibGUgdG8NCnN1cHBvcnQgaW1tZWRpYXRlIHJldm9jYXRpb24uDQoNCg0KR8O2cmFu DQoNCg0KDQpPbiAyMDE2LTAxLTIxIDE2OjE2LCAiQWNlIG9uIGJlaGFsZiBvZiBIYW5uZXMgVHNj aG9mZW5pZyINCjxhY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaGFubmVzLnRzY2hv ZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj5IaSBSZW56bywgSGkgYWxsLA0KPg0KPnRoYW5rcyBm b3IgeW91ciByZXZpZXcgY29tbWVudCBzaW5jZSB5b3UgcmFpc2UgYSBiaWdnZXIgaXNzdWUuIFRo ZQ0KPnJldmlldyBmZWVkYmFjayB3YXMgcmVjb3JkZWQgYXMgaXNzdWUjMTIgYXQNCj5odHRwczov L2dpdGh1Yi5jb20vTHVkd2lnU2VpdHovYWNlLW9hdXRoL2lzc3Vlcy8xMg0KPg0KPllvdSBhcmUg YXNraW5nIHdoYXQgb3VyIHJlcXVpcmVtZW50cyBmb3IgdGhlIFJlc291cmNlIFNlcnZlciAoUlMp IGFyZQ0KPndpdGggcmVnYXJkIHRvIHRoZSBhdmFpbGFiaWxpdHkgb2YgdGltZSBpbmZvcm1hdGlv biAoYW5kIHRoZSBhY2N1cmFjeSBvZg0KPml0KS4gT3VyIHNvbHV0aW9uIGJ1aWxkaW5nIGJsb2Nr cyBjdXJyZW50bHkgcmVxdWlyZSB0aW1lIGluZm9ybWF0aW9uLA0KPnN1Y2ggYXMgY2VydGlmaWNh dGVzIGFuZCBhY2Nlc3MgdG9rZW5zLg0KPg0KPkluIHlvdXIgZW1haWwgd3JpdGUtdXAsIHNlZQ0K Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTU1 NC5odG1sLCB5b3UNCj5jb3JyZWN0bHkgcG9pbnRlZCBvdXQgdGhhdCB0aGVyZSBpcyBhIHJlbGF0 aW9uc2hpcCB3aXRoIHRoZSB2YWxpZGl0eSBvZg0KPnRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0 aW9uIGFuZCB3aXRoIGEgcG90ZW50aWFsIHJldm9jYXRpb24gbWVjaGFuaXNtLg0KPg0KPkJlZm9y ZSB3ZSBzdGFydCB3b3JraW5nIG9uIHNvbHV0aW9ucyBJIHdvdWxkIGxpa2UgdG8gZ2V0IGEgc2Vu c2Ugb2YgdGhlDQo+Z3JvdXAgd2hhdCB0aGUgdmlld3MgYXJlLiBGb3IgcmVzb3VyY2Ugc2VydmVy cyBkbyB5b3UgY29uc2lkZXIgdG8NCj5pbmNvcnBvcmF0ZSBhIHJlYWwtdGltZSBjbG9jayBhbmQg YSBwcm90b2NvbCBtZWNoYW5pc20gdGhhdCBvYnRhaW5zIHRpbWUNCj5pbmZvcm1hdGlvbj8NCj4N Cj5Ob3QgaGF2aW5nIHRpbWUgaW5mb3JtYXRpb24gYXQgdGhlIFJTIHdpbGwgaGF2ZSB0aGUgZm9s bG93aW5nIGltcGFjdDoNCj4NCj4qIFRoZSBSUyBzb21laG93IGhhcyB0byBnZXQgaW5mb3JtYXRp b24gYWJvdXQgYWNjZXNzIHRva2VucyB3aGVyZQ0KPnBlcm1pc3Npb25zIGhhdmUgY2hhbmdlZCwg d2hlcmUgdGhlIGFjY2VzcyB0b2tlbnMgaGF2ZSBiZWVuIHJldm9rZWQgb3INCj5oYXZlIG90aGVy d2lzZSBiZWVuIGludmFsaWRhdGVkIHNpbmNlIHRoZSB0b2tlbnMgZG8gbm90IGNvbnRhaW4gdmFs aWRpdHkNCj5pbmZvcm1hdGlvbi4NCj4qIFRpbWUtcmVsYXRlZCBpbmZvcm1hdGlvbiBpbiBjZXJ0 aWZpY2F0ZXMgY2Fubm90IGJlIGNoZWNrZWQuDQo+DQo+SW4gbWFueSBzaXR1YXRpb25zIHdlIHdp bGwgaGF2ZSBhIHRyYWRlb2ZmIGJldHdlZW4gdGhlIGF2YWlsYWJpbGl0eSBvZg0KPnRpbWUgaW5m b3JtYXRpb24gYW5kIHRoZSByZXF1aXJlZCBjb21tdW5pY2F0aW9uIG92ZXJoZWFkIGZvciBpbnRl cmFjdGluZw0KPndpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluIHVwLXRvLWRh dGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQo+dmFsaWRpdHkgb2YgdGhlIGNyZWRlbnRpYWxzLg0K Pg0KPldoYXQgZG9lcyB0aGUgZ3JvdXAgdGhpbms/DQo+DQo+Q2lhbw0KPkhhbm5lcw0KPg0KPg0K Pk9uIDExLzE5LzIwMTUgMTA6MTkgQU0sIFJhZmEgTWFyaW4gTG9wZXogd3JvdGU6DQo+PiBIaSBS ZW56bzoNCj4+IA0KPj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGlmIHdlIGNvbnNpZGVyIHRoZSBk aXN0cmlidXRpb24gb2YgYSBzeW1tZXRyaWMNCj4+a2V5IGJldHdlZW4gdGhyZWUgcGFydGllcyB0 aGUgbGl0ZXJhdHVyZSBpcyBmdWxsIG9mIHZlcnkgY29uY2lzZSBhbmQNCj4+c2VjdXJpdHkgcHJv dmVuIHByb3RvY29scy4NCj4+IA0KPj4gUGxlYXNlIGNvdW50IG9uIG1lIGlmIHNvbWUgaGVscCBp cyByZXF1aXJlZCBpbiB0aGlzIGFyZWEuDQo+PiANCj4+IEJlc3QgUmVnYXJkcy4gDQo+PiANCj4+ IA0KPj4+IEVsIDEzIG5vdiAyMDE1LCBhIGxhcyAxNzozMCwgUmVuem8gTmF2YXMgPHJlbnpvZWZy YUBnbWFpbC5jb20+DQo+Pj5lc2NyaWJpw7M6DQo+Pj4NCj4+PiBHb29kIEV2ZW5pbmcgQUNFIE1M LA0KPj4+DQo+Pj4gUmVhZGluZyBkcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDAgKHRoYW5r cyB0byB0aGUgYXV0aG9ycyBmb3IgZWFzeQ0KPj4+IHRvIHJlYWQgZG9jKSBJIHdhcyB2ZXJ5IGlu dGVyZXN0ZWQgYnkgdGhlIFBvUCB0b2tlbiB0aGF0IG9mZmVycyBhbg0KPj4+IGF1dGhlbnRpY2F0 ZWQgZnJlc2gga2V5IHRvIGJlIHVzZWQgZm9yIGZ1cnRoZXIgc2VjdXJlIHRoZSBjb21tLiwNCj4+ PiBidXQgSSBzYXcgYSB2ZXJ5IHN0cm9uZyByZXF1aXJlbWVudCBmb3IgdGhlIFJTIHRvIGhhdmUg YSBUaW1lIFN5bmMuDQo+Pj5tZWNoYW5pc20uDQo+Pj4gSSBwcmV2aWV3IHRoZSBvYmplY3RpdmUg b2YgbXkgbWFpbCwgIGlzIHRvIHJhaXNlIHRoZSBxdWVzdGlvbjoNCj4+Pg0KPj4+ICogRG8gd2Ug d2FudCB0byBoYXZlIGEgc3Ryb25nIHJlcXVpcmVtZW50IGZvciB0aGUgY29uc3RyYWluZWQgZGV2 aWNlDQo+Pj4gKFJTKSBvbiBhbiBBQSBBcmNoaXRlY3R1cmUgdG8gaGF2ZSBhIFRpbWUgU3luY2hy b25pemF0aW9uIG1lY2hhbmlzbT8NCj4+PiAqIEFyZSB3ZSBpbnRlcmVzdGVkIG9uIG9mZmVyaW5n IG5vbi10aW1lIC1ub25jZS0gYmFzZWQgc29sdXRpb24gZm9yIGFuDQo+Pj4gT0F1dGggUG9QIFRv a2VuIGFwcHJvYWNoIChmb3IgZXhhbXBsZSB3aGVuIHRoZSB0b2tlbiBkb2VzIG5vdCBleHBpcmUp Pw0KPj4+DQo+Pj4NCj4+PiAodGhvc2UgaW50ZXJlc3RlZCBvbiB0aG9zZSBjb25jZXJucyBjYW4g cmVhZCB0aGUgcmVzdCBvZiB0aGUgbWFpbCwNCj4+PiB0aGF0IGlzIHJhdGhlciBsb25nKQ0KPj4+ DQo+Pj4gUmVnYXJkcw0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+DQo+Pj4gKExvbmcgdmVyc2lvbikNCj4+Pg0KPj4+ IEkndmUgYmVlbiB3b3JraW5nIGxhdGVseSBvbiB0aGUgQXV0aGVudGljYXRlZCBLZXkgRXN0YWJs aXNobWVudA0KPj4+IHByb2JsZW0gKFRoZSBhcmUgdHdvIHZlcnkgZ29vZCByZWZlcmVuY2UgYm9v a3MgWzFdWzJdKSwgZm9jdXNpbmcgb24NCj4+PiBzb2x1dGlvbnMgd2l0aCBhIFRydXN0ZWQgVGhp cmQgUGFydHksIFN5bW1ldHJpYyBDcnlwdG8sIGFuZCBub3QgdXNpbmcNCj4+PiBUaW1lLXN0YW1w cyBidXQgTm9uY2VzIChUbyBhdm9pZCBoYXZpbmcgdG8gZGVhbCB3aXRoIHRpbWUNCj4+PiBzeW5j aHJvbml6YXRpb24pLkkgaGF2ZSBubyBzdHJvbmcgQ3J5cHRvIGJhY2tncm91bmQuDQo+Pj4NCj4+ PiBGaXJzdCBJIHdhbnQgdG8gdGhhbmsgdGhlIGF1dGhvcnMgb2YgZHJhZnQtc2VpdHotYWNlLW9h dXRoLWF1dGh6LTAwICwNCj4+PiB2ZXJ5IGVubGlnaHRlbmluZyBmb3IgdGhlIG9hdXRoIG5lb3Bo eXRlcy4NCj4+PiBJJ20gbW9zdGx5IGludGVyZXN0ZWQgb24gdGhlIGF1dGhlbnRpY2F0aW9uIHBy b2JsZW0gKGF1dGguIGtleQ0KPj4+IGVzdGFibGlzaG1lbnQpLCBzbyB0aGUgUHJvb2Ytb2YtUG9z c2VzaW9uIFRva2VuIGlzIGEgZ3JlYXQNCj4+PiB0b29sL2NvbmNlcHQsIEkgdG9vayB0aGUgdGlt ZSB0byByZWFkDQo+Pj4gZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1IGFuZA0K Pj4+IGRyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24tMDIgdG8gdHJ5IHRvIGhh dmUgYWxsIHRoZQ0KPj4+IGJhY2tncm91bmQgcG9zc2libGUuDQo+Pj4NCj4+PiBTbyBmcm9tIHRo ZSBBdXRoZW50aWNhdGVkIGtleSBlc3RhYmxpc2htZW50IG1lY2hhbmlzbSBwb2ludCBvZiB2aWV3 IGENCj4+PiBuZXcgZnJlc2gga2V5IGJldHdlZW4gQyBhbmQgUlMgb2J0YWluZWQgYnkgbWVhbnMg b2YgYSAgUG9QIFRva2VuDQo+Pj4gbWVjaGFuaXNtIC1JIHRoaW5rLSB3aWxsIGJlIHNpbWlsYXIg dG8gYSAgRGVubmluZy1TYWNjbyBzaGFyZWQga2V5DQo+Pj4gcHJvdG9jb2wgKCANCj4+Pmh0dHA6 Ly93d3cubHN2LmVucy1jYWNoYW4uZnIvU29mdHdhcmUvc3BvcmUvZGVubmluZ1NhY2NvLmh0bWwN Cj4+PiAuIENsaWVudCBpcyBBLCBBUyBpcyBTLCBhbmQgUlMgaXMgQiksIHdpdGggdGhlIGRpZmZl cmVuY2UgdGhhdCB0aGUgUG9QDQo+Pj4gVG9rZW4gVGltZXN0YW1wIGhhdmUgYSBzdGFydCBhbmQg ZW5kIHZhbHVlIHRoYXQgd2lsbCBtYWtlIHRoZQ0KPj4+ICJtdXRpcGxpY2l0eSBhdHRhY2siIG9m IERlbm5pbmctU2FjY28gbGltaXRlZCBvbiB0aW1lLg0KPj4+DQo+Pj4gTXkgY29uY2VybiBpcyB0 aGF0IHdlIHdpbGwgYWx3YXlzIG5lZWQgVGltZSBzeW5jIG9uIHRoZSBSUywgdGhhdCBzb21lDQo+ Pj4gKG1vc3QpIHRpbWVzIHdpbGwgYmUgdGhlIGNvbnN0cmFpbmVkIG5vZGUgKEkgdGhpbmsgdGhh dCB0aGUgQ2xpZW50DQo+Pj4gZG9lcyBub3QgbmVlZCB0byBiZSBUaW1lLWF3YXJlKSwgaXMgdGhh dCBhIE1VU1QgcmVxdWlyZW1lbnQ/IFNvDQo+Pj4gbm8tdGltZSBhd2FyZSBkZXZpY2VzIHdpbGwg bm90IGJlIGFibGUgdG8gdXNlIE9BdXRoIFBvUCBUb2tlbiAob3Igd2lsbA0KPj4+IGhhdmUgdG8g dXNlIHRva2VuIGludHJvc3BlY3Rpb24sIGEgZ29vZCBmYWxsYmFjayBzb2x1dGlvbiBidHcpDQo+ Pj4NCj4+PiBXaWxsIGJlIG9mIGludGVyZXN0IG9mZmVyaW5nIGEgUG9QIFRva2VuIGdlbmVyYXRp b24gYW5kIHRyYW5zcG9ydA0KPj4+IG1lY2hhbmlzbXMgdGhhdCAgb2ZmZXJzIGFuIGF1dGhlbnRp Y2F0ZWQgZnJlc2gga2V5IHdpdGhvdXQgdGhlIG5lZWQgb2YNCj4+PiBUaW1lLWF3YXJlbm5lc3Mg YXQgdGhlIFJTPw0KPj4+DQo+Pj4gVGltZSBhd2FyZW5lc3MgYXQgdGhlIFJTIG9mZmVycyBncmVh dCBhZHZhbnRhZ2VzLCBhbmQgbWF5YmUgYWxzbyBUaW1lDQo+Pj4gaXMgYWx3YXlzIG5lZWRlZCBp biBhbGwgYXV0aG9yaXphdGlvbiBzb2x1dGlvbnMgKHRvIG1ha2UgZWFzeSB0b2tlbg0KPj4+IGV4 cGlyYXRpb24gYW5kIGZyZXNobmVzcyBjbGFpbXMpLg0KPj4+DQo+Pj4gQnV0IEknbSB0aGlua2lu ZyBhYm91dCBub25jZS1iYXNlZCBhdXRoZW50aWNhdGVkIGtleSBlc3RhYmxpc2htZW50LiBPZg0K Pj4+IGNvdXJzZSB3aXRob3V0IHRpbWUgaW5mb3JtYXRpb24gZW1iZWRkZWQgb24gdGhlIHRva2Vu LCB0b2tlbg0KPj4+IGV4cGlyYXRpb24gd2lsbCBiZSBtb3JlIGRpZmZpY3VsdDoNCj4+PiAqIHdl IHdpbGwgbmVlZCB0b2tlbiBpbnRyb3NwZWN0aW9uLCBvcg0KPj4+ICogdGhlIEFTIHdpbGwgY29u dGFjdCB0aGUgUlMgdG8gcmV2b2tlIHRva2Vucywgb3INCj4+PiAqIHdlIHdpbGwgbmVlZCBvbiBh IG5vbi10aW1lIGJhc2VkIHNvbHV0aW9uIGZvciByZXZvY2F0aW9uIHRoYXQgZG9lcw0KPj4+IG5v dCBpbnZvbHZlIHRoZSBBUywgZm9yIGV4YW1wbGU6IGEgcG9wIHRva2VuL2tleSBpcyB2YWxpZCBm b3IgdXNlIG9ubHkNCj4+PiBmb3Igb25lIChvciBOKSBSZXNvdXJjZSBSZXF1ZXN0cyAob2YgY291 cnNlIGlmIHRoZSByZXNwb25zZSBtZXNzYWdlDQo+Pj4gZ2V0IGxvc3Qgd2UgYXJlIHNjcmV3ZWQu Li4pDQo+Pj4NCj4+Pg0KPj4+IFNvIG1heWJlIHdlIGNhbm5vdCBhdm9pZCB0byBoYXZlIFRpbWUt YXdhcmVuZXNzIGF0IHRoZSBSUywgZm9yDQo+Pj4gQXV0aG9yaXphdGlvbiBwdXJwb3Nlcy4uDQo+ Pj4gQnV0IGZvciBBdXRoZW50aWNhdGlvbiBjZXJ0YWlubHkgd2UgY2FuIGF2b2lkIFRpbWUsIHRo ZSB0aHJlZSBtb3N0DQo+Pj4gcmVjb21tZW5kZWQgYnkgWzJdIG5vbmNlLWJhc2VkIHByb3RvY29s cyBhcmU6DQo+Pj4gKiBCZWxsYXJlLVJvZ2F3YXkgKDNQS0QpIFthIENob28gbW9kaWZpZWQgdmVy c2lvbiBJdCBoYXMgYmVlbiBwcm92ZW4NCj4+PiBwcm92YWJseSBzZWN1cmUgb24gdGhlIHN0cm9u Z2VzdCBtb2RlbCB0byB0ZXN0IGF1dGguIGtleSBlc3RhYmxpc2htZW50DQo+Pj4gcHJvdG9jb2xz IF0gWzNdDQo+Pj4gKiBZYWhhbG9tIFthIG1vZGlmaWVkIHZlcnNpb24gaGFzIGJlZW4gcHJvdmVu IHNlY3VyZSBvbiBhIHdlYWtlciBtb2RlbA0KPj4+IC1iZWxsYXJlIHJvZ3dheS0gdGhhbiAzUEtE XSBbNF0NCj4+PiAqIEJveWQgW0tleSBBZ3JlZW1lbnQ6IFJTLCBDIGFuZCBBUyBjb250cmlidXRl IGlucHV0cyB0byBnZW5lcmF0ZSB0aGUNCj4+PiBrZXldIFtwcm9vZiBpZGVtIHlhaGFsb20gXVs1 XQ0KPj4+DQo+Pj4gVGhlIG1lc3NhZ2UgZmxvd3Mgb24gdGhhdCB0aHJlZSBvZiBwcm90b2NvbHMg ZG8gbm90IHJlc3BlY3QgT0F1dGgNCj4+PiBmbG93cyAoSSBhdHRhY2ggYW4gaW1hZ2Ugd2l0aCB0 aGUgaGlnaCBsZXZlbCBtZXNzYWdlIGZsb3dzLCBBIGlzIHRoZQ0KPj4+IGluaXRpYXRvciBhbHdh eXMpLCBzbyB0aGF0IHRha2UgdXMgYXBhcnQgYSBiaXQgZnJvbSBPQXV0aC4uLg0KPj4+DQo+Pj4g VGhpcyBtYWlsIGlzIHN0YXJ0aW5nIHRvIGdldCBsb25nIHNvIEkgd2lsbCB0cnkgdG8gY29uY2x1 ZGUgaXQsIGJ1dA0KPj4+IGhvcGVmdWxseSByYWlzZSB0aGUgcXVlc3Rpb246DQo+Pj4NCj4+Pg0K Pj4+ICoqIEFyZSB3ZSBpbnRlcmVzdGVkIG9uIG9mZmVyaW5nIG5vbi10aW1lIC1ub25jZS0gYmFz ZWQgc29sdXRpb24gZm9yDQo+Pj4gYW4gT0F1dGggUG9QIFRva2VuIGFwcHJvYWNoIChmb3IgZXhh bXBsZSB3aGVuIHRoZSB0b2tlbiBkb2VzIG5vdA0KPj4+IGV4cGlyZSkqKj8NCj4+Pg0KPj4+DQo+ Pj4NCj4+PiBJZiBOTywgSSBndWVzcyB0aGF0IHdpbGwgbmVlZCB0b2tlbiBpbnRyb3NwZWN0aW9u IGZvciBSUyB0aGF0IGNhbm5vdA0KPj4+IHN1cHBvcnQgdGltZSAoVGhhdCBtZWNoYW5pc20gd2ls bCBtYXAgdG8gb3RoZXIgYXV0aGVudGljYXRlZCBrZXkNCj4+PiBlc3RhYmxpc2htZW50IHByb3Rv Y29sIGFuZCBub3QgRGVubmluZy1TYWNjby1iYXNlZCApDQo+Pj4NCj4+PiBpZiBZRVMsIGFyZSB3 ZSBpbnRlcmVzdGVkIGluIGFkYXB0aW5nIGEgbm9uY2UtYmFzZWQgYXV0aC4ga2V5DQo+Pj4gZXN0 YWJsaXNobWVudCBwcm90b2NvbCB0byBPQXV0aCBQb1AgVG9rZW4/DQo+Pj4NCj4+Pg0KPj4+IEkg aG9wZSB0aGlzIHF1ZXN0aW9ucyBhcmUgdXNlZnVsLA0KPj4+DQo+Pj4gQmVzdCByZWdhcmRzDQo+ Pj4NCj4+PiBSZW56bw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFsxXSBDb2xpbiBBLiBCb3lkIGFuZCBB bmlzaCBNYXRodXJpYS4gMjAwMy4gUHJvdG9jb2xzIGZvciBLZXkNCj4+PiBFc3RhYmxpc2htZW50 IGFuZCBBdXRoZW50aWNhdGlvbi4gU3ByaW5nZXItVmVybGFnIE5ldyBZb3JrLCBJbmMuLA0KPj4+ IFNlY2F1Y3VzLCBOSiwgVVNBLg0KPj4+IFsyXSBLaW0tS3dhbmcgUmF5bW9uZCBDaG9vLiAyMDA4 LiBTZWN1cmUgS2V5IEVzdGFibGlzaG1lbnQgKDFlZC4pLg0KPj4+IFNwcmluZ2VyIFB1Ymxpc2hp bmcgQ29tcGFueSwgSW5jb3Jwb3JhdGVkLg0KPj4+DQo+Pj4gWzNdIDNQS0QgLSANCj4+Pmh0dHA6 Ly9lcHJpbnRzLnF1dC5lZHUuYXUvMTIzMC8xL0FDSVNQX0Z1bGxfVmVyc2lvbl8tXzAzX01heV8y MDA1LnBkZg0KPj4+IFs0XSBZYWhhbG9tIC0gaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAwNy8x ODgucGRmDQo+Pj4gWzVdIEJveWQgLSBodHRwOi8vZXByaW50cy5xdXQuZWR1LmF1LzQ0MjEvMS80 NDIxXzEucGRmDQo+Pj4gDQo+Pj48QXV0aC1LZXktRXN0YWJsaXNobWVuLU1zZ0Zsb3dzLnBuZz5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pl9fX19fX19fX19fDQo+Pj4g QWNlIG1haWxpbmcgbGlzdA0KPj4+IEFjZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFJhZmFlbCBNYXJpbiBMb3Bleiwg UGhEDQo+PiBEZXB0LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcg KERJSUMpDQo+PiBGYWN1bHR5IG9mIENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBvZiBNdXJj aWENCj4+IDMwMTAwIE11cmNpYSAtIFNwYWluDQo+PiBUZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiAr MzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2Ug bWFpbGluZyBsaXN0DQo+PiBBY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWNlDQo+PiANCj4NCg0K From nobody Sat Jan 23 05:23:34 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09B1A036E for ; Sat, 23 Jan 2016 05:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOnQ3mh2D3en for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CC01A0368 for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id o6so39089425qkc.2 for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=lKmaJ+520eVDn8ESw9OwVeNvll2XCs9o7FSElQdfRZE=; b=IIKBPItPhd7h8JoTzfezpPen1+HCU5cu/uGJReBHNep6YIx8mEmc0H3dvYsPMd+in9 njwrR5UPjET0ejwqdPEpcMucFgEkKe4hdA93w7ozOjYyTuFlfSHE4Nn4hMDHrmkQQC5l Ca7f6vFCKehlg+fMgfjP3FICrPSEj9T0/LRxlkh63YBIBCsQw3DH8kg3K1L7PN9jmLWV 5YAuoKRR9e14ZPEX/OqQ1+eeY6qHfNDVnO860UJbztUZWz4ygP+ht9tJyVr8xaQxkAdr +wbdN1qa7QfG7S1eoExgCZQmJzQwagFE0deVOHMJsQWc//9tpts52Cha9FyRrXxtKZaE 2/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lKmaJ+520eVDn8ESw9OwVeNvll2XCs9o7FSElQdfRZE=; b=gehqCg5HwQjF29GYqpkMyx+9IQ6aitodH+XEWChr7lVtDJd/sVsM0BXK4NQ3EwXzFo iP2HqFlE68gBVo3CNReioeax640rysn/vBcT1ON28jEikPJjXnfT9wd2FzLoEas8++Jo /5ZwWWVSluo4Trp0yRAy3rvON+EKw4F0uhouSh3OtgJhvAzCkT1KrSbmEoAKv/HxuEHK nOqre7XBZAoWsTl8eJo6ektm7ww/s26mWwTSNEtWEPfHmwccv+V1vqYfgLFGMhMyhPC0 ALcUBj1WciU3VsA2tOUDDEBhrSUOEUf5XyWNZsiZm1ckkCHpO5lpqqrJpjDeQqRbxkSp m02w== X-Gm-Message-State: AG10YORCvPuoJt2Rzdih2OOk1POvl7UlundXYHxeN7fgEfezb8SY/wjr3+ARwtGzlf1y2V9juHpBytZQT+J9WA== MIME-Version: 1.0 X-Received: by 10.55.24.77 with SMTP id j74mr9665155qkh.53.1453555409388; Sat, 23 Jan 2016 05:23:29 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sat, 23 Jan 2016 05:23:29 -0800 (PST) Date: Sat, 23 Jan 2016 14:23:29 +0100 Message-ID: From: Samuel Erdtman To: cose , Jim Schaad , Ace@ietf.org, =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a11440d3ad6aa42052a003db5 Archived-At: Subject: [Ace] CoAP Content-Format X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 13:23:32 -0000 --001a11440d3ad6aa42052a003db5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point wh= ere I need a Content-Format for conveying the PoP token from the Client to the Resource Server as content of a CoAP POST. draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens but it seems reasonable, I could use application/cbor but application/cose, application/cose+cwt or application/cwt seems more appropriate. Are there plans to register any of these Content-Format either from the COSE specification or the CWT specification or should I do something from draft-ietf-ace-oauth-authz? Best Regards //Samuel --001a11440d3ad6aa42052a003db5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I=C2=B4m writing on the=C2=A0draft-= ietf-ace-oauth-authz and came to the point where I need a=C2=A0Content-Form= at for conveying the PoP token from the Client to the Resource Server as co= ntent of a CoAP POST.

draft-ietf-ace-oauth-authz d= oes not mandate use of COSE encoded tokens but it seems reasonable, I could= use=C2=A0applicati= on/cbor but=C2=A0application/cose,=C2=A0application/cose+cwt or=C2=A0application/cwt seems more=C2=A0appropriate.
Are t= here plans to register any of these=C2=A0Content-Format either from the COSE specification or the CW= T specification or should I do something from=C2=A0=C2=A0draf= t-ietf-ace-oauth-authz?

Best Regards
//S= amuel
=C2= =A0
--001a11440d3ad6aa42052a003db5-- From nobody Sat Jan 23 05:51:13 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0BF1A1AE6 for ; Sat, 23 Jan 2016 05:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGh_Xqc4zGqq for ; Sat, 23 Jan 2016 05:51:10 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647BE1A1AD3 for ; Sat, 23 Jan 2016 05:51:10 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s68so39075678qkh.3 for ; Sat, 23 Jan 2016 05:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=9cVyI8UdIjvIvlTaloWHPUjVFEPQbCyVH+XeawBMDJk=; b=LkV48fJJNUDjMu2ZaqriAyo7vkp0ITpXjtOJab+43Ph6AR6WG2qeNW62i6t+CtJG7E osGNKcqPIb0uIrWsBHKVBj9flcQW5NI+L38iMuJnwOwifDZaZIfsKOvr1etDOPjtAfL6 I+Y+isRLo60u4uvt5gw7DiyLsvx3ds/GLvW9qJe3KjQQigL7upmlM4/LAOJDsaoG0sTJ qEf8repIL18Qs/DtSTReX0AhisR1N8DAroYQRZJ+6ezDe6xrqhs9Ubc9R8SmALqZGrvF RRN+DsYKxW62P70Cj9MXT3VhZVeGiw8c7MB7g/XRIRr8iucQ7JpOipekU8PeIF3Fi/vr TWow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9cVyI8UdIjvIvlTaloWHPUjVFEPQbCyVH+XeawBMDJk=; b=E01/Xfv7xYPa4D6Wcfts407VShEd/eIFk+ux7cip0AGJ60SDeNQstgK1eSshQq1D63 yC5A8dHeXm4yQzuzo4CUDPT73OIrsdn+6dZrZV+pLrguAxGYemOt14l0Oi6pKC7/MzSc VJl0m7tmMEqP3FvdkxFzuKHAYY4h0gI1yJCNNp0ARNpWmLt0fe0hQj7ElDHLelB/vXZK bOcViGP6UMEb+nxESW8c/ENivRMaAv3JgkrpM/dSdDNWQ4IyeorJJXQ5C3GnxucnS8jB GQ1Rv8nrjJfDG97GAPoYgDke7By2i4LZcdXVTdmqbmoQaAobxTi5lNEl1CllRG81rKty oSpg== X-Gm-Message-State: AG10YOQ2V5HCSzYj/Dnyc8Pq5Ph7aoNRtydcV6I0opeC0iDaGMv3+cvcnWTFnZmx0ej5HLrzS37CgR8m2tXnqg== MIME-Version: 1.0 X-Received: by 10.55.71.146 with SMTP id u140mr10015119qka.14.1453557069615; Sat, 23 Jan 2016 05:51:09 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sat, 23 Jan 2016 05:51:09 -0800 (PST) Date: Sat, 23 Jan 2016 14:51:09 +0100 Message-ID: From: Samuel Erdtman To: Ace@ietf.org Content-Type: multipart/alternative; boundary=001a114a7b96cbbf1d052a00a02a Archived-At: Subject: [Ace] =?utf-8?q?Issue=3A_Define_=22/authz-info=E2=80=9D_endpoint_?= =?utf-8?q?on_RS?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 13:51:11 -0000 --001a114a7b96cbbf1d052a00a02a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I have added text to resolve * Define "/authz-info=E2=80=9D endpoint on RS ( https://github.com/LudwigSeitz/ace-oauth/issues/5) Result can bee seen here under section 5.2 https://github.com/LudwigSeitz/ace-oauth/blob/master/draft-ietf-ace-oauth-a= uthz.txt A question came up while writing. Do we need to define an error response format or is the CoAP response codes enough? OAuth2 defines various error responses for when requesting tokens, but it does not for the resource access request (https://tools.ietf.org/html/rfc6749#section-7.2). I think this resource is more similar to a resource access request then to the token request, i.e. we do not need to define error response format. Best Regards //Samuel --001a114a7b96cbbf1d052a00a02a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A question came up while writing. Do we need to define a= n error response format or is the CoAP response codes enough? OAuth2 define= s various error responses for when requesting tokens, but it does not for t= he resource access request (https://tools.ietf.org/html/rfc6749#section-7.2). I think = this resource is more similar to a resource access request then to the toke= n request, i.e. we do not need to define error response format.
<= br>
Best Regards
//Samuel
--001a114a7b96cbbf1d052a00a02a-- From nobody Sat Jan 23 09:10:17 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC31B39B0; Sat, 23 Jan 2016 09:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlXuoPcOw95Q; Sat, 23 Jan 2016 09:10:14 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78EB1B3993; Sat, 23 Jan 2016 09:10:13 -0800 (PST) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4E72E1720B2; Sat, 23 Jan 2016 18:10:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TgSnssUHcFZz; Sat, 23 Jan 2016 18:10:10 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id AD60D172098; Sat, 23 Jan 2016 18:10:09 +0100 (CET) Message-ID: <56A3B3F2.7070003@tzi.org> Date: Sat, 23 Jan 2016 18:10:10 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Samuel Erdtman References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , Ace@ietf.org, =?UTF-8?B?RXJpayBXYWhsc3Ryw7Zt?= , cose Subject: Re: [Ace] [COSE] CoAP Content-Format X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:10:16 -0000 > I麓m writing on the draft-ietf-ace-oauth-authz and came to the point > where I need a Content-Format for conveying the PoP token from the > Client to the Resource Server as content of a CoAP POST. > > draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens > but it seems reasonable, I could use application/cbor > but application/cose, application/cose+cwt or application/cwt seems > more appropriate. Once a COSE-based OAuth token is defined, that should get a media type and a do a CoAP content-format registration right with that. There is a bit of structure behind the +xyz names, so here this would be: application/cwt+cbor (but then, because of the signing, there is little point in having anything but a cbor version of that, so the +cbor is a bit redundant). > Are there plans to register any of these Content-Format either from the > COSE specification or the CWT specification or should I do something > from draft-ietf-ace-oauth-authz? Whoever gets to define the media type (format, contents, processing rules) gets to register it. Is this a CWT? Are we done with deciding which WG does CWT? Gr眉脽e, Carsten From nobody Sat Jan 23 13:36:16 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D221A8842; Sat, 23 Jan 2016 13:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqs1zTp-zFFK; Sat, 23 Jan 2016 13:36:12 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7D91A039B; Sat, 23 Jan 2016 13:36:12 -0800 (PST) Received: from hebrews (unknown [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 6C9A52C9B7; Sat, 23 Jan 2016 13:36:11 -0800 (PST) From: "Jim Schaad" To: "'Samuel Erdtman'" , "'cose'" , , =?UTF-8?Q?'Erik_Wahlstr=C3=B6m'?= References: In-Reply-To: Date: Sat, 23 Jan 2016 13:33:35 -0800 Message-ID: <03c601d15625$b7771b30$26655190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C7_01D155E2.A955AFF0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGaZk8iigNlBXuxIZmAU2Qd7Bpl0Z93fpvg Archived-At: Subject: Re: [Ace] CoAP Content-Format X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 21:36:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03C7_01D155E2.A955AFF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The COSE document registers application/cose but not = application/cose+cbor. I don=E2=80=99t know the status of CWT. =20 Jim =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Saturday, January 23, 2016 5:23 AM To: cose ; Jim Schaad ; = Ace@ietf.org; Erik Wahlstr=C3=B6m Subject: CoAP Content-Format =20 Hi, =20 I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point = where I need a Content-Format for conveying the PoP token from the = Client to the Resource Server as content of a CoAP POST. =20 draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens = but it seems reasonable, I could use application/cbor but = application/cose, application/cose+cwt or application/cwt seems more = appropriate. Are there plans to register any of these Content-Format either from the = COSE specification or the CWT specification or should I do something = from draft-ietf-ace-oauth-authz? =20 Best Regards //Samuel =20 ------=_NextPart_000_03C7_01D155E2.A955AFF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The COSE document registers application/cose but not = application/cose+cbor.=C2=A0 I don=E2=80=99t know the status of = CWT.

 

Jim

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Saturday, = January 23, 2016 5:23 AM
To: cose <cose@ietf.org>; Jim = Schaad <ietf@augustcellars.com>; Ace@ietf.org; Erik Wahlstr=C3=B6m = <erik@wahlstromstekniska.se>
Subject: CoAP = Content-Format

 

Hi,

 

I=C2=B4m writing on = the draft-ietf-ace-oauth-authz and came to the point where I need = a Content-Format for conveying the PoP token from the Client to the = Resource Server as content of a CoAP POST.

 

draft-ietf-ace-oauth-authz does not mandate use of = COSE encoded tokens but it seems reasonable, I could use application/cbor but application/cose, application/cose+cwt = or application/cwt seems = more appropriate.

Are there plans to register any of these Content-Format either = from the COSE specification or the CWT specification or should I do = something = from  draft-ietf-ace-oauth-authz?

 

Best Regards

//Samuel

 

------=_NextPart_000_03C7_01D155E2.A955AFF0-- From nobody Sun Jan 24 16:52:51 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7A1B364A; Sun, 24 Jan 2016 16:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckQ9JiW8amkA; Sun, 24 Jan 2016 16:52:47 -0800 (PST) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2F1B3648; Sun, 24 Jan 2016 16:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1453683163; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=kOMamCs/HSIqOEIy7zmLg8Y1AAYuu1u/Pwh+neZOGjU=; b=N7j9g/2DwkhLCIq5D0gHB/4YiQCohRHi4gDm9EZSW7j0XEGGEumZfcWpdBUIG9hXRG/jo3Nu1ECutjHwSC8p/XzhFFFYgDSMOZB48QVA/rm5cVFR8m1x7x87qbsR6if623bKjR92zan6pqldprxj8vB1VlaJGu3JEcn3Pvni98o= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R591e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l10434; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_----4Tr-Ofd_1453683153; Received: from 30.10.27.169(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.105) by smtp.aliyun-inc.com(127.0.0.1); Mon, 25 Jan 2016 08:52:40 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 25 Jan 2016 08:52:36 +0800 From: "Kepeng Li" To: Carsten Bormann , Samuel Erdtman Message-ID: Thread-Topic: [COSE] CoAP Content-Format References: <56A3B3F2.7070003@tzi.org> In-Reply-To: <56A3B3F2.7070003@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: Jim Schaad , Erik =?ISO-8859-1?B?V2FobHN0cvZt?= , cose , Ace@ietf.org Subject: Re: [Ace] [COSE] CoAP Content-Format X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 00:52:48 -0000 > Are we done with deciding which WG does CWT? Yes, it should be done in ACE WG. Please refer to the discussions in COSE mailing list: http://www.ietf.org/mail-archive/web/cose/current/msg00810.html Kind Regards Kepeng =E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten Bormann" =E5=86=99=E5=85=A5: >> I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point >> where I need a Content-Format for conveying the PoP token from the >> Client to the Resource Server as content of a CoAP POST. >>=20 >> draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens >> but it seems reasonable, I could use application/cbor >> but application/cose, application/cose+cwt or application/cwt seems >> more appropriate. > >Once a COSE-based OAuth token is defined, that should get a media type >and a do a CoAP content-format registration right with that. > >There is a bit of structure behind the +xyz names, so here this would be: > >application/cwt+cbor > >(but then, because of the signing, there is little point in having >anything but a cbor version of that, so the +cbor is a bit redundant). > >> Are there plans to register any of these Content-Format either from the >> COSE specification or the CWT specification or should I do something >> from draft-ietf-ace-oauth-authz? > >Whoever gets to define the media type (format, contents, processing >rules) gets to register it. Is this a CWT? Are we done with deciding >which WG does CWT? > >Gr=C3=BC=C3=9Fe, Carsten > >_______________________________________________ >COSE mailing list >COSE@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jan 25 02:55:58 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3E1A89FA for ; Mon, 25 Jan 2016 02:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t08vH4IitD_E for ; Mon, 25 Jan 2016 02:52:40 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E631A89F6 for ; Mon, 25 Jan 2016 02:52:39 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id 17so81939225lfz.1 for ; Mon, 25 Jan 2016 02:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8pf/DVadmVQubbb/OK8qozbwde5P7yuDnxdi3R+nU9s=; b=Ii9iaEWDRo/hb9xv0l4lx8MXGC0Qk2LbCOOFteeYkgSfn+90FVEsoZwRQBADxOcuJ9 sfSHOuDBwp67UbFdRH5D6Jdk4y5W6VEdXOHHQKaXvtyGVi0EW80xmgaPNwsXBIdIg1Qj 1mXtsJiSO4s2/wZwuJhSAPetnGczlUpx62pX81WEnega3ZL7kadkcBC6HmWe023LlZ// eMkYm40EgDuzYxtkP8AF9FBcAN7OKRYyytOxXK+mj9p4dI1NgRjNlAUHKUP4WD8yu9gB uwdNL95K//+mllp9McuYQSKN4d0QSpFCxaHeUcWtgIHGfqo67qM7Fwro8TsQKwy05xTH nisg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8pf/DVadmVQubbb/OK8qozbwde5P7yuDnxdi3R+nU9s=; b=V03/75KnGNypvyOYfae2wci8lOrp2ooAotXwyIVR8nltvNLbnTE4UGnXujPLdJ8nTn 3IGhj5GxtwULvKcrXKMMSyzd2P9KvjfdmMJm1EqlqsaRFzyScRVyf2Yv41aGwWf2tUpN Td6BCP8ZyEq2a9EqmuumSKAckUfJYJMmWowy4vvsJSQq6gk24INbAlKCrUvVkkA8vtFN m8BQ0Kinj8sZvsTKWw8APHTZEkDVJVOH0lTUtnvkf86J16c7NC+qte+7Uql/7zNCpm37 rviPCr9P9L45AibkIBR94WlWofw1xR+HKMbTTimG5pjtkvlJW2tmAVaMQreAu8zijUqn 2Maw== X-Gm-Message-State: AG10YORkBn0OjiDB8hdHz+KuKCt/lMVNNqbIrR2zN+SzGEHpE/MJlqnWRSvzOr+8tCHx6Q== X-Received: by 10.25.207.3 with SMTP id f3mr6368621lfg.20.1453719157650; Mon, 25 Jan 2016 02:52:37 -0800 (PST) Received: from [192.168.1.10] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id dt9sm2550026lbc.47.2016.01.25.02.52.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 02:52:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: Date: Mon, 25 Jan 2016 11:52:34 +0100 Message-Id: <1059B572-516A-4454-B4FE-B2A8A27A871E@wahlstromstekniska.se> References: <56A3B3F2.7070003@tzi.org> To: Kepeng Li X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Mon, 25 Jan 2016 02:55:57 -0800 Cc: Samuel Erdtman , Carsten Bormann , cose , Jim Schaad , Ace@ietf.org Subject: Re: [Ace] [COSE] CoAP Content-Format X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 10:52:42 -0000 --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Latest version can be found here (in ace): https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ = The earlier document in oauth2 is archived and also replaced by above = version. I added a potential Content-Format as a new issue in an issue tracker = for CWT. https://github.com/erwah/ietf/issues/7 = / Erik > On 25 Jan 2016, at 01:52, Kepeng Li = wrote: >=20 >> Are we done with deciding which WG does CWT? >=20 >=20 > Yes, it should be done in ACE WG. >=20 > Please refer to the discussions in COSE mailing list: > http://www.ietf.org/mail-archive/web/cose/current/msg00810.html >=20 > Kind Regards > Kepeng >=20 > =E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten Bormann" = =E5=86=99=E5=85=A5: >=20 >>> I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the = point >>> where I need a Content-Format for conveying the PoP token from the >>> Client to the Resource Server as content of a CoAP POST. >>>=20 >>> draft-ietf-ace-oauth-authz does not mandate use of COSE encoded = tokens >>> but it seems reasonable, I could use application/cbor >>> but application/cose, application/cose+cwt or application/cwt seems >>> more appropriate. >>=20 >> Once a COSE-based OAuth token is defined, that should get a media = type >> and a do a CoAP content-format registration right with that. >>=20 >> There is a bit of structure behind the +xyz names, so here this would = be: >>=20 >> application/cwt+cbor >>=20 >> (but then, because of the signing, there is little point in having >> anything but a cbor version of that, so the +cbor is a bit = redundant). >>=20 >>> Are there plans to register any of these Content-Format either from = the >>> COSE specification or the CWT specification or should I do something >>> from draft-ietf-ace-oauth-authz? >>=20 >> Whoever gets to define the media type (format, contents, processing >> rules) gets to register it. Is this a CWT? Are we done with = deciding >> which WG does CWT? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 >=20 --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

Latest version can be found here (in = ace):
https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-= token/

The = earlier document in oauth2 is archived and also replaced by above = version.

I = added a potential Content-Format as a new issue in an issue tracker for = CWT.
https://github.com/erwah/ietf/issues/7

/ Erik


On 25 Jan 2016, at 01:52, = Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Are we done with deciding which WG does CWT?


Yes, it should be = done in ACE WG.

Please refer to the = discussions in COSE mailing list:
http://www.ietf.org/mail-archive/web/cose/current/msg00810.html=

Kind Regards
Kepeng

=E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten = Bormann" <cabo@tzi.org> =E5=86=99=E5=85=A5:

I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came = to the point
where I need a Content-Format for conveying = the PoP token from the
Client to the Resource Server as = content of a CoAP POST.

draft-ietf-ace-oauth-authz does not mandate use of COSE = encoded tokens
but it seems reasonable, I could use = application/cbor
but application/cose, = application/cose+cwt or application/cwt seems
more = appropriate.

Once a COSE-based = OAuth token is defined, that should get a media type
and a = do a CoAP content-format registration right with that.

There is a bit of structure behind the +xyz names, so here = this would be:

application/cwt+cbor

(but then, because of the signing, there is = little point in having
anything but a cbor version of = that, so the +cbor is a bit redundant).

Are there plans to = register any of these Content-Format either from the
COSE = specification or the CWT specification or should I do something
from  draft-ietf-ace-oauth-authz?

Whoever gets to define the media = type (format, contents, processing
rules) gets to register = it.  Is this a CWT?  Are we done with deciding
which WG does CWT?

Gr=C3=BC=C3=9Fe= , Carsten

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose



= --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F-- From nobody Mon Jan 25 17:46:04 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B681ACD69 for ; Mon, 25 Jan 2016 17:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSw_87Xma9H9 for ; Mon, 25 Jan 2016 17:45:50 -0800 (PST) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE71ACD60 for ; Mon, 25 Jan 2016 17:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1453772749; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=i0hDY7NVaI8XTJyJXJxkAQopVdMOpUFPe9mD1YC8kdA=; b=JNqH1TsgaTFuT5CfhRrjAbFdZLSRrA71SyCHsO8uKR7XJHYKOthcxi2NhP/ZO78ChrI94SqaetIgiDNM6oXaOnDpoMCO0s6ff3jn/L7581oQwPodD3Swu4EEINkz8pLlfbb7HoaWgjYuxZSgf7dT62yI38mAhbQpmmJyD7XErPI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07382; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_----4U3aQqy_1453772728; Received: from 30.10.27.169(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.105) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 Jan 2016 09:45:38 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 26 Jan 2016 09:45:27 +0800 From: "Kepeng Li" To: "Kepeng Li" , "Ace@ietf.org" Message-ID: Thread-Topic: [Ace] Doodle for ACE virtual interim meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3536646338_386148" Archived-At: Cc: Hannes Tschofenig , Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Doodle for ACE virtual interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 01:45:57 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3536646338_386148 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable According to the doodle results, the time for our virtual interim meeting will be: 2nd Mar, Wednesday, GMT 14:00 ~ 15:00. I also received a request to add the CWT draft, now the agenda will be: 1. ACE Actors: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ 2. ACE Oauth Solution: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ 3. ACE CWT: https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ 4. AOB. I will send out the meeting information later. Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Li Kepeng =C8=D5=C6=DA: Saturday, 16 January, 2016 2:37 pm =D6=C1: "Ace@ietf.org" =B3=AD=CB=CD: Hannes Tschofenig , Hannes Tschofenig , Kathleen Moriarty , Stephen Farrell =D6=F7=CC=E2: [Ace] Doodle for ACE virtual interim meeting Hi all, To speed up our progress, Hannes and I plan to have a virtual interim meeting in the end of Feb or early of March. According to our discussion results on the virtual interim meeting, editors can make updates for the drafts before our next F2F meeting in Apr. We proposed four options for the meeting time: 1. 24th Feb, Wednesday, GMT 14:00 ~ 15:00. 2. 25th Feb, Thursday, GMT 14:00 ~ 15:00. 3. 2nd Mar, Wednesday, GMT 14:00 ~ 15:00. 4. 3rd Mar, Thursday, GMT 14:00 ~ 15:00. Please indicate your available time from the doodle poll: http://doodle.com/poll/gcswyngw9hr7573e The initial agenda could be: 1. ACE Actors: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ 2. ACE Oauth Solution: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ 3. AOB. If you have any additions, please let us know. Thanks, Kind Regards Kepeng & Hannes _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3536646338_386148 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
According to the doodle results,= the time for our virtual interim meeting will be: 2nd Mar, Wednesday, GMT 1= 4:00 ~ 15:00.

I also received a request to add the = CWT draft, now the agenda will be:
1. ACE Actors:
<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ace-actors">https://data= tracker.ietf.org/doc/draft-ietf-ace-actors/
2. ACE Oauth Solut= ion:

<= div>I will send out the meeting information later.

= Kind Regards
Kepeng

=B7=A2=BC=FE=C8=CB: Li Kepeng <= kepeng.lkp@alibaba-inc.com>
=C8=D5=C6=DA: <= /span> Saturday, 16 January, 2016 2:37 pm
= =D6=C1: "Ace@ietf.org" <Ace@ietf.org>
=B3=AD= =CB=CD: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Kathleen Moriart= y <kathleen.moriarty.ie= tf@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
=D6=F7=CC=E2: [Ace] Doodle for ACE virtual interim meeting
Hi all,

To spee= d up our progress, Hannes and I plan to have a virtual interim meeting in th= e end of Feb or early of March.

According to our di= scussion results on the virtual interim meeting, editors can make updates fo= r the drafts before our next F2F meeting in Apr.

We= proposed four options for the meeting time:
1. 24th Feb, Wednesda= y, GMT 14:00 ~ 15:00.
2. 25th Feb, Thursday, GMT 14:00 ~ 15:00.
3. 2nd Mar, Wednesday, GMT 14:00 ~ 15:00.
4. 3rd Mar, Thur= sday, GMT 14:00 ~ 15:00.

Please indicate your avail= able time from the doodle poll:

The initial agenda could be:
1. ACE Actors:
2. ACE Oauth Solutio= n:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
3. AOB.

If you have any additions, please let= us know.

Thanks,
Kind Regards
= Kepeng & Hannes

_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3536646338_386148-- From nobody Tue Jan 26 09:12:42 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E781A9082 for ; Tue, 26 Jan 2016 09:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DZNrR5V-ZAF for ; Tue, 26 Jan 2016 09:12:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DFC1A002A for ; Tue, 26 Jan 2016 09:12:27 -0800 (PST) Received: from [192.168.10.131] ([12.147.0.33]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MPE7E-1aSX0a2r5M-004Qck for ; Tue, 26 Jan 2016 18:12:25 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56A7A8FD.7080806@gmx.net> Date: Tue, 26 Jan 2016 18:12:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pU6XpFoXLRk3oLBcRH0CDex4CKJrBsIH8" X-Provags-ID: V03:K0:VGJRfA0PZZIahsUFvCdbS64fNc07X4RuvhaTQ9IaKvWzmw4+DS1 0FBn4ZHGPYxKAqnT7f/laYhomyckdTmuqXMjVyaIFePmath7tDLjxaTvxcl+kG4IODnQSJ+ OWhlGC5Q2PS+8L2Bips3+r2dnF2yZvR4mpbdsLX9U/p4aYXm0iT9HzBIlZZJqGRsRsreN1y g1x7NHngo6pv/QEDRirjA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kn6JPV0SwNc=:aSg4QecgjTWvCNPWHPXU+I Y/5GhqCHdQdGZ6UDktLIR6QXnJYHoKQXd/4/puqPyGd+Roowk3s8E/NCbI13Yw5ny/XJybLcW 9AkxhYQqxv9NHVVgZovb8d6xxzGO3B8B74xvBUCcIBtSd6X3XHUJU7LjzJsMRW4vKu9TpKSlB EaeJqSbVzttOOFAAbv5RA9UskdIewmLtrqMJQii6pe2p3iv5NHzgvlLcm2x5+lwUhBVJQv7PO lw5vnTGvCAs+BgR/DTlNaxzeXtPYxWLPy+PBRglUGsDnoY9pDwwG3OXvHLVC7kf3QxSsvyG0e 4OAPdSxH5IRXZjbQ3oK3Y0e4gvuddGEAZuX8QnBlHSOJNVh5OlF0VRJZySkA3lpnenhx6UeoK sfStX+auLsVg0YO0yYUehC9T31sVRz+06IwPfZRdwAVUZkYj0BEFkoZ05g0/ncRNAdjZF0Ew/ l4G9AVGdVQoV3ct+SiekX674VI1X+M/gn84N7/P74Kp0Y4ubs+/r2zpvv1DbFHCplqq8HjseX EqSApSbliOD940VMASbKqTcWyw71S+M6UEUZm7BsmspkPwa6X4sNdAY2g7EujlUmMn9BV877o nVdx0LQ3jbfKnA0Z82i9SzBJ0wFkfbb/5qNbAqezMTqLfWMIgb6E73MpY6BehKmzFQQPyyBtd R81NuFAQSFeA/LZ89qKqKTnoUuR1ZCFq3/ovrgnx68/N4xIIoWlNaObnrkRL46hnkqKINRzYn 0xrTWO/+XbdEK70oHKJfZMkeAmYpPZPnp4ek19bFU3cuLHmzfNsvtjb7G5w= Archived-At: Subject: [Ace] Conference Bridge Details: ACE Virtual Interim Meeting -- 2nd March 2016 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:12:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pU6XpFoXLRk3oLBcRH0CDex4CKJrBsIH8 Content-Type: multipart/mixed; boundary="------------030107020100020604000008" This is a multi-part message in MIME format. --------------030107020100020604000008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are the conference call details. ACE Interim Meeting Wednesday, March 2, 2016 4:00 pm | Europe Time (Berlin, GMT+01:00) | 1 hr Join WebEx meeting Meeting number: 649 246 728 Meeting password: 6X2upMdh Join by phone +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 246 728 Toll-free calling restrictions, see http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dm69889072a7c3018065fe789b58cc6d6= 1 ----------------------------------- Agenda: 1. ACE Actors: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ 2. ACE OAuth Solution: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ 3. ACE CWT: https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ 4. AOB. --------------030107020100020604000008 Content-Type: text/calendar; name="WebEx_Meeting_ACE.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting_ACE.ics" BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe Time BEGIN:STANDARD DTSTART:20141001T030000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:Standard Time END:STANDARD BEGIN:DAYLIGHT DTSTART:20140301T020000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:Daylight Savings Time END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN=3D"ACE Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAI= LTO:ace-chairs@tools.ietf.org ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com DTSTART;TZID=3D"Europe Time":20160302T160000 DTEND;TZID=3D"Europe Time":20160302T170000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1453827766 UID:811e05b8-0fc1-4096-8c88-776227c52c4f DTSTAMP:20160302T150000Z DESCRIPTION:\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3D= m3d375c193cf8d06514445ebc5f67ba4f\nMeeting number: 649 246 728\nMeeting p= assword: 6X2upMdh\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free nu= mber (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess= code: 649 246 728\n\nToll-free dialing restrictions: \nhttp://www.webex.= com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Contact = support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Plea= se note that this WebEx service allows audio and other information sent d= uring the session to be recorded, which may be discoverable in a legal ma= tter. You should inform all meeting attendees prior to recording if you i= ntend to record the meeting.\n X-ALT-DESC;FMTTYPE=3Dtext/html:  
Host key: 100668 
 
 
Join WebEx = meeting
Meeting number: = 649 246 728 =
Meeting password:6X2upMdh
 
 
Join= by phone 
1-877-668-4493 Call-in toll free number (US/Can= ada) 
<= strong>1-650-479-3208 Call-in toll number (US/Canada) 
Access code= : 649 246 728 
To= ll-free calling restrictions  


 =
Can't join the= meeting? Contact support.   
IMPORTANT N= OTICE: Please note that this WebEx service allows audio and other informa= tion sent during the session to be recorded, which may be discoverable in= a legal matter. You should inform all meeting attendees prior to recordi= ng if you intend to record the meeting. SUMMARY:ACE Interim Meeting PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --------------030107020100020604000008-- --pU6XpFoXLRk3oLBcRH0CDex4CKJrBsIH8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWp6j+AAoJEGhJURNOOiAtL7IH/RUG+jQ50lkCopfPD4hrloBI zBgh7AG/iOOZKrkrrvmJqn0NOmwAOUeoylO6MI5cs4mD4Hw2g5WrwitXQPviL6K3 o9rqcTxYvO7YysTQMetSGnZRGYj9eFKt3girc2qfoIA10p9hujcPISa27tpMOxh8 4JRFC8n+jZBzl67p0qu3OBnHt4wx//LZ4hNo6W8cAMC+UjKPz3BioH86DLlGPRiR hQDgNO9AzK9jU8/il3g7DSU92pj1FpiXPa/re3XEYVfMlVb7/P40Uzrvc+m+Coay eRx3VNES68ajPWKAWT5fz6QrI2LUIMtFmSiJfxfLRjxkhh8uGGA4+fd3MbTFQsQ= =dFjf -----END PGP SIGNATURE----- --pU6XpFoXLRk3oLBcRH0CDex4CKJrBsIH8-- From nobody Tue Jan 26 12:00:41 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A241B2D30 for ; Tue, 26 Jan 2016 12:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km-2TXU27Yu6 for ; Tue, 26 Jan 2016 12:00:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2448E1B2CD8 for ; Tue, 26 Jan 2016 12:00:18 -0800 (PST) Received: from [192.168.10.131] ([12.147.0.33]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MNYxW-1aUCSg0ysM-007AC8; Tue, 26 Jan 2016 21:00:09 +0100 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Rafa Marin Lopez , Renzo Navas References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56A7D04B.9000302@gmx.net> Date: Tue, 26 Jan 2016 21:00:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xa4CiCfB3TkOQWKjte7jbK7wfFWd8DbCN" X-Provags-ID: V03:K0:FL48UhPuScxtuRHYHgnTBaaePL+p03RE099ytIgfxExOlgExFYg RqW0V94jo2Y1/X4QJMfZNMlOiTdhoo75soS5cr19nFgsV/zrP5SAcCMMf2bDb5xXlYTgNcS HFYPVqYaVkeaN1XfJcsQfinuUErIeZIx2ILwHbQTV+pu5accWz7LhhkwZqrL8LNmx4l9izn J/RuYBt4MUgJ70JIGa0UA== X-UI-Out-Filterresults: notjunk:1;V01:K0:C3DshsCDwAo=:CJQzIWTCmfzbkxj8AUQLB2 LTVTBLibcb8YqSuKT1eouhOR7Vl68zhHoPnUodyjRBmzS/PCNVLvRPSFPJ0R+k7a4+v0UxO7a /sRmpsbLJfEg7aZjO4xLUaoQQXanS2ncgzewPoV5CtZgHgXXV3ZyaFJ7CIoq+EPVbJcVr0l7W S3Waf06ZvrKZJon08JQzLMIdO7lu6tgrt57FiiK7nuE7XwF4p73pSJ3zRbmWWrJthOoBcGzKB DvvtJjOGlnhVAPdnW+d5xxO3+S0NrtdrGqrSLpySJ1qHYdzKAI8+z4w4YRSJ8UqYmVfFhy+5W aJAwDSEOAF3cHUz5NqiQ9dNETRAOQV2+HibWggzzBE4eaftp8ldi0kVhDSHZXvU+LXew8SzqN v7OLqE6tA867psks9eG/z1s9hw8khClO3TcY7J9O9llAdhElRdNdJEYFQyMVj7VlGkhEY/oqE pT52KDPAQ3so8LFQgtvBc4CYRVMipzigZ5Xj4gApeDYT6jejMr7j+Y4AE+HSoJzg6CfoXgf0G KCZrar5ILJ/fTu6BZ49AmAlnUCZVjMloJUzWY8aZdmxSXyuZ/bIkVWsIy/GRBkpqyiCTOvLEw FiJYvLuO3daMa4HLHnAK9Ldz5vGF4qDeFlbv6zIK9GKYWLTRjAP8za0IGWNTkYmadvKkBvVgo mFG/lfN+fNqmVuooRTaFzS5WOKRJlkphVtw+rN09BE9YrOgkJ5J6NY+PdO/aCSE5E3w3YkWfN SDN+3P0elJXDPFF1nmnLu0sq8VeHp8CQUahBeC613CaeZEDvNg0M3920lM0= Archived-At: Cc: ace Subject: Re: [Ace] Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 20:00:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xa4CiCfB3TkOQWKjte7jbK7wfFWd8DbCN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, thanks for your response. On 01/21/2016 06:40 PM, G=C3=B6ran Selander wrote: > Hi Hannes, >=20 > Good discussion input, some comments: >=20 > You write certificates, but CoAP also support raw public keys and > pre-shared keys. For these cases there is not necessarily time related > information, is there? It is true that with raw public keys and pre-shared secrets the situation is a bit different. Nevertheless the requirement for time information still does not necessarily disappear since there is still the access token that may contain claims like issued at, not before, and an expiry date. >=20 > If the use case does not allow the RS to be online with AS or time serv= er > at all times (for reasons of connectivity such as container use case et= c., > or for reasons of communication budget) then you are right that it may = not > be possible to verify change of permissions and revokation. Correct. >=20 > But still it may be possible for the RS to: > - invalidate short lived access tokens (counting down using internal cl= ock) > - verify that access tokens are not replayed (using nonce or sequence > numbers) > which is sufficient in terms of timely authorization in some cases. Access tokens don't contain sequence numbers or nonces since otherwise they will become on-time-tokens. Using an "internal clock" is not sufficient since such a real-time clock needs to have a reference to know whether a "short lived token" is indeed fresh. >=20 > Furthermore a client may have access to the AS even if the RS doesn=E2=80= =99t, and > through a new access token provide fresh information to the RS. (The RS= > would in this case not know that an access token is recent, but in case= of > sequence numbers that it is more recent than previous.) It is indeed possible that the client may have access to the AS but you are in essence suggesting * one-time-tokens, and * keeping state (such as a sequence number) at the RS. >=20 > I think we should support deployments which does not require RS to keep= > external time, and accept that those deployments will not be able to > support immediate revocation. The problem is that it come for free. So, we need to make an informed decision. For that reason I am reaching out to folks in this group to determine whether there is indeed interest in deploying such solutions. Ciao Hannes >=20 > G=C3=B6ran >=20 >=20 >=20 > On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig" > wrote: >=20 >> Hi Renzo, Hi all, >> >> thanks for your review comment since you raise a bigger issue. The >> review feedback was recorded as issue#12 at >> https://github.com/LudwigSeitz/ace-oauth/issues/12 >> >> You are asking what our requirements for the Resource Server (RS) are >> with regard to the availability of time information (and the accuracy = of >> it). Our solution building blocks currently require time information, >> such as certificates and access tokens. >> >> In your email write-up, see >> http://www.ietf.org/mail-archive/web/ace/current/msg01554.html, you >> correctly pointed out that there is a relationship with the validity o= f >> the authorization information and with a potential revocation mechanis= m. >> >> Before we start working on solutions I would like to get a sense of th= e >> group what the views are. For resource servers do you consider to >> incorporate a real-time clock and a protocol mechanism that obtains ti= me >> information? >> >> Not having time information at the RS will have the following impact: >> >> * The RS somehow has to get information about access tokens where >> permissions have changed, where the access tokens have been revoked or= >> have otherwise been invalidated since the tokens do not contain validi= ty >> information. >> * Time-related information in certificates cannot be checked. >> >> In many situations we will have a tradeoff between the availability of= >> time information and the required communication overhead for interacti= ng >> with an authorization server to obtain up-to-date information about th= e >> validity of the credentials. >> >> What does the group think? >> >> Ciao >> Hannes >> >> >> On 11/19/2015 10:19 AM, Rafa Marin Lopez wrote: >>> Hi Renzo: >>> >>> I agree with you that if we consider the distribution of a symmetric >>> key between three parties the literature is full of very concise and >>> security proven protocols. >>> >>> Please count on me if some help is required in this area. >>> >>> Best Regards.=20 >>> >>> >>>> El 13 nov 2015, a las 17:30, Renzo Navas >>>> escribi=C3=B3: >>>> >>>> Good Evening ACE ML, >>>> >>>> Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for ea= sy >>>> to read doc) I was very interested by the PoP token that offers an >>>> authenticated fresh key to be used for further secure the comm., >>>> but I saw a very strong requirement for the RS to have a Time Sync. >>>> mechanism. >>>> I preview the objective of my mail, is to raise the question: >>>> >>>> * Do we want to have a strong requirement for the constrained device= >>>> (RS) on an AA Architecture to have a Time Synchronization mechanism?= >>>> * Are we interested on offering non-time -nonce- based solution for = an >>>> OAuth PoP Token approach (for example when the token does not expire= )? >>>> >>>> >>>> (those interested on those concerns can read the rest of the mail, >>>> that is rather long) >>>> >>>> Regards >>>> >>>> ------------------------------------------------------- >>>> >>>> (Long version) >>>> >>>> I've been working lately on the Authenticated Key Establishment >>>> problem (The are two very good reference books [1][2]), focusing on >>>> solutions with a Trusted Third Party, Symmetric Crypto, and not usin= g >>>> Time-stamps but Nonces (To avoid having to deal with time >>>> synchronization).I have no strong Crypto background. >>>> >>>> First I want to thank the authors of draft-seitz-ace-oauth-authz-00 = , >>>> very enlightening for the oauth neophytes. >>>> I'm mostly interested on the authentication problem (auth. key >>>> establishment), so the Proof-of-Possesion Token is a great >>>> tool/concept, I took the time to read >>>> draft-ietf-oauth-pop-architecture-05 and >>>> draft-ietf-oauth-pop-key-distribution-02 to try to have all the >>>> background possible. >>>> >>>> So from the Authenticated key establishment mechanism point of view = a >>>> new fresh key between C and RS obtained by means of a PoP Token >>>> mechanism -I think- will be similar to a Denning-Sacco shared key >>>> protocol (=20 >>>> http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html >>>> . Client is A, AS is S, and RS is B), with the difference that the P= oP >>>> Token Timestamp have a start and end value that will make the >>>> "mutiplicity attack" of Denning-Sacco limited on time. >>>> >>>> My concern is that we will always need Time sync on the RS, that som= e >>>> (most) times will be the constrained node (I think that the Client >>>> does not need to be Time-aware), is that a MUST requirement? So >>>> no-time aware devices will not be able to use OAuth PoP Token (or wi= ll >>>> have to use token introspection, a good fallback solution btw) >>>> >>>> Will be of interest offering a PoP Token generation and transport >>>> mechanisms that offers an authenticated fresh key without the need = of >>>> Time-awarenness at the RS? >>>> >>>> Time awareness at the RS offers great advantages, and maybe also Tim= e >>>> is always needed in all authorization solutions (to make easy token >>>> expiration and freshness claims). >>>> >>>> But I'm thinking about nonce-based authenticated key establishment. = Of >>>> course without time information embedded on the token, token >>>> expiration will be more difficult: >>>> * we will need token introspection, or >>>> * the AS will contact the RS to revoke tokens, or >>>> * we will need on a non-time based solution for revocation that does= >>>> not involve the AS, for example: a pop token/key is valid for use on= ly >>>> for one (or N) Resource Requests (of course if the response message >>>> get lost we are screwed...) >>>> >>>> >>>> So maybe we cannot avoid to have Time-awareness at the RS, for >>>> Authorization purposes.. >>>> But for Authentication certainly we can avoid Time, the three most >>>> recommended by [2] nonce-based protocols are: >>>> * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven= >>>> provably secure on the strongest model to test auth. key establishme= nt >>>> protocols ] [3] >>>> * Yahalom [a modified version has been proven secure on a weaker mod= el >>>> -bellare rogway- than 3PKD] [4] >>>> * Boyd [Key Agreement: RS, C and AS contribute inputs to generate th= e >>>> key] [proof idem yahalom ][5] >>>> >>>> The message flows on that three of protocols do not respect OAuth >>>> flows (I attach an image with the high level message flows, A is the= >>>> initiator always), so that take us apart a bit from OAuth... >>>> >>>> This mail is starting to get long so I will try to conclude it, but >>>> hopefully raise the question: >>>> >>>> >>>> ** Are we interested on offering non-time -nonce- based solution for= >>>> an OAuth PoP Token approach (for example when the token does not >>>> expire)**? >>>> >>>> >>>> >>>> If NO, I guess that will need token introspection for RS that cannot= >>>> support time (That mechanism will map to other authenticated key >>>> establishment protocol and not Denning-Sacco-based ) >>>> >>>> if YES, are we interested in adapting a nonce-based auth. key >>>> establishment protocol to OAuth PoP Token? >>>> >>>> >>>> I hope this questions are useful, >>>> >>>> Best regards >>>> >>>> Renzo >>>> >>>> >>>> >>>> [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key >>>> Establishment and Authentication. Springer-Verlag New York, Inc., >>>> Secaucus, NJ, USA. >>>> [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.). >>>> Springer Publishing Company, Incorporated. >>>> >>>> [3] 3PKD -=20 >>>> http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pd= f >>>> [4] Yahalom - https://eprint.iacr.org/2007/188.pdf >>>> [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf >>>> >>>> ________________________________= ____ >>>> ___________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> ------------------------------------------------------- >>> Rafael Marin Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>> ------------------------------------------------------- >>> >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >=20 --Xa4CiCfB3TkOQWKjte7jbK7wfFWd8DbCN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWp9BLAAoJEGhJURNOOiAtPjkIAJmjNMKHkNrVnY6VVsyisSCK UlpiN3vpdwQkMzka8WAxY8vAwVy5mE7T9yUri4wE2wZgd4/6zk526ziwg2punbVU cG8437qyx1OdX1JhTuRR+ruo4OwGvgegu9H7AUbjug6s5K5QM4gnWGwK6kbyrhJw 69Mx4ESylmfjVBQix5RZ76GH2Xt+52lIguSGb1sOqSeML1wxuJ/Bt/PS5f83DWxz pv3OwRhs1uBxEcYpi2DMmyT4+yiDUfz7gSahinFXObL9w2Ao6Z4mMkOTZn45l3KL rWsTVdZOAuELwZOQttNU6/2lNmH8rTB4l3amqCbyvtHojvyqz8N1i51evDjK/j0= =og/C -----END PGP SIGNATURE----- --Xa4CiCfB3TkOQWKjte7jbK7wfFWd8DbCN-- From nobody Fri Jan 29 18:03:54 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E2E1A8BC5; Fri, 29 Jan 2016 14:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dmh2dtQ18DY; Fri, 29 Jan 2016 14:36:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F8D1A8F3D; Fri, 29 Jan 2016 14:36:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8DE9B180471; Fri, 29 Jan 2016 14:34:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160129223427.8DE9B180471@rfc-editor.org> Date: Fri, 29 Jan 2016 14:34:27 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 29 Jan 2016 18:03:51 -0800 Cc: drafts-update-ref@iana.org, ace@ietf.org, rfc-editor@rfc-editor.org Subject: [Ace] RFC 7744 on Use Cases for Authentication and Authorization in Constrained Environments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 22:36:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7744 Title: Use Cases for Authentication and Authorization in Constrained Environments Author: L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar Status: Informational Stream: IETF Date: January 2016 Mailbox: ludwig@sics.se, gerdes@tzi.org, goran.selander@ericsson.com, mehdi.mani@itron.com, sandeep.kumar@philips.com Pages: 30 Characters: 72630 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ace-usecases-10.txt URL: https://www.rfc-editor.org/info/rfc7744 DOI: http://dx.doi.org/10.17487/RFC7744 Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally. This document is a product of the Authentication and Authorization for Constrained Environments Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Jan 30 13:48:29 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33F01ACD7C for ; Sat, 30 Jan 2016 13:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGFxsOMONEyW for ; Sat, 30 Jan 2016 13:48:25 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29C91ACD7D for ; Sat, 30 Jan 2016 13:48:25 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id 6so91849901qgy.1 for ; Sat, 30 Jan 2016 13:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=5zGQZiL9y7lfhP7OyvwnDitG54/2FEKB3w8dKYK9pnk=; b=lCr72zxKhozoKt6vpag9paURcZixPGWC6GqAkrYUPNa9NVVdGu91AblL7Hq0ck4KT0 RCK6fNjKNjMxax1cPxf9dO1yFCWPbmKGnUgbhy05lL+8N0JEHj58KHqIc/1S/iJ8M70r AgiaPe59VkkI0Pu7d3rwjmt5gpYlqU5thn+5/CB3JFXnDZBYxNJpSRiGHaWkzLgq0x/0 Ll7j4aX/lfGWz7ZxO0RCp0x49st3HIEsy0d1Hz8ckhQCmUfkeGcFa66GBELh2Q+XRDdr /lYk5+OdodCFL6s2LZoEQA12YqnadR9nu5WMJ/qnK4/pfOp4jMWuJJb9EZRHKf82C55F DVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5zGQZiL9y7lfhP7OyvwnDitG54/2FEKB3w8dKYK9pnk=; b=M3ufgCaLmFHLrHVzQ4NOumSPatXLNUkiqHEljmvxJ5rmX+fjjj5IQhTrbS3tVzf7AP uD8i9+8yROc18gsTY0HUncUgPtdgtWjJP2VTqOSYhC33gan5j9iFwZM3WMPI05QKkSkb S/jwTv0Ik9vqwThG7RiVgrBpbg1yOOQUpCFTIb+S3BHQUwjbNrkPmn6Xo7mb2evkQ7li BUo3HVBZYEVk/MZ0XOKUWtPwTiutP2rd1lz/PP2c9kOIVGa4wbqs4Mj2tUthMHGAaaE5 w8n57QvcIb7OySOXmcRSD4Bh8mS43vXMg9jiEYQNgbJ8yThCupeZRVKpry9eRGhzoiwF VmmQ== X-Gm-Message-State: AG10YORBvkerxWzFToyiFQJHYktlweECFg5zHIYFVWFQvNx0Xd0PHNQrIqqN0RlcHJu4fGNUs/XmQ9f4z8sGnA== MIME-Version: 1.0 X-Received: by 10.140.38.73 with SMTP id s67mr19595589qgs.82.1454190504204; Sat, 30 Jan 2016 13:48:24 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sat, 30 Jan 2016 13:48:24 -0800 (PST) Date: Sat, 30 Jan 2016 22:48:24 +0100 Message-ID: From: Samuel Erdtman To: Ace@ietf.org Content-Type: multipart/alternative; boundary=001a11c1274c7083a8052a941c91 Archived-At: Subject: [Ace] CoAP option for Access token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 21:48:27 -0000 --001a11c1274c7083a8052a941c91 Content-Type: text/plain; charset=UTF-8 Hi, Working on the draft-ietf-ace-oauth-authz draft I see the need for a CoAP Option to send access token in. This option can be used when token is smaller then 255 bytes. Then it comes down to the trade-of between sending the access token once to the authorization information resource at the RS and sending it in each request as this option. Can we agree that we need this option? Should we call it Access-Token or is that to specific? Best Regards //Samuel --001a11c1274c7083a8052a941c91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Working on the=C2=A0draft-ietf-ace-= oauth-authz draft I see the need for a CoAP Option to send access token in.= This option can be used when token is smaller then 255 bytes. Then it come= s down to the trade-of between sending the access token once to the authori= zation information resource at the RS and sending it in each request as thi= s option.

Can we agree that we need this option?
Should we call it Access-Token or is that to specific?
<= br>
Best Regards
//Samuel

--001a11c1274c7083a8052a941c91-- From nobody Sun Jan 31 23:52:18 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8231A6F68 for ; Sun, 31 Jan 2016 23:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_DELETE=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTy3vreNOI-7 for ; Sun, 31 Jan 2016 23:52:13 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B021A6F62 for ; Sun, 31 Jan 2016 23:52:13 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id dx2so69725858lbd.3 for ; Sun, 31 Jan 2016 23:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=1ZbnxwlX1XeAJ5TCwqll6Zc+vxMEZbeHeIe5ODnYecc=; b=wJxFMOlwmE5Hdz613v9fzQeWkKRU38D82rnIu1SY+eogqqGWHT+16oLS8/UOFia/zG w0xPEIpcs7brm7Zl5HwNBtbvsIyDFzoJxYa5H5RyqGoWwGWNCuy3jiisOm+u7l6nG5UR ThsIq/xZkg6oa0BVLDGrEm/ulomf2+iriB08fpgBkC89uuenViKlDuRrVkNKEtcx75/c b39IYlTSGQ3+e689ask+TvhFiAXiNHZhgghtE5MoAP6hBNUSQ7KwaBvaFUu7W7KyLkAO qXBnAHvrpvQXeIR38GWIr5qJrJ3goqkMpReFJBnFSsm3ai0DY5EEkQkG/XgI+IWHG0Bi 4bsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=1ZbnxwlX1XeAJ5TCwqll6Zc+vxMEZbeHeIe5ODnYecc=; b=HOkVGk9FEmI2WW6+Ru/w/tNBy5hO8YKD2MkVmdKW0eq0yY/4siJAIMwh5obdj2NVpg twnG2o0+bCHPQCfNvDxO4kcFraWqfNQDXwCougBvHNStMt3egpiQmm9WAxHC8ZPoCcEs VFsU3YVrHdodhGMHlrI2XykSgGqf21y0oAT1AxCEpM7ca819emJonfqoGT7KtS90xZIa OJbYLHpNvYSfEiuKTEn+vcBbEYGLGd7Wv7zLVxfayRK+aXwtATsrCKrtxdG4YPA4LfSB g+D0nT8iRnXnhR80wAIP5UfCySB2hpH1TqVZeUrsD/84IKkvT24gz2iYboOx5xJTurYb EzSQ== X-Gm-Message-State: AG10YOShqc9qHkSixgA9Cj7u9jzCdtwC6tivKIFpdJ+OOm+hyiHOwhFA+ruwfJzP4xzfrYi0 X-Received: by 10.112.149.230 with SMTP id ud6mr7692337lbb.12.1454313131145; Sun, 31 Jan 2016 23:52:11 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id y63sm3925963lfd.10.2016.01.31.23.52.10 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jan 2016 23:52:10 -0800 (PST) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: <56AF0EA9.40309@sics.se> Date: Mon, 1 Feb 2016 08:52:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060802040602000709000803" Archived-At: Subject: Re: [Ace] CoAP option for Access token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 07:52:17 -0000 This is a cryptographically signed message in MIME format. --------------ms060802040602000709000803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 01/30/2016 10:48 PM, Samuel Erdtman wrote: > Hi, > > Working on the draft-ietf-ace-oauth-authz draft I see the need for a > CoAP Option to send access token in. This option can be used when token= > is smaller then 255 bytes. Then it comes down to the trade-of between > sending the access token once to the authorization information resource= > at the RS and sending it in each request as this option. > Wouldn't it still be possible for the RS to save a token sent in an optio= n? Would it then not be possible for the client to remember that it already = sent this token in a previous request (and that it is still valid)? Would the client then not be able to omit it from further requests=20 (until it is no longer valid)? The real trade-off is a bit more complex: 1.) You can use blockwise to fragment large payloads 2.) If your token is large you'd therefore rather send it as payload 3a.) Not all requests have payload (GET, DELTETE) 3b.) The application needs to know that the payload contains a token 4a.) Either you mix the token and the real application payload and as a=20 benefit you can send both together in one request (provided the type=20 supports payload) ... 4b.) ... or you separate the token-payload from the real application=20 payload (which may not exist) and send two messages, where the token=20 message needs to go to some resource that understands that this is a toke= n. Voila! This is the trade-off tl;dr: Trade-off is: Mix token and payload and have the app-logic deal=20 with it, or separate them and create a resource that processes tokens. > Can we agree that we need this option? I agree. > Should we call it Access-Token or is that to specific? Access-Token sounds indeed reasonable. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se --------------ms060802040602000709000803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDEwNzUyMDlaMC8GCSqGSIb3DQEJBDEiBCCJ30YVcrI7KaRh DWAyFjrsOl4wpyzZaVft1g06NktDkDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAaWqv9RaBEK9r8w7eiVUp9t9ZL +g35Yxm4tjgbClyRxYW4VTjOHwSL0PFgWPA119C2HYVSZM3NTL5lXEj7jTVudHgCXpAbW32B Y4fxfcOPM3xmM9r9seJag7QTlIZAfsmcRpBbQnVKlurgakA4uunqC7DyxOrKDQY0uNJRWXVk pjozvIrtGg98WyQIE3G9tgDn/XnfFtcF6/bkSh60s58FXUOicuZy61eDKL/XBHRxKkpmT3+Q 9Prx19PnxlFGjor4aW2PrmrVtaS/QAlHBjRWgMNXbMGauJGfP5H3l2Xyd9amT0x19fv/qP+n q9kXY+YyNmRHDzmPP9lDVkLtPrY4AAAAAAAA --------------ms060802040602000709000803--