From nobody Mon Oct 10 00:02:23 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0AF129413 for ; Mon, 10 Oct 2016 00:02:22 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.onmicrosoft.com 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 y97D6a6_yfOj for ; Mon, 10 Oct 2016 00:02:19 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50102.outbound.protection.outlook.com [40.107.5.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F7B128E18 for ; Mon, 10 Oct 2016 00:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ascuhtNPOUc2jzifIIN9eGiM3Xb9ZQJg7OWc1ZEPtzg=; b=oAlvC1blL1oiUwCXMuIA7WBiZUGQmyAv0lkM5aavg5vS4JPEOxu0TxgHjZoosiwCqZpWvNkXZo4s4R9ewFOe6ZmkHoPneuSpfLGLZkfzrJhs1grtX4c9Ckkdib1MV/zJfy+eGi6Zj+b9KKOuNv8W20MnpJ/alZl2EClxtLwMTo4= Received: from DB6PR0601MB2198.eurprd06.prod.outlook.com (10.168.57.139) by DB6PR0601MB2200.eurprd06.prod.outlook.com (10.168.57.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Mon, 10 Oct 2016 07:02:14 +0000 Received: from DB6PR0601MB2198.eurprd06.prod.outlook.com ([10.168.57.139]) by DB6PR0601MB2198.eurprd06.prod.outlook.com ([10.168.57.139]) with mapi id 15.01.0649.027; Mon, 10 Oct 2016 07:02:13 +0000 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: draft-ietf-ace-oauth-authz-02 Thread-Index: AdIiwSPofEKafDkbQoO7BUP/zlfzfg== Date: Mon, 10 Oct 2016 07:02:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abhinav.somaraju@tridonic.com; x-originating-ip: [146.108.200.99] x-ms-office365-filtering-correlation-id: 85fd829d-8ff7-4095-bb96-08d3f0db5cf6 x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2200; 7:cM47vyjqkm2DtKdhWRYrFrtvX4GlX1JpwfRgZW3efOLqwsQKwSEIPMk8uutcraFc20JuSmeWSevRExxEYBLsM036JZJEtsPFHCfoEMlqvjJnbwW+QRZAwdE7yQZRTMPkvSdjT1xslgAm01aDKkt8Tme2p39SWwgePIP7V8PykbgwAOKpFHm5iIsvKo5kXlXjgRohypOnuQaESpKtFFcErsAmJZEJ1nBKD2LjXUU0q7vKAexBtEDvP4iVEBcE0VaFLoQpveuratkwPw4cFIxDJVorQrpRpEfJoNR5DiS3J0dqNe+qjyiCJvPUWpYABwraQ9I5LLV5iWlzMiauqhZVDyz09DlRr3t2kC4UiLq3jvg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2200; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(271806183753584)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DB6PR0601MB2200; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2200; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(3280700002)(3660700001)(7696004)(2501003)(5890100001)(92566002)(19300405004)(106356001)(230783001)(76576001)(5660300001)(105586002)(229853001)(19580395003)(2351001)(122556002)(15975445007)(450100001)(77096005)(7846002)(7736002)(86362001)(9326002)(9686002)(81156014)(8936002)(8676002)(1730700003)(81166006)(5002640100001)(5630700001)(2900100001)(6916009)(107886002)(68736007)(2906002)(19625215002)(87936001)(97736004)(5640700001)(33656002)(101416001)(6116002)(110136003)(10400500002)(102836003)(3846002)(586003)(790700001)(74316002)(54356999)(189998001)(66066001)(50986999)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2200; H:DB6PR0601MB2198.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: tridonic.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0DB6PR0601MB2198_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 07:02:13.5417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2200 Archived-At: Subject: [Ace] draft-ietf-ace-oauth-authz-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 07:02:22 -0000 --_000_DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0DB6PR0601MB2198_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have been looking into this draft, which is very well written, and I woul= d like a clarification regarding the workflow in figure 1 of the draft. This workflow is a bit different to the typical one I imagine for constrain= ed clients/servers. Such devices would typically be provisioned from some k= ind of a commissioning tool and the tool would also initiate the provisioni= ng process. Therefore, would it not be better to have a protocol flow that = is not necessarily initiated by the client device? I show two options below= . In Option 1, the Resource Owner would be a commissioning tool and in Opti= on 2, the Authorization server would be the commissioning tool. In the prot= ocol flow in your draft, I will need a proprietary method to generate the t= oken request message from client to AS. OPTION 1: +--------+ +---------------+ | | | Resource | | | | Owner | | |<-(A)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(B)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(C)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(D)----- Access Token ------>| Resource | | | | Server | | |<-(E)--- Protected Resource ---| | +--------+ +---------------+ OPTION 2: +--------+ +---------------+ | | | | | | | Authorization | | |<--(A)-- Access Token ---------| Server | | | + Client Information | | | | +---------------+ | | ^ | | | Introspection Request (C)| | | Client | | | | | Response + Client Token | |(D) | | | v | | +--------------+ | |---(B)-- Token + Request ----->| | | | | Resource | | |<--(E)-- Protected Resource ---| Server | | | | | +--------+ +--------------+ ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0DB6PR0601MB2198_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have been looking into this draft, which is very w= ell written, and I would like a clarification regarding the workflow in fig= ure 1 of the draft.

 

This workflow is a bit different to the typical one = I imagine for constrained clients/servers. Such devices would typically be = provisioned from some kind of a commissioning tool and the tool would also = initiate the provisioning process. Therefore, would it not be better to have a protocol flow that is not nece= ssarily initiated by the client device? I show two options below. In Option= 1, the Resource Owner would be a commissioning tool and in Option 2, the A= uthorization server would be the commissioning tool. In the protocol flow in your draft, I will need a prop= rietary method to generate the token request message from client to AS.

 

OPTION 1:

     +--------+&nb= sp;            =             &nb= sp;     +---------------+

     |   &n= bsp;    |        &nb= sp;            =           |   Resour= ce    |

     |   &n= bsp;    |        &nb= sp;            =           |   &= nbsp; Owner     |

     |   &n= bsp;    |<-(A)-- Authorization Grant ---|  &nbs= p;            |=

     |   &n= bsp;    |        &nb= sp;            =           +---------------= +

     |   &n= bsp;    |

     |   &n= bsp;    |        &nb= sp;            =           +---------------= +

     |   &n= bsp;    |--(B)-- Authorization Grant -->| Authorization |=

     | Client |  = ;            &n= bsp;            = ;    |     Server    |

     |   &n= bsp;    |<-(C)----- Access Token -------|  &nbs= p;            |=

     |   &n= bsp;    |        &nb= sp;            =           +---------------= +

     |   &n= bsp;    |

     |   &n= bsp;    |        &nb= sp;            =           +---------------= +

     |   &n= bsp;    |--(D)----- Access Token ------>|  &nbs= p; Resource   |

     |   &n= bsp;    |        &nb= sp;            =           |   &= nbsp; Server    |

     |   &n= bsp;    |<-(E)--- Protected Resource ---|  &nbs= p;            |=

     +--------+&nb= sp;            =             &nb= sp;     +---------------+

 

OPTION 2:

 

   +--------+  =
;            &n=
bsp;            =
;    +---------------+
   |    &nbs=
p;   |          =
;            &n=
bsp;        |     &n=
bsp;         |
   |    &nbs=
p;   |          =
;            &n=
bsp;        | Authorization |=

   |    &nbs=
p;   |<--(A)-- Access Token ---------|    Serve=
r     |
   |    &nbs=
p;   |       + Client Informati=
on    |         =
;      |
   |    &nbs=
p;   |          =
;            &n=
bsp;        +---------------+
   |    &nbs=
p;   |          =
;            &n=
bsp;            =
;   ^ |
   |    &nbs=
p;   |          =
;  Introspection Request  (C)| |
   | Client |   &=
nbsp;           &nbs=
p;            &=
nbsp;         | |=

   |    &nbs=
p;   |          =
;   Response + Client Token  | |(D)

   |    &nbs=
p;   |          =
;             &=
nbsp;           &nbs=
p;  | v


   |    &nbs=
p;   |          =
;            &n=
bsp;        +--------------+


   |    &nbs=
p;   |---(B)-- Token + Request ----->|   &n=
bsp;          |


   |    &nbs=
p;   |          =
;            &n=
bsp;        |   Resource =
  |


   |    &nbs=
p;   |<--(E)-- Protected Resource ---|    Serve=
r    |


   |    &nbs=
p;   |          =
;            &n=
bsp;        |    &nb=
sp;         |

   +--------+  =
;            &n=
bsp;            =
;    +--------------+


 


 


 


 
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_DB6PR0601MB2198FA78698DEC6CDB51D275FCDB0DB6PR0601MB2198_-- From nobody Mon Oct 10 01:24:01 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD31295F0 for ; Mon, 10 Oct 2016 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 MSB4A8r34ecX for ; Mon, 10 Oct 2016 01:23:57 -0700 (PDT) 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 A36A1129601 for ; Mon, 10 Oct 2016 01:23:56 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id x79so114154301lff.0 for ; Mon, 10 Oct 2016 01:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ISCyidsHyqcajaI+rJuxKiOfn63xrA+1ylNfbMAnOO4=; b=fDU8ZS6qTXgv++QBa7UkKfFmPpGQDTqSAqd2j+Mrs169KwqVFTZ4OZEk6+thVnICji Gh9I78ZsGamG46CzNSN0ReOCcTHM5DaV/INaCe7pRC1RhbMMzXzgS1ADhVhkxHimzE/4 bD+Yqmw0ei2ODkMy4R0mtaeyDzmBJ9IPUi5LzI/ZKDZDcioKWWTjNjCB3/+EekXiDQKz 7Z0nap0WJN689CuOyKBvLwSNT5eyQI+KX0w6gZenS+/AyXjyS7uZqXCKegyYBM0Mhc+i Ww+uYconZIGRnXQ8KaAaK6nqfO9rM8GyeKT/PFRpMTAgOmqYab9ua+9hQLKMA1v8KtGQ 9qbQ== 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; bh=ISCyidsHyqcajaI+rJuxKiOfn63xrA+1ylNfbMAnOO4=; b=QBG9B6l/S0qg6RObgiC94sc4LkQuFcl+sIeIMLy4tLaRxXgvXxCeXb2Bbxth+5BZA8 iNO9wZT7B3C2ME4fDC+8rLUHKnIEkMTU3XdB7VugikVZASSeF1rFJTuL3xdbMSCBR1N6 Q4OZGWLXv6gqc+oOq6CptnUm7ojh35R7wlSp+ln2UjEr58ZfmP0TR3sIFtiYp0WFrp7z F0nHb466CBGzqkJbzjvdJcK41/073A0dN5Co44rK65OAyoakNVB9vLZXizNE6KwEHIvR qFBO1cdkPVM9ejN9fIxGqAREub9DED7PbGR6lzsuSJFT/ln+fLmeDr2hZLS0n0Wjx9H0 1xUQ== X-Gm-Message-State: AA6/9RnfM2+r4atmCjyw0O3uHpVhVioGfnjLLYlJKjPa4YvRUtUYFY9ffji584ByFRx9oNML X-Received: by 10.25.40.74 with SMTP id o71mr13445667lfo.36.1476087834539; Mon, 10 Oct 2016 01:23:54 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id 84sm5902152ljf.33.2016.10.10.01.23.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Oct 2016 01:23:53 -0700 (PDT) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: Date: Mon, 10 Oct 2016 10:23:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030103020007010001010504" Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 08:24:01 -0000 This is a cryptographically signed message in MIME format. --------------ms030103020007010001010504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-10-10 09:02, Somaraju Abhinav wrote: > Hi, I have been looking into this draft, which is very well written, > and I would like a clarification regarding the workflow in figure 1 > of the draft. > > This workflow is a bit different to the typical one I imagine for > constrained clients/servers. Such devices would typically be > provisioned from some kind of a commissioning tool and the tool would > also initiate the provisioning process. Therefore, would it not be > better to have a protocol flow that is not necessarily initiated by > the client device? If I understand you correctly, you are suggesting to provision either=20 the grant or the access token during the commissioning process. Our idea was to use the client credentials grant instead (not shown in=20 our figure 1) and have the AS decide what access tokens to grant purely=20 based on the credentials presented by the client. This way you don't have to provision anything, except for base=20 credentials to a client. The underlying idea is that the RO would configure access control=20 policies at the AS during the commissioning procedure. The AS uses these = to determine what kind of access tokens to grant to the client, when it=20 requests one. You could of course also provision a long term access token to the=20 client during commissioning (I think we mentioned that somewhere, or at=20 least thought of it), so your proposed option 2 would also be valid, and = I think they would work just as well with the rest of the framework. I would suggest to add a step before (A) then, were the RO requests an=20 access token from the AS on behalf of the client. As for option 1, I am not sure what the advantage would be of=20 provisioning a grant to the client as opposed to using the client=20 credentials grant. Could you elaborate on that? Regards, 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 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order to create a unified institute sector and become a stronger innovation partner for businesses and society. At the end of the year we will change our name to RISE. Read more at www.ri.se/en/about-rise --------------ms030103020007010001010504 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 CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEwMTAwODIzNTNaMC8GCSqGSIb3DQEJBDEiBCAtYndQENJx IDOo19d6wP+DTy2wgSzx7KIKx3mfTv1bmDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQCdF6WUD46v0dYBCEM39DNM dq2iFBBg8UOPqc3l/mDkLg4myYsI2+LTHA9I1yMJmhCEiJ1r5WDUzCVyy6Z1zhm39c9EHYnt oAi4APCqjZldd0PTnN7FKksDIB07jAZcGi/Rf3aqkzyxag3kcGjl+IIyVP0nUpOZQxdVK3ck HWFhNoCpnoPmaShZ96p6DoZ3HOuk8Ss257kKM/nL1Ir2nCYBaV6yxTWTnHo7O4OnYaZMUHwq 5coEFz5P3yHlECxaTU30hNmamORnlyLSq31+ZDzvTrqNthY/EA/Jum/wPRBImQsi9ZGHR7pS BkPEYGOHyh4njZYTiH0PY6LMMV8k4rw5AAAAAAAA --------------ms030103020007010001010504-- From nobody Mon Oct 10 04:41:11 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9412960C for ; Mon, 10 Oct 2016 04:41:10 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.onmicrosoft.com 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 VpsOuUwE4Ben for ; Mon, 10 Oct 2016 04:41:07 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0114.outbound.protection.outlook.com [104.47.0.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEF1129608 for ; Mon, 10 Oct 2016 04:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GIt4+Euusu7X3KTyKXFBCPofofjQvULDuF12mLEoLKI=; b=KtLsnvwT0ip9tELccT6IMIkhuzcoocfOGbjKJf/iNjOddQZuN/881xgdksoQ7ald4RoQRF6j8aCMxivSn/xFUMlQubSaXqk2ZPj/We2uFI9YYWHLZ4uuXgtd8IFs1B3JWsEpcZ+JrPoQTJb0tyrZRQ5V1kcc8tWtgkNo65pEUSo= Received: from DB6PR0601MB2198.eurprd06.prod.outlook.com (10.168.57.139) by DB6PR0601MB2199.eurprd06.prod.outlook.com (10.168.57.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Mon, 10 Oct 2016 11:41:03 +0000 Received: from DB6PR0601MB2198.eurprd06.prod.outlook.com ([10.168.57.139]) by DB6PR0601MB2198.eurprd06.prod.outlook.com ([10.168.57.139]) with mapi id 15.01.0649.027; Mon, 10 Oct 2016 11:41:03 +0000 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: Re: [Ace] draft-ietf-ace-oauth-authz-02 Thread-Index: AdIi6J7hv4U2h0UYRsWsVuXZNGjOhg== Date: Mon, 10 Oct 2016 11:41:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abhinav.somaraju@tridonic.com; x-originating-ip: [146.108.200.99] x-ms-office365-filtering-correlation-id: 2e444db0-12fc-4e35-f8b4-08d3f102509a x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2199; 7:6qnZO52ByxBfn+BBBjfX4G4rrThjl6fO/6jtY/h4Q/FUg2TUS5ICmrVmsDHv/uPsV9bV5OMZJCiN3C6FMGPFMCduntRQDSRdFD7nXBOqATTADMz31Ga9TPDGYDWYdmcZPSN4AShsN26dHwiWknoMXm3gQMyGap0qxx1KVxVmVR4RVaSNtguTxvz23jWPM4curFk6uzr9GU1VCW0Sj/Bg8DeNg060i1Vz3Ob7Y9FsodUgCJUeG4oLoVbWg/tf3NXQsQx7001oaF2ZbaJh3k7t4xR6wmuXQMbNkJDP17XAT5jHst5M8DRkauaXBkigGmkRI9y/x1bNpJtJ4WKP7RquGg2VT7aXQEyC3BJ5y8wb3Zc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2199; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(271806183753584)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DB6PR0601MB2199; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2199; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(377424004)(199003)(8936002)(10400500002)(230783001)(7736002)(6116002)(3846002)(102836003)(586003)(122556002)(11100500001)(2351001)(106356001)(105586002)(2501003)(54356999)(9686002)(50986999)(87936001)(7696004)(101416001)(7846002)(110136003)(92566002)(74316002)(76576001)(5002640100001)(790700001)(5890100001)(8676002)(1730700003)(81166006)(81156014)(107886002)(97736004)(19625215002)(33656002)(4001150100001)(5660300001)(15975445007)(3280700002)(3660700001)(66066001)(2900100001)(86362001)(77096005)(450100001)(6916009)(19300405004)(189998001)(16236675004)(68736007)(2906002)(5630700001)(19580395003)(5640700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2199; H:DB6PR0601MB2198.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: tridonic.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0601MB21986C821B87D0570E04DE97FCDB0DB6PR0601MB2198_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 11:41:03.2542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2199 Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 11:41:10 -0000 --_000_DB6PR0601MB21986C821B87D0570E04DE97FCDB0DB6PR0601MB2198_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2016-10-10 09:02, Somaraju Abhinav wrote: > Hi, I have been looking into this draft, which is very well written, > and I would like a clarification regarding the workflow in figure 1 > of the draft. > > This workflow is a bit different to the typical one I imagine for > constrained clients/servers. Such devices would typically be > provisioned from some kind of a commissioning tool and the tool would > also initiate the provisioning process. Therefore, would it not be > better to have a protocol flow that is not necessarily initiated by > the client device? If I understand you correctly, you are suggesting to provision either the grant or the access token during the commissioning process. Our idea was to use the client credentials grant instead (not shown in our figure 1) and have the AS decide what access tokens to grant purely based on the credentials presented by the client. This way you don't have to provision anything, except for base credentials to a client. The underlying idea is that the RO would configure access control policies at the AS during the commissioning procedure. The AS uses these to determine what kind of access tokens to grant to the client, when it requests one. [AS] Okay. This makes sense. I did not understand this from the text and ma= ybe some clarification in the text could help. For example, in figure 2, ho= w does the client know what to write in the "aud" field. In the Figure 3, t= he grant_type says "token" and I am not sure how this would work. In genera= l, this Section is a little unclear to me and maybe an example in the Appen= dix of how a commissioning tool would be used to provision the system might= help with the readability of the document. You could of course also provision a long term access token to the client during commissioning (I think we mentioned that somewhere, or at least thought of it), so your proposed option 2 would also be valid, and I think they would work just as well with the rest of the framework. I would suggest to add a step before (A) then, were the RO requests an access token from the AS on behalf of the client. [AS] Okay. This could work but maybe the CoAP server/client interaction nee= ds a little bit more work (e.g. how can the AS initiate an interaction with= the client without needing the client to send a GET request). As for option 1, I am not sure what the advantage would be of provisioning a grant to the client as opposed to using the client credentials grant. Could you elaborate on that? [AS] Now that I understand your idea better (i.e. use of client credentials= and the fact that the commissioning tool tells the AS the access rights of= the client), I don't think Option 2 is required. I was thinking of a situa= tion where the commissioning tool is not permanently available. With Option= 2, the commissioning tool could be available during the initial provisioni= ng and during this time it could provide every client with an authorization= grant that includes in the "claims" the access rights of the client. This = authorization grant could then be used in the token request from client to = AS, which then provides the access tokens. ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_DB6PR0601MB21986C821B87D0570E04DE97FCDB0DB6PR0601MB2198_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On 2016-10-10 09:02, Somaraju Abhinav wrote:

> Hi, I have been looking into this draft, which = is very well written,

> and I would like a clarification regarding the = workflow in figure 1

> of the draft.

> 

> This workflow is a bit different to the typical= one I imagine for

> constrained clients/servers. Such devices would= typically be

> provisioned from some kind of a commissioning t= ool and the tool would

> also initiate the provisioning process. Therefo= re, would it not be

> better to have a protocol flow that is not nece= ssarily initiated by

> the client device?

 

If I understand you correctly, you are suggesting to= provision either

the grant or the access token during the commissioni= ng process.

 

Our idea was to use the client credentials grant ins= tead (not shown in

our figure 1) and have the AS decide what access tok= ens to grant purely

based on the credentials presented by the client.

 

This way you don't have to provision anything, excep= t for base

credentials to a client.

 

The underlying idea is that the RO would configure a= ccess control

policies at the AS during the commissioning procedur= e. The AS uses these

to determine what kind of access tokens to grant to = the client, when it

requests one.

[AS] Okay. This makes = sense. I did not understand this from the text and maybe some clarification= in the text could help. For example, in figure 2, how does the client know= what to write in the “aud” field. In the Figure 3, the grant_type says “token” and I am not sure ho= w this would work. In general, this Section is a little unclear to me and m= aybe an example in the Appendix of how a commissioning tool would be used t= o provision the system might help with the readability of the document.

 

You could of course also provision a long term acces= s token to the

client during commissioning (I think we mentioned th= at somewhere, or at

least thought of it), so your proposed option 2 woul= d also be valid, and

I think they would work just as well with the rest o= f the framework.

I would suggest to add a step before (A) then, were = the RO requests an

access token from the AS on behalf of the client.

[AS] Okay. This could = work but maybe the CoAP server/client interaction needs a little bit more w= ork (e.g. how can the AS initiate an interaction with the client without ne= eding the client to send a GET request).

 

As for option 1, I am not sure what the advantage wo= uld be of

provisioning a grant to the client as opposed to usi= ng the client

credentials grant. Could you elaborate on that?=

[AS] Now that I unders= tand your idea better (i.e. use of client credentials and the fact that the= commissioning tool tells the AS the access rights of the client), I don= 217;t think Option 2 is required. I was thinking of a situation where the commissioning tool is not permanently available. = With Option 2, the commissioning tool could be available during the initial= provisioning and during this time it could provide every client with an au= thorization grant that includes in the “claims” the access rights of the client. This authoriz= ation grant could then be used in the token request from client to AS, whic= h then provides the access tokens.  

________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_DB6PR0601MB21986C821B87D0570E04DE97FCDB0DB6PR0601MB2198_-- From nobody Wed Oct 12 01:12:22 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2C41296FA for ; Wed, 12 Oct 2016 01:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 1mQBCzgQb4gA for ; Wed, 12 Oct 2016 01:12:04 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 3E78F1296F1 for ; Wed, 12 Oct 2016 01:12:04 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id x79so67512164lff.0 for ; Wed, 12 Oct 2016 01:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=mime-version:from:date:message-id:subject:to; bh=rwte14AeHecS+6MORirmYpvs5IB5AkY3EV38+abFrD8=; b=QG1WbMB56Wc9rCsoMmG+doQbz+KpEGbSG+tdXsCSlkhBsm9nSe++bFrtpoPULBzrvE +72ZC37pLQFyyJKgTNL9GlFcAyS8mlTKt0hmJAjMADs0mun5fCoYZ9/abIS7UR1zm6mX wolcdslJ+PYjePo8X+CrDC0C7Q0TkTxMUipG9FtMAYruqCy9Hf7LappyDOPmlFUKKRmQ Q98AMnGP/MRRomIVVjOL+lXNkG06xwVZP85z5bs31eTfthtUtjDp9kCQlSxeFFyo42qf R0pxQyI4u3Qx/D1kIDsssovevXnoM0/ShRvEhnXdGn2P8hfR+Vu7DRi+oYlc6lPFBaCu iYAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rwte14AeHecS+6MORirmYpvs5IB5AkY3EV38+abFrD8=; b=QhgW2zJXfmp8XXkfopZO/e0/6idB6uCmI1Vu+fStYGHSrPsJTsTjV+kb5q8wFdU7sx Wpd5SzqhTTmQCGj5ZMZuHE2mtOae5fBywjwUJnft5NM0VJz5FN0lTncpSkP/qG71dHJG 2ihGGRX0LvyCxCNJGG2RAHpcO65plxYnvlFeqwzb32eRqmtUOCaGUVwkKPxIgfzRdzTr HD8VhLr8zlVbrV1RZ+tHKVYjVka37P6605/e3mbvijwVfwZ/ITiw7JnqR1m5GdAx0lYy u50oQwOY/ZB9/hh3gkpWZt3kImRwxjiqZsKUu+boRtUWfM6HOhS8B2Z7MX0z9vweSnzK N8Nw== X-Gm-Message-State: AA6/9RmDKX/k17SO8STkcGbO/IbrVZfTYKhTk6tTu3vYnZJ6+DdxvdR+54xRn4uNlL1FqIiJB9c42Y0IQnA0ELYV X-Received: by 10.25.139.195 with SMTP id n186mr6103529lfd.97.1476259922123; Wed, 12 Oct 2016 01:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.134.213 with HTTP; Wed, 12 Oct 2016 01:12:01 -0700 (PDT) From: Marco Tiloca Date: Wed, 12 Oct 2016 10:12:01 +0200 Message-ID: To: core@ietf.org, Ace@ietf.org Content-Type: multipart/alternative; boundary=001a113ebaa6413c47053ea68ced Archived-At: Subject: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 08:12:17 -0000 --001a113ebaa6413c47053ea68ced Content-Type: text/plain; charset=UTF-8 Dear CoRE/ACE, We have submitted a draft on secure group communication for CoAP addressing security for the setting of a multicast CoAP request with unicast responses as described in RFC7390. This draft builds on the recently updated version of OSCOAP, extended with mandatory Sender ID and multiple Recipient Contexts. It also enables source authentication with asymmetric signatures implemented as counter signatures included with the COSE objects defined by OSCOAP. We hope that by submitting now we could get some first discussion to allow updates before the cutoff. This draft provides the missing link between https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP. Best regards, Marco ---------- Forwarded message ---------- From: Date: Wed, Oct 12, 2016 at 9:27 AM Subject: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt To: Marco Tiloca , Goeran Selander < goran.selander@ericsson.com>, Francesca Palombini < francesca.palombini@ericsson.com> A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt has been successfully submitted by Francesca Palombini and posted to the IETF repository. Name: draft-tiloca-core-multicast-oscoap Revision: 00 Title: Secure group communication for CoAP Document date: 2016-10-12 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-tiloca-core- multicast-oscoap-00.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-core- multicast-oscoap/ Htmlized: https://tools.ietf.org/html/draft-tiloca-core-multicast- oscoap-00 Abstract: This document describes a method for application layer protection of messages exchanged with the Constrained Application Protocol (CoAP) in a group communication context. The proposed approach relies on Object Security of CoAP (OSCOAP) and the CBOR Object Signing and Encryption (COSE) format. All security requirements fulfilled by OSCOAP are maintained for multicast CoAP request messages and related unicast CoAP response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through asymmetric private keys of sender devices and embedded in the protected CoAP messages. 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. The IETF Secretariat --001a113ebaa6413c47053ea68ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear CoRE/ACE,

We have submitted a draft on secure group communication for CoAP=20 addressing security for the setting of a multicast CoAP request with=20 unicast responses as described in RFC7390.

This draft builds on the recently updated version of OSCOAP, extended=20 with mandatory Sender ID and multiple Recipient Contexts. It also=20 enables source authentication with asymmetric signatures implemented as=20 counter signatures included with the COSE objects defined by OSCOAP.

We hope that by submitting now we could get some first discussion to allow = updates before the cutoff.

This draft provides the missing link between https://tools.ietf.org/html/draft-so= maraju-ace-multicast and OSCOAP.

Best regards,
Marco


---------- Forwarded message --= --------
From: <= internet-drafts@ietf.org>= ;
Date: Wed, Oct 12, 2016 at 9:27 AM
Subject: New Version Noti= fication for draft-tiloca-core-multicast-oscoap-00.txt
To: Marco Tiloca = <marco@sics.se>, Goeran Selander= <goran.selander@ericsson= .com>, Francesca Palombini <francesca.palombini@ericsson.com>



A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt
has been successfully submitted by Francesca Palombini and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tiloca-core-multicast-<= wbr>oscoap
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secure group communication for CoA= P
Document date:=C2=A0 2016-10-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-til= oca-core-multicast-oscoap-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-tiloca-core-multi= cast-oscoap/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-0= 0


Abstract:
=C2=A0 =C2=A0This document describes a method for application layer protect= ion of
=C2=A0 =C2=A0messages exchanged with the Constrained Application Protocol (= CoAP)
=C2=A0 =C2=A0in a group communication context.=C2=A0 The proposed approach = relies on
=C2=A0 =C2=A0Object Security of CoAP (OSCOAP) and the CBOR Object Signing a= nd
=C2=A0 =C2=A0Encryption (COSE) format.=C2=A0 All security requirements fulf= illed by
=C2=A0 =C2=A0OSCOAP are maintained for multicast CoAP request messages and = related
=C2=A0 =C2=A0unicast CoAP response messages.=C2=A0 Source authentication of= all
=C2=A0 =C2=A0messages exchanged within the group is ensured, by means of di= gital
=C2=A0 =C2=A0signatures produced through asymmetric private keys of sender = devices
=C2=A0 =C2=A0and embedded in the protected CoAP messages.




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.

The IETF Secretariat


--001a113ebaa6413c47053ea68ced-- From nobody Wed Oct 12 01:40:25 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B6712970A for ; Wed, 12 Oct 2016 01:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EIDPgwCCp_yM for ; Wed, 12 Oct 2016 01:40:22 -0700 (PDT) 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 A9B5E1294A5 for ; Wed, 12 Oct 2016 01:40:21 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MI5Ve-1brUjN0zny-003z3y; Wed, 12 Oct 2016 10:40:19 +0200 To: Marco Tiloca , Ace@ietf.org References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> Date: Wed, 12 Oct 2016 10:40:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G21iLGuCNFdTfsHWrfIOF2gLU85cApDuC" X-Provags-ID: V03:K0:m1+G07kzdVZ7Dtlb5cFYktC+NJJaDk1sGl/qGFgpisFaHwHxnro wzLsOsZ7b8r4Svhk6Xs+s5XUnSLko+iO5Ik522D2NDaPQ0oJBXu1NsmGWVxXmV0PxHOKSTB fqrZmFHg7s41KRB3qLs3fddLrF2zFvvA3PgO5vUR7GJ2LCLt8vqiuAQ7LR3yr9Q7MhI3M4h 37Z4mD+0d9gVT9jp2FcFQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:qpfrqy4Bi4s=:RfUBx0sODiYyo/yYfYDVWk m3O5DFWRPYaiK9pQcqLNI9tmBs+iwj4OdE+b5AazqkaZpFfExMtvux0fPmZvf0BHbeoKMMP6t o+9NYC3dSpqp9YxjmvLqQo8fyNBT2fUZNQJbbzJg8wwKRsi7XO54jirC+gUSuI/s+H/kMdvJc N/25sTQuIjNuY2fy/80fy4jV0nYaWyyfM0oa+zZQBiYk8iNv7ugDWe0mlbjO0ovxgnoFK+tEF xevMkN+81JeyQY/JdbFgVEYeB9nzEFldts/CBRXOG7c9pPq0ZZvriHNQxaXhJ8TdJaZMxl4QR chvBu+njluS0wT3jkykwJI21RpRaqv9vkSVMOQStorSm9Qn1G6kd1COZSCO6ArA8UGYhdMN89 A29hHX0/BBIg4Fmk4LrbjfRvZLJaxYVubJ77nwWUhBZlGI9KdUidu22v7PCg6OV7IyRbikdwc DmIr+JVM6fzzKlCPlGIfXKpUbEopsxINcWiMg8qy1uBMwwtdfFBL0HkpP+gUk8QMY9s1nZ3xv pfVzMvr9qrAYQ1JiyvWJW9e0jn3Yp4yI1mQkjp3VDXKo+B3nkesj0Ui03GElqHrvVu0VJjwUG 1L9phoZZGEk4JufwrCx+L+NDQE+YX5G0YpOY6SfkvFsRM8MWepHRPn3NnvUTxXzaaVBRlmijM xXVUIThmc3TMWk1uYeTXA2/Ui9aGBkkNhAPiLUutkuLSHzAFPouO7+WG8qsDnVy87y2iATb/0 Pp4JIIBkr2gV64LIbFTjBEZwP5swYHS5dOGPvpk4UoV+2OvJakoR1utu9ow= Archived-At: Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 08:40:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G21iLGuCNFdTfsHWrfIOF2gLU85cApDuC Content-Type: multipart/mixed; boundary="DEMvbLfnWqOeiTtPBLs84XpGeqmEfifGC"; protected-headers="v1" From: Hannes Tschofenig To: Marco Tiloca , Ace@ietf.org Message-ID: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt References: In-Reply-To: --DEMvbLfnWqOeiTtPBLs84XpGeqmEfifGC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Marco, Hi Francesca, Hi Goeran, I am a bit surprised about your document submission since you guys have been pretty silent in the group communication security discussion, which was quite controversial, long, and tough. That's where your support would have been needed. Adding the few small bits to the already written draft isn't the problem. Ciao Hannes On 10/12/2016 10:12 AM, Marco Tiloca wrote: > Dear CoRE/ACE, >=20 > We have submitted a draft on secure group communication for CoAP > addressing security for the setting of a multicast CoAP request with > unicast responses as described in RFC7390. >=20 > This draft builds on the recently updated version of OSCOAP, extended > with mandatory Sender ID and multiple Recipient Contexts. It also > enables source authentication with asymmetric signatures implemented as= > counter signatures included with the COSE objects defined by OSCOAP. >=20 > We hope that by submitting now we could get some first discussion to > allow updates before the cutoff. >=20 > This draft provides the missing link between > https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP. >=20 > Best regards, > Marco >=20 >=20 > ---------- Forwarded message ---------- > From: ** > > Date: Wed, Oct 12, 2016 at 9:27 AM > Subject: New Version Notification for > draft-tiloca-core-multicast-oscoap-00.txt > To: Marco Tiloca >, Goeran Selande= r > >, > Francesca Palombini > >=20 >=20 >=20 > A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt > has been successfully submitted by Francesca Palombini and posted to th= e > IETF repository. >=20 > Name: draft-tiloca-core-multicast-oscoap > Revision: 00 > Title: Secure group communication for CoAP > Document date: 2016-10-12 > Group: Individual Submission > Pages: 15 > URL: =20 > https://www.ietf.org/internet-drafts/draft-tiloca-core-multicast-oscoap= -00.txt > > Status: =20 > https://datatracker.ietf.org/doc/draft-tiloca-core-multicast-oscoap/ > > Htmlized: =20 > https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00 > >=20 >=20 > Abstract: > This document describes a method for application layer protection of= > messages exchanged with the Constrained Application Protocol (CoAP) > in a group communication context. The proposed approach relies on > Object Security of CoAP (OSCOAP) and the CBOR Object Signing and > Encryption (COSE) format. All security requirements fulfilled by > OSCOAP are maintained for multicast CoAP request messages and relate= d > unicast CoAP response messages. Source authentication of all > messages exchanged within the group is ensured, by means of digital > signatures produced through asymmetric private keys of sender device= s > and embedded in the protected CoAP messages. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org > . >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --DEMvbLfnWqOeiTtPBLs84XpGeqmEfifGC-- --G21iLGuCNFdTfsHWrfIOF2gLU85cApDuC 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/fbxAAoJEGhJURNOOiAtvVsH+wfXUW4STsu5CmgBDg/AviwI dt/xN2OBWVOKaxPwE795+1Ig2ZQ7/SVgdG8wwNdODzYq9Cy16UqWkJduNCOy7WhA 2ZWUm9TXc5oPJMISMWQeerQgn/RAAiUtMX5iCzpG98+Hf04gXkpFAIA66oh48vCs qYxk3iVsi2G6Y4va+LA6gxqa+JE+Wk2ZKiCn6Y16nXgbEQxA5r1zD4upH9jBV00B rM6Eavfs9s8BfADCzWDPD7sBGnteuqzcMbs6KRCRvavjwm6Ezro5PQRG4GeIK0bC 0INvOfEaNMMA5HsgS0HjqhIQucgA5U8taIgnvTV+dnInTMFVw8Oawi9zwjLJuvQ= =9NlS -----END PGP SIGNATURE----- --G21iLGuCNFdTfsHWrfIOF2gLU85cApDuC-- From nobody Wed Oct 12 04:32:05 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69379129795 for ; Wed, 12 Oct 2016 04:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ppxjDjnNgkPI for ; Wed, 12 Oct 2016 04:32:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 03F3A1294BE for ; Wed, 12 Oct 2016 04:32:00 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-05-57fe1f2f5153 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 29.99.03250.F2F1EF75; Wed, 12 Oct 2016 13:31:59 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.183]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 13:31:58 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Marco Tiloca , "Ace@ietf.org" Thread-Topic: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt Thread-Index: AQHSJGBb3IlreYskZUK0h4lx2n498qCkXjyAgABRfAA= Date: Wed, 12 Oct 2016 11:31:57 +0000 Message-ID: References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> In-Reply-To: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <068EEDDE9F2ECB47A045649B5916431D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7hK6+/L9wg/l7pC2+f+thtli68x6r xZy1e9kcmD0Wb9rP5rFkyU8mj95jv9kCmKO4bFJSczLLUov07RK4MibN3cRa8Muk4sCtF0wN jGeMuxg5OSQETCRuH2lk7mLk4hASWM8o8a7nIQuEs4RRomviImaQKjYBF4kHDY+YQGwRgQKJ uecvsIPYwgLpEmfau9kh4hkSi97eA2rmALKtJE7dkwIJswioSuz6cY4FxOYVsJA48PENI8T8 RkaJ+y++giU4Bawlvtx5zwpiMwqISXw/tQZsF7OAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP7B6 UQE9iWcnFzNCxJUkGpc8YQW5gVlAU2L9Ln0I01qi8bQWxERFiSndD9khzhGUODnzCcsERrFZ SJbNQmiehdA8C0nzLCTNCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERtnBLb8NdjC+ fO54iFGAg1GJh3eBxt9wIdbEsuLK3EOMEhzMSiK8+uL/woV4UxIrq1KL8uOLSnNSiw8xSnOw KInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgZP77L1ra/1vkhVsWR27khJnufbOm1FSbL6Ut aXKp8mXB9SVN5fcn3FzVmpbfMuGh0mfB75/i7qQbeOzR8kx8L+a3JSFMSD1EXH/zHPlujXMz RefZ/m14/UC0mPH0W2WfJyVv+sNOz+LuYH67jUV2BivPP77YqFm3d6Yr7g6+XC65zE3n99ap SizFGYmGWsxFxYkACWozVq4CAAA= Archived-At: Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 11:32:03 -0000 DQpIaSBIYW5uZXMsDQoNCknigJltIGEgYml0IHN1cnByaXNlZCBhdCB5b3VyIHJlYWN0aW9uLiBJ ZiB5b3UgaGF2ZSBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbg0Kb24gT1NDT0FQIHlvdSBrbm93IHRo YXQgb25lIHJlY3VycmluZyByZXF1ZXN0IGhhcyBiZWVuIG9uIHN1cHBvcnQgZm9yDQptdWx0aWNh c3QuIFRoaXMgZHJhZnQgaXMgYWRkcmVzc2luZyB0aGF0IHJlcXVlc3QuDQoNCmRyYWZ0LXNvbWFy YWp1LWFjZS1tdWx0aWNhc3QtMDEgaXMgcmVmZXJyaW5nIHRvIE9TQ09BUCBmb3Igc2VjdXJlIGdy b3VwDQpjb21tdW5pY2F0aW9uIGFuZCB3ZSBwcm9wb3NlIHRoaXMgZHJhZnQgdG8gYmUgdGhlIHdh eSB0byBleHRlbmQgT1NDT0FQIGZvcg0KdGhhdCBwdXJwb3NlLg0KDQpJbiB0aGUgImNvbnRyb3Zl cnNpYWwsIGxvbmcsIGFuZCB0b3VnaOKAnSBkaXNjdXNzaW9uIHlvdSByZWZlciB0bywgb25lDQpj ZW50cmFsIGlzc3VlIHJlbGF0ZXMgdG8gdGhlIHVzZSBvZiBzeW1tZXRyaWMga2V5cyBvbmx5IGlu IGdyb3VwDQpjb21tdW5pY2F0aW9uLiBPdXIgZHJhZnQgbWFuZGF0ZXMgdGhlIHVzZSBvZiBhc3lt bWV0cmljIGtleXMgc2luY2UgdGhhdA0KcHJvdmlkZXMgc291cmNlIGF1dGhlbnRpY2F0aW9uLiBT aG91bGQgaXQgYmUgYWdyZWVkIHRoYXQgc291cmNlDQphdXRoZW50aWNhdGlvbiBmb3Igc29tZSBw dXJwb3NlIGlzIG5vdCBuZWNlc3NhcnksIGl0IGlzIGEgc2ltcGxlDQptb2RpZmljYXRpb24gb2Yg dGhpcyBkcmFmdCAtIHNpbXBseSBtYWtpbmcgdGhlIGNvdW50ZXIgc2lnbmF0dXJlIGluIHRoZQ0K Q09TRSBvYmplY3Qgbm9uLW1hbmRhdG9yeS4NCg0KSXQgd2FzIG91ciBob3BlIHRoYXQgd2UgaW4g dGhpcyB3YXkgY2FuIGRlY291cGxlIHRoZSBxdWVzdGlvbiBvZiBhZG9wdGlvbg0Kb2YgZHJhZnQt c29tYXJhanUtYWNlLW11bHRpY2FzdC0wMSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBzb3VyY2UNCmF1 dGhlbnRpY2F0aW9uLg0KDQpHw7ZyYW4NCg0KDQoNCg0KT24gMjAxNi0xMC0xMiAxMDo0MCwgIkFj ZSBvbiBiZWhhbGYgb2YgSGFubmVzIFRzY2hvZmVuaWciDQo8YWNlLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQo+SGkgTWFy Y28sIEhpIEZyYW5jZXNjYSwgSGkgR29lcmFuLA0KPg0KPkkgYW0gYSBiaXQgc3VycHJpc2VkIGFi b3V0IHlvdXIgZG9jdW1lbnQgc3VibWlzc2lvbiBzaW5jZSB5b3UgZ3V5cyBoYXZlDQo+YmVlbiBw cmV0dHkgc2lsZW50IGluIHRoZSBncm91cCBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGRpc2N1c3Np b24sIHdoaWNoDQo+d2FzIHF1aXRlIGNvbnRyb3ZlcnNpYWwsIGxvbmcsIGFuZCB0b3VnaC4gVGhh dCdzIHdoZXJlIHlvdXIgc3VwcG9ydA0KPndvdWxkIGhhdmUgYmVlbiBuZWVkZWQuIEFkZGluZyB0 aGUgZmV3IHNtYWxsIGJpdHMgdG8gdGhlIGFscmVhZHkgd3JpdHRlbg0KPmRyYWZ0IGlzbid0IHRo ZSBwcm9ibGVtLg0KPg0KPkNpYW8NCj5IYW5uZXMNCj4NCj5PbiAxMC8xMi8yMDE2IDEwOjEyIEFN LCBNYXJjbyBUaWxvY2Egd3JvdGU6DQo+PiBEZWFyIENvUkUvQUNFLA0KPj4gDQo+PiBXZSBoYXZl IHN1Ym1pdHRlZCBhIGRyYWZ0IG9uIHNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uIGZvciBDb0FQ DQo+PiBhZGRyZXNzaW5nIHNlY3VyaXR5IGZvciB0aGUgc2V0dGluZyBvZiBhIG11bHRpY2FzdCBD b0FQIHJlcXVlc3Qgd2l0aA0KPj4gdW5pY2FzdCByZXNwb25zZXMgYXMgZGVzY3JpYmVkIGluIFJG QzczOTAuDQo+PiANCj4+IFRoaXMgZHJhZnQgYnVpbGRzIG9uIHRoZSByZWNlbnRseSB1cGRhdGVk IHZlcnNpb24gb2YgT1NDT0FQLCBleHRlbmRlZA0KPj4gd2l0aCBtYW5kYXRvcnkgU2VuZGVyIElE IGFuZCBtdWx0aXBsZSBSZWNpcGllbnQgQ29udGV4dHMuIEl0IGFsc28NCj4+IGVuYWJsZXMgc291 cmNlIGF1dGhlbnRpY2F0aW9uIHdpdGggYXN5bW1ldHJpYyBzaWduYXR1cmVzIGltcGxlbWVudGVk IGFzDQo+PiBjb3VudGVyIHNpZ25hdHVyZXMgaW5jbHVkZWQgd2l0aCB0aGUgQ09TRSBvYmplY3Rz IGRlZmluZWQgYnkgT1NDT0FQLg0KPj4gDQo+PiBXZSBob3BlIHRoYXQgYnkgc3VibWl0dGluZyBu b3cgd2UgY291bGQgZ2V0IHNvbWUgZmlyc3QgZGlzY3Vzc2lvbiB0bw0KPj4gYWxsb3cgdXBkYXRl cyBiZWZvcmUgdGhlIGN1dG9mZi4NCj4+IA0KPj4gVGhpcyBkcmFmdCBwcm92aWRlcyB0aGUgbWlz c2luZyBsaW5rIGJldHdlZW4NCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z b21hcmFqdS1hY2UtbXVsdGljYXN0IGFuZCBPU0NPQVAuDQo+PiANCj4+IEJlc3QgcmVnYXJkcywN Cj4+IE1hcmNvDQo+PiANCj4+IA0KPj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0t LS0tLS0tDQo+PiBGcm9tOiAqKiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCj4+IERhdGU6IFdlZCwgT2N0IDEyLCAyMDE2IGF0IDk6 MjcgQU0NCj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+IGRyYWZ0 LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDAudHh0DQo+PiBUbzogTWFyY28gVGlsb2Nh IDxtYXJjb0BzaWNzLnNlIDxtYWlsdG86bWFyY29Ac2ljcy5zZT4+LCBHb2VyYW4gU2VsYW5kZXIN Cj4+IDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20gPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20+PiwNCj4+IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJp bmlAZXJpY3Nzb24uY29tDQo+PiA8bWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24u Y29tPj4NCj4+IA0KPj4gDQo+PiANCj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aWxv Y2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBGcmFuY2VzY2EgUGFsb21iaW5pIGFuZCBwb3N0ZWQgdG8gdGhlDQo+PiBJ RVRGIHJlcG9zaXRvcnkuDQo+PiANCj4+IE5hbWU6ICAgICAgICAgICBkcmFmdC10aWxvY2EtY29y ZS1tdWx0aWNhc3Qtb3Njb2FwDQo+PiBSZXZpc2lvbjogICAgICAgMDANCj4+IFRpdGxlOiAgICAg ICAgICBTZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUA0KPj4gRG9jdW1lbnQgZGF0 ZTogIDIwMTYtMTAtMTINCj4+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4+IFBhZ2VzOiAgICAgICAgICAxNQ0KPj4gVVJMOiAgICAgICAgICAgDQo+PiANCj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2Fz dC1vc2NvYXAtMA0KPj4wLnR4dA0KPj4gDQo+PjxodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0NCj4+MDAudHh0Pg0K Pj4gU3RhdHVzOiAgICAgICANCj4+ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLw0KPj4gPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAvPg0KPj4g SHRtbGl6ZWQ6ICAgICANCj4+ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGls b2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMA0KPj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAwPg0KPj4gDQo+PiANCj4+ IEFic3RyYWN0Og0KPj4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgZm9yIGFw cGxpY2F0aW9uIGxheWVyIHByb3RlY3Rpb24gb2YNCj4+ICAgIG1lc3NhZ2VzIGV4Y2hhbmdlZCB3 aXRoIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkNCj4+ICAgIGlu IGEgZ3JvdXAgY29tbXVuaWNhdGlvbiBjb250ZXh0LiAgVGhlIHByb3Bvc2VkIGFwcHJvYWNoIHJl bGllcyBvbg0KPj4gICAgT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9TQ09BUCkgYW5kIHRoZSBD Qk9SIE9iamVjdCBTaWduaW5nIGFuZA0KPj4gICAgRW5jcnlwdGlvbiAoQ09TRSkgZm9ybWF0LiAg QWxsIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmdWxmaWxsZWQgYnkNCj4+ICAgIE9TQ09BUCBhcmUg bWFpbnRhaW5lZCBmb3IgbXVsdGljYXN0IENvQVAgcmVxdWVzdCBtZXNzYWdlcyBhbmQgcmVsYXRl ZA0KPj4gICAgdW5pY2FzdCBDb0FQIHJlc3BvbnNlIG1lc3NhZ2VzLiAgU291cmNlIGF1dGhlbnRp Y2F0aW9uIG9mIGFsbA0KPj4gICAgbWVzc2FnZXMgZXhjaGFuZ2VkIHdpdGhpbiB0aGUgZ3JvdXAg aXMgZW5zdXJlZCwgYnkgbWVhbnMgb2YgZGlnaXRhbA0KPj4gICAgc2lnbmF0dXJlcyBwcm9kdWNl ZCB0aHJvdWdoIGFzeW1tZXRyaWMgcHJpdmF0ZSBrZXlzIG9mIHNlbmRlciBkZXZpY2VzDQo+PiAg ICBhbmQgZW1iZWRkZWQgaW4gdGhlIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2VzLg0KPj4gDQo+PiAN Cj4+IA0KPj4gDQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj5zdWJtaXNzaW9uDQo+PiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnDQo+PiA8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4+IA0KPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+IEFjZUBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4+IA0KPg0KDQo= From nobody Wed Oct 12 04:35:30 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 F3C641294C4; Wed, 12 Oct 2016 04:35:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147627212799.24170.1992129579515763479.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 04:35:27 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 11:35:28 -0000 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 of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-03.txt Pages : 56 Date : 2016-10-12 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-03 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/ From nobody Wed Oct 12 04:37:45 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE31297A1 for ; Wed, 12 Oct 2016 04:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 dkMpCTwiATXA for ; Wed, 12 Oct 2016 04:37:41 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 C14FC1294C4 for ; Wed, 12 Oct 2016 04:37:40 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l131so38325239lfl.2 for ; Wed, 12 Oct 2016 04:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=FQZjNkpR5koEfV2YYXcE4fOXhCBkl5Q18QE7507/9Nw=; b=dNkiBucM6SRVFdPH1pGgcsQ0yH/m7pidIWn6N3EVz727/kvjxhOPFJ6Cxvt/4IgNnQ H3gEDKvvs5d2tyl1lm2uvGdiv6JQgEXjq5b0YkdVWQnzKlv8S79TssySUToenX3SMJ9V abCziQRj5K8hw22A0VnQPixa6GblFhktZh+lTqgSlt9W5OIzkZsWFcOUqmyoFf/PppVN 7O574utv2QaNmqs+VGtLxI3YjmiCFmUurlF3QmL8EtGv2ERCC+YbZBPZdld3+yyg2mij SFkHU4dIDEIBFxmpkmQbG78L6bUJE3VVj/ICkvp4ZxNiWnC9bNenT1RFlQJJtqcElchq Ge8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=FQZjNkpR5koEfV2YYXcE4fOXhCBkl5Q18QE7507/9Nw=; b=Qm9ZmG97iuwZiabch+vv/46Eha2NrwFBtNo/u83n+O+4hQKJB9uUACNuSgejWcQoFY tFvrxfD5McZ2Do1vW1n5FKmK/CFtGG7X58hR+r0TY7OKspKKFN3olo8VP5k+Atfi91lv NcmWISrDXB2fPdCa3r7YjiJKvSAFhrGsx1rtUtbm0Iv+nXnBsCBENRM3r95tHVjaYCcz XaGNngXsvB0LqfQCLpnFu/uZeVRZknPc9XQ16kH2fBtQG7mjxdF/Ex+CMDIDEIl76673 +asaRKS/wxitvpkeLhnyhJU6m6J/b3MvAvgArrvvIUfEu4GL+J8bPCNlOJjETPtqzKq8 C9ug== X-Gm-Message-State: AA6/9RlUuDGtF3ecMGpmRxaYHt6hAjHhIsHWu0wW2nQYZkw+dk6ZfcF3aEKUIPuACU0KJVAq X-Received: by 10.25.201.137 with SMTP id z131mr668291lff.144.1476272258276; Wed, 12 Oct 2016 04:37:38 -0700 (PDT) Received: from [192.168.0.110] (89-253-76-185.customers.ownit.se. [89.253.76.185]) by smtp.gmail.com with ESMTPSA id e70sm2041298lji.30.2016.10.12.04.37.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Oct 2016 04:37:37 -0700 (PDT) References: <147627212816.24170.6595320071556255667.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <147627212816.24170.6595320071556255667.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 12 Oct 2016 13:37:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147627212816.24170.6595320071556255667.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000305020108020405080906" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 11:37:43 -0000 This is a cryptographically signed message in MIME format. --------------ms000305020108020405080906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello ACE, we have uploaded a new version of our draft, addressing mainly the=20 review comments from Renzo and adding a number of clarifications about=20 the /token, /introspect and /authz-info endpoints. Please review this version and send us comments, if we get enough=20 feeback we might be able to produce another version before the cut-off. Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.txt Date: Wed, 12 Oct 2016 04:35:28 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Erik Wahlstroem=20 , Goeran Selander=20 , Samuel Erdtman ,=20 Hannes Tschofenig A new version of I-D, draft-ietf-ace-oauth-authz-03.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 03 Title: Authentication and Authorization for Constrained Environments (AC= E) Document date: 2016-10-12 Group: ace Pages: 56 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-aut= hz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03= Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-03 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms000305020108020405080906 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 CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEwMTIxMTM3MjlaMC8GCSqGSIb3DQEJBDEiBCCFf8q2fa4D 3636d+ELmZGCpcDMk7Vw5WeukPjlKCBSPDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQAHeGdVVIndv/wKUchbpML1 uO1q02OVX+9+g9ZtYaOCLGEoIgBaxI7tdM76atuJsVRE/OpEn25HxiFQZQx6pnBGt/sMNs/X SRLnYSbzgnuprDRokse0l7zXAqnGPYZJfwaBZs38XFpd3jEcZF0tLEYJB8QRgF5I3qpsBxly Vw/mJ1KGiKs7Sqh4a4E9L6lkIwWzfqbbEzpmXCy+WlxQf9nC7+2u3yIJ+9JkWK9y296B7huy JDy2CS3h01cgQlPnowMjgzjhAk0ej3AbMuRZ4ce5oIDwn7aniR1P3HniiaDGBSDFVcfzBC0V bPSQsjczLtw8jyyUQF3pHVe8zIrpZyNUAAAAAAAA --------------ms000305020108020405080906-- From nobody Wed Oct 12 04:50:48 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB621294D4 for ; Wed, 12 Oct 2016 04:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 C9wlDLg6LOwO for ; Wed, 12 Oct 2016 04:50:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 36DF71294D2 for ; Wed, 12 Oct 2016 04:50:45 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MAyZg-1bkMRJ1LFs-009xgb; Wed, 12 Oct 2016 13:50:41 +0200 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Marco Tiloca , "Ace@ietf.org" References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> Date: Wed, 12 Oct 2016 13:50:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="B0viD8JvbCDnSWbIiViVKdP74s8bP7X5W" X-Provags-ID: V03:K0:Euzvd7peO+K38lJxufbzsDi+CHkfTPPUyf611e4fEto26iKin4X J6ILRhRGARryqnM+mhuL/IylXy4E8TSvv5aC/H62brrgwT2oRc7kuonqe/WNhn7yjqptFe1 +S3qnqWsNrxuLxEImr2dShE73LyKqtJ48YqLOLBaDaDG7nEL0xQPCdSkQZOo6h9MCcw/RjS 6WytPG2L/WLdKPDlFg53w== X-UI-Out-Filterresults: notjunk:1;V01:K0:bn1BkKadfC8=:1j0wyKOEKQ5gFgAHUNAFSj 0/mAnagmdt8g7rDirgQsD5LJFNSZ76VWBWrADXDiiMyGrk7XdEUUFUS4XuVkYiakQHMkzhh8m ndjc8F1dMvo5xhPEAY/+yqjGuipyLT1hBnWp/1zOtAe0T6fT9F2sAatnt+Ub+g83uNhALNa6m hfj7ZLqUpOt6RB+A11+OrYP9GViqb1sFCczXSqQCmodcGev9nPK1358KuLU6JnqcBhNutbWYr GE04mb1RlXbdGBUprxdT8erTkGmxGaZGG4L1WoxNPdch9MN8vQkKQ3swFT4odStSryWscERPo eOfWCq8HYfxdyUjrSBuGth75ShuiWpHrtGjwXTLf6FqMOcVGhlqIj8XCxXFIxt8RhjnJTcLLb p2tZp1FbftxUZG1npPn2Veahk3VWPFp8VhOwMtROCZuzVwK7Dfx20ysSkwYprNiulVtEVos64 fA36O6JZ5JFm5VJ529f9rxUzptYAJGi1PaZ3bwn7ovn55ER1fTMeuR3iX8mcxfZ3ytfgBW3fA 64Bm4CfT8CtAcXNvNA2ctwdnC1gEbxbVt0vWu+RLLwxM4xgQZv+/XVfbT0U+zrxPaHLj3npoy kgcuH6S1c6EeSma+IePt4SAJeh1t5LqS4YzV4cq8m3jScCX6+H1c5SLycCBIGWqyxwMCa+B4J 7GB2V+LvIVYX/MtV6nRwq/9yz3MvrPfqtABElnoGF8sKegFL2ARPP83gbLx7WvtA7SDnX3u9K tDTjHMuoswhgdyiAk3tCeBM8lxQpk6CeUKywjaty0C47Eg78uki5scN6lIk= Archived-At: Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 11:50:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B0viD8JvbCDnSWbIiViVKdP74s8bP7X5W Content-Type: multipart/mixed; boundary="oSQde1uurvXsJodXURRp6fTfige6EsExI"; protected-headers="v1" From: Hannes Tschofenig To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Marco Tiloca , "Ace@ietf.org" Message-ID: <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> In-Reply-To: --oSQde1uurvXsJodXURRp6fTfige6EsExI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, there was never any doubt that we can use COSE to design a security solution using the already existing building blocks. Btw, in the meanwhile we have actually concluded the discussion in ACE on the group communication security topic, see https://www.ietf.org/mail-archive/web/ace/current/msg01967.html Ciao Hannes PS: You cannot decouple the question of adoption of draft-somaraju-ace-multicast-01 from the question of source authentication since this was the core issue of the debate. On 10/12/2016 01:31 PM, G=C3=B6ran Selander wrote: >=20 > Hi Hannes, >=20 > I=E2=80=99m a bit surprised at your reaction. If you have followed the = discussion > on OSCOAP you know that one recurring request has been on support for > multicast. This draft is addressing that request. >=20 > draft-somaraju-ace-multicast-01 is referring to OSCOAP for secure group= > communication and we propose this draft to be the way to extend OSCOAP = for > that purpose. >=20 > In the "controversial, long, and tough=E2=80=9D discussion you refer to= , one > central issue relates to the use of symmetric keys only in group > communication. Our draft mandates the use of asymmetric keys since that= > provides source authentication. Should it be agreed that source > authentication for some purpose is not necessary, it is a simple > modification of this draft - simply making the counter signature in the= > COSE object non-mandatory. >=20 > It was our hope that we in this way can decouple the question of adopti= on > of draft-somaraju-ace-multicast-01 from the question of source > authentication. >=20 > G=C3=B6ran >=20 >=20 >=20 >=20 > On 2016-10-12 10:40, "Ace on behalf of Hannes Tschofenig" > wrote: >=20 >> Hi Marco, Hi Francesca, Hi Goeran, >> >> I am a bit surprised about your document submission since you guys hav= e >> been pretty silent in the group communication security discussion, whi= ch >> was quite controversial, long, and tough. That's where your support >> would have been needed. Adding the few small bits to the already writt= en >> draft isn't the problem. >> >> Ciao >> Hannes >> >> On 10/12/2016 10:12 AM, Marco Tiloca wrote: >>> Dear CoRE/ACE, >>> >>> We have submitted a draft on secure group communication for CoAP >>> addressing security for the setting of a multicast CoAP request with >>> unicast responses as described in RFC7390. >>> >>> This draft builds on the recently updated version of OSCOAP, extended= >>> with mandatory Sender ID and multiple Recipient Contexts. It also >>> enables source authentication with asymmetric signatures implemented = as >>> counter signatures included with the COSE objects defined by OSCOAP. >>> >>> We hope that by submitting now we could get some first discussion to >>> allow updates before the cutoff. >>> >>> This draft provides the missing link between >>> https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP. >>> >>> Best regards, >>> Marco >>> >>> >>> ---------- Forwarded message ---------- >>> From: ** >= >>> Date: Wed, Oct 12, 2016 at 9:27 AM >>> Subject: New Version Notification for >>> draft-tiloca-core-multicast-oscoap-00.txt >>> To: Marco Tiloca >, Goeran Selan= der >>> >, >>> Francesca Palombini >> > >>> >>> >>> >>> A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt >>> has been successfully submitted by Francesca Palombini and posted to = the >>> IETF repository. >>> >>> Name: draft-tiloca-core-multicast-oscoap >>> Revision: 00 >>> Title: Secure group communication for CoAP >>> Document date: 2016-10-12 >>> Group: Individual Submission >>> Pages: 15 >>> URL: =20 >>> >>> https://www.ietf.org/internet-drafts/draft-tiloca-core-multicast-osco= ap-0 >>> 0.txt >>> >>> >> 00.txt> >>> Status: =20 >>> https://datatracker.ietf.org/doc/draft-tiloca-core-multicast-oscoap/= >>> >>> Htmlized: =20 >>> https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00 >>> >>> >>> >>> Abstract: >>> This document describes a method for application layer protection = of >>> messages exchanged with the Constrained Application Protocol (CoAP= ) >>> in a group communication context. The proposed approach relies on= >>> Object Security of CoAP (OSCOAP) and the CBOR Object Signing and >>> Encryption (COSE) format. All security requirements fulfilled by >>> OSCOAP are maintained for multicast CoAP request messages and rela= ted >>> unicast CoAP response messages. Source authentication of all >>> messages exchanged within the group is ensured, by means of digita= l >>> signatures produced through asymmetric private keys of sender devi= ces >>> and embedded in the protected CoAP messages. >>> >>> >>> >>> >>> 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 >>> . >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --oSQde1uurvXsJodXURRp6fTfige6EsExI-- --B0viD8JvbCDnSWbIiViVKdP74s8bP7X5W 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/iOPAAoJEGhJURNOOiAtwd0H/1Fbyp64PtzSmEHlKO8ej8ux 1fFk5wM2Bv1FIJI5ie72BgrqD5wWIbd3EKsoxgmYQXUpRxF+35M1rrf/gYVqcH5Q rEu5IayYKETKRkKdbRAn1K1UgW5n9pun9b2YroT0QF7FDfKrZzOT8JQyj9fKG1Zt coAP0sW3EK+JY5Ee1PgZWA9DSQJR6JVU/N9SgHSSzzQ+TzduzBA9HK9rUZNai+Mr TSmamtiBXE8OQgjaEI3mNSuSBi64EyzV9u784L6I8LTBjCgpfMo3S+s9+iiGTnZ/ LdWkKG3iKPNQf5eM+NWKTRsSpzvogTd3hBv68leY/xfNrZo2LYjWV6WVrEppEUw= =eCj5 -----END PGP SIGNATURE----- --B0viD8JvbCDnSWbIiViVKdP74s8bP7X5W-- From nobody Wed Oct 12 05:17:19 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A451294AC for ; Wed, 12 Oct 2016 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com 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 Ry_jN9inV2jk for ; Wed, 12 Oct 2016 05:17:15 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10090.outbound.protection.outlook.com [40.107.1.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F2F1293F4 for ; Wed, 12 Oct 2016 05:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zy/EcuvYI5KgfMrnArZN25ZTovahV8kgQ0qVm04Bi3Q=; b=THvQ4tig4rPPH2z8SBRpoJ9sW8vptyZXmv4vGFYE0O/rchzCCFe5iWGc3DrO4dvdSYRs3II2/CsHWgrWGi2sTojD1kUVCE5H/hnDHo1W627zvNusruXbHnXum3Xrdhqr7FjddFqKZxzg58xp9Bq1Le2UgMk+/fY+4xsO+RGhJiI= Received: from DB4PR04CA0011.eurprd04.prod.outlook.com (10.160.41.21) by VI1PR04MB1264.eurprd04.prod.outlook.com (10.162.121.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Wed, 12 Oct 2016 12:17:10 +0000 Received: from AM1FFO11FD052.protection.gbl (2a01:111:f400:7e00::106) by DB4PR04CA0011.outlook.office365.com (2a01:111:e400:9852::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12 via Frontend Transport; Wed, 12 Oct 2016 12:17:09 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.84) smtp.mailfrom=philips.com; gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.84) by AM1FFO11FD052.mail.protection.outlook.com (10.174.65.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Wed, 12 Oct 2016 12:16:51 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com (129.75.99.82) by VI1PR9003MB0240.MGDPHG.emi.philips.com (129.75.99.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 12 Oct 2016 12:16:50 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) by VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) with mapi id 15.01.0649.027; Wed, 12 Oct 2016 12:16:50 +0000 From: "Kumar SS, Sandeep" To: Hannes Tschofenig , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Marco Tiloca , "Ace@ietf.org" Thread-Topic: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt Thread-Index: AQHSJGCYtb3aVwulzkqOX5gk7VKRKaCkf8KAgAAv94CAAAU5gIAABCGA Date: Wed, 12 Oct 2016 12:16:50 +0000 Message-ID: References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> In-Reply-To: <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] X-MS-Office365-Filtering-Correlation-Id: 82818651-dd2d-4664-0d84-08d3f299a5ef Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: VI1PR9003MB0240.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.84; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(85714005)(377424004)(24454002)(374574003)(199003)(13464003)(377454003)(189002)(55904004)(305945005)(69596002)(586003)(33646002)(7736002)(15650500001)(50466002)(68736007)(2501003)(7846002)(81156014)(356003)(2906002)(8676002)(66066001)(19580405001)(8936002)(15975445007)(19580395003)(2420400007)(92566002)(2900100001)(87936001)(102836003)(10400500002)(3846002)(6116002)(11100500001)(5660300001)(4001150100001)(626004)(47776003)(76176999)(2950100002)(50986999)(54356999)(86362001)(101416001)(7110500001)(106116001)(107886002)(81166006)(106466001)(93886004)(230783001)(97736004)(23676002)(105586002)(7696004)(108616004)(24736003)(5001770100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB1264; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD052; 1:znsXdVhLUPklKrlTg7/hLazBJxAcawqTgy0se0Zi5dx4e8HOIzYm4u7iwoPnciIKqJHUZqzhrjicVNS4ecRzYa6v/XrHfpdk6D1V7rcE7W/VAAAwHUhHPvvQo/O4paQ54cby0W9VYfuEKFOKI8+wOJm3UfN9KMaSczVMCEJ3h8Zh5om2zLytE/gDWA2P3mnxBmuflHvbcP910GyIBKu34M+Ffko29fLLSsqTuy2s2EzfSJmuBXTeznWrQh99t0QnjI0uPOpZH4w+TYbZVJ56L2xXUXJo2bD/HqPN+4uopobbo5FZlUG/DuhTwtxrlMIzYs4l0wyMfawmfr9rrH40t/qDxNMs7YK8VRwREvtots5y9svG6WOarJSA+8xx1vz+7C638bzTeIN8ZantIyI6Cim5POQxOFLJTFJ+WVpElpe7EmAdjK4x44qiMboO7GlG60OgGDQcgh2L/A6rjSKM+INzef/y/Th9HUl7owuKC0bxvyZblzJHdUQwyKKYQwMK X-CrossPremisesHeadersFiltered: AM1FFO11FD052.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1264; 2:OPawqndftGgtttqL9z1zNj61mQ+Xpu+2YG5jzA+NmQ4WlAxloNn0ZjiIGjp5TVE5bs/anh+1k0H6m6aR4xbVvDRLWIuxt55byq/zUUrduWErztUPyQ4VjI0pAUttjJwsRdcCDJt84O4LCDzZ/ZS6MyRIMUK10PXX0wxkjXzUWrerGVe5mez1afxLIj0iGylWDP5i8+YtafhyTkLxvUnQhQ==; 3:1nmuAh9bC5SxFlEyNiW8fViGE+0CBDXE+2X+4plWlQ8PHO4CEkrLHkENsSeqvES1RctSXGEm215pmVbC2f/Tt73taWU0OjzM3x6yFwP54CEOjZIhzyP3XNQJvS3swZukMUjvc3E4ARVatmcgzIQUrg/Na2Lgvz9k0bWXNcBd12Kd5lET5OpIlNGmobvmdQGqKomumgo+Oo2egiMhZDUatGBDmb/jnQrEJabVmilpfSY03oUZauli3moj8wUoH7M4; 25:bvgOgd/T7x3fryynNUb7H0MOv4OmaAroU4TR8OSfdFK+BhcHNWysKmPjS1frNOHbWKdtTS6TXVP14TukVclo3YIr/OgXKPXEl5ZfgB/P0KFZn7TNc+so0QSfV1DTVwidBTYOJO+mlj+XcrFYnoQ7Gtnyikfx5BFqQwDDhKUlduVzrtgcDAJ8Trnt5GOygE+Qm4RECuHJZHPBi/tqdXbjEuwKnsPS3PWmV8lvrx+paXYNAMMYhoIF5Fcc9SF9D7ZjgkRYpc+F0LIjHgtU1M4jUkfEeYKMCMLqL9YqavLPmWhiBH0ZJqjDIcKRRCJVgkUffFsR5LjWNFcqW4zG0g/nOSx8uzNJtqnF1ZSr/FWaTlOj/YT3fz3aIhp63hWAWfN5QKwqFJx2Edel+oYRfIIA3nGnFHiKV9Ly7wHCTGrG8pM4HIPobQaahLlBV+zrhB7h X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB1264; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1264; 31:odapyeLbnqT6VNat2KlXoUsm6mhrNIgU4LV5ySho8XMtNKr1udxEqP0a9d2kpkzP+8Qp8X3fEWvJjLTAfKBhnH8XT8VPAr/t8OTUnDXsZxbobaB24n81uoFCbS9l0mX6C2MqLv2OjHYhbVIJ9P1CDXaeVy82MX1YsN6Er5A+hOHhegwBeyKpojZ3g2KBNvLDe0yJvVoLkrUAzH2oTlpH5+JMiXSZYGbCTpjo1BWHyQXmZIj6+Jeo5mlfIB47VUz7bsJY5jQuors8I9SU7Jty+g==; 20:fv3BgnqjvqBtWJMuntfGgfO2+3eamKUis4zrh72zOJtfPDZQU0whV0o9XgR4PTdHkZcvFjYTGSzdi046nVbaunz/+IgJobQb10zT9o+qceX6c2bg5KDMyAAgOPkTbUp34Jl+n36hzJOs6954jxvyY43fAzBlCHx00vocQ+36mhKrWya6cHLgcEa5+6+f7YRw2z3NE2Q5ffZXnDbjNmUPa1DqjZU4wJ38Cuoph+cRYodpixuE8ifF+rohskAJyX15Oo8FKKXzQ/3jnOPg1TPFj0e1zyo4NKf4Ne5VWzcT+/zfzhUWyGbOORJVo4GNBjEMlxB8041UCrdSmfsgPxk/a0wSCucg7yn1nI7pIV61Vnt/Vum2pmB/oWYAHkLukUXrwygBGyqiCODijSJL27RjVIywXRKpeg9O6m79YeVwRxbrmJBFAxFuf0AHGDjBfbzomKO+/AX0ei2CV8dn9mdj0DdelwuDVE4VHBvZU+s5GT2dlFgbOzq8V3aqnINvt8Gs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(120809045254105)(192374486261705)(248736688235697); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(8121501046)(5005006)(13016025)(10201501046)(3002001)(6055026); SRVR:VI1PR04MB1264; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1264; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1264; 4:ydwT0Rt0A4GdzHOtXCoZJDQAvEe6gSLn94wOp8HUexhyHX/jILw6h8bNDDZyuMJXSmaxdnAj0D288NrYQWGEk6FO9YJ8vBUVkHqx+JSj50VShyGeNEs83ZQBalcEKwXYQtbiXXC6e8gSQTRpGW91THI4U0WOIrB/GJE8ylgoPsnb+2sKh/m/fr1GLyZbCNrSofr1R0Y2FgA4nQed5awu/kcAyCAiex+xyxc5McvrtrvytbNsWfUpmhojP65mxDjMY+BDNH6GkOc4AZajiaYSPw5jSat08UsjwEXwpxTkvOKQKlLXez+WKzp+jls9LBxTM11sniJ3G4KtoAY1wOns8MiT6haTzF0tYK/pHJfOOV9JzB7ykIJIr6mo5mLL4mGA5W+H1X1EpXmPQIy5s3KTOYVKso9nVNUmoPbc4EBXANp4Wp7fpCCHXIb5hHbCxu7nJ4NuI51E/avGOmSfLpqCJJIJIkb6VOZ+BYw3ZjUkpBGYZhrtef7TpvOKvB9XTjHm+ncPDHSQruzhDODqMR06F0dgFNWGv/bWMJts0guIfy+5+F4Kqb3dyckglu/N4p60lygy9d+tbtvgBeqFke42NZ6cLgudAc6fnq1LYSi2gq8= X-Forefront-PRVS: 0093C80C01 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA0TUIxMjY0OzIzOkdoUnZERDVkVU5OQUxaSkZkTi9NTmF4dFdm?= =?utf-8?B?UEN2THhrMU02S3JqNzhEZEk5UmRlSGJZb2RvcDZiSWl2M1JjQnJBVUV5WWtM?= =?utf-8?B?ZmJNUGwycnhBUG9QeWdqS2NLRGxRNEt6VitnSHdaWDJMZzRCRUU3NFdBS0s5?= =?utf-8?B?bmJCcW9DcDBhZjRmdWtZdnJPQ3lXYlpqVk1sYjJYeStGK25KbU1Yb2RUS3Nr?= =?utf-8?B?cmFWQ1Evbkk2UUhkN2p2emhCMGxzTzVDWEs0VzlYZWF1ZGxHOFZYTlhnUTg4?= =?utf-8?B?K0djYUMvOWdzUlFvWnRZVzFlS2h4MHdiajM1RTVyOGtmS2NUSDVlU2xkSkRF?= =?utf-8?B?VlVlczNPME50WVk2dDdoQTl4YVNySDB3L2ppUm1CT1JJQWYwSjZTb3hjam0r?= =?utf-8?B?KzhYUW5tT1NQUWJzb1dQRTdGNlljWFFEazV0b3E4Lzh6aE5jOTZXeHN5MnJK?= =?utf-8?B?Tmc3azFqSThualFEZTl3b0R5dTBKV21DMSs1eEpHR3F1UDhDbFRHNHdLR0Zn?= =?utf-8?B?d0RFVlg0djhuQkdnOVVqcGY0N0lJNUxqTU5xMzc1MWtySjlnaG5tWEVEYW1z?= =?utf-8?B?eGtqL2d0c29LeGpFaXQwOU0wNEtSVk5XdDZOVUJzcDJMSVd0UE5UUjFVbS9J?= =?utf-8?B?bDZLTGNJUUE1c2RWUWsyeENYOXRiWXd0RkczWDZDcURLdTZuZy9PQnkrNVMy?= =?utf-8?B?ZEZSNGx2T1h3ZVh1bjhCVUFTRVZGRWdEZkJ5SVlwa0tWL0NqUGwweDkyUFZ1?= =?utf-8?B?RHV2M3Q5Z3hKV3o2NXhuNXR4UU5hdEJIb2RTSGZ4Uis2U21DYmVYdnR6VVI5?= =?utf-8?B?VXI1NmhWSW1JREtVV2NpK3YrRW5LSXlTZTJJREY1cmRoeUZ3QUt4UEhXdjBJ?= =?utf-8?B?a3JSRmVRNEJ4aW0yZWpiN1lvSFl0T0F2MThKUzNnSjV0WWZFaGdOL0orUGJl?= =?utf-8?B?Q1hEWkdrYVF6a1FrbnJ1RnFRZ3lhRlJROE5obHVtTWREZVJNQUc4K1RzblNx?= =?utf-8?B?RU10b1dXZ2hQME5jVVZWMXgwald0NTgxVVQ5RU92ZUlTMFpYK0xrR2V1VzlZ?= =?utf-8?B?LzVVUDZzRUwwQlZONzhWUUtnVHpRSElKekkyYU8zZHFibXBGTkhoRllUOExl?= =?utf-8?B?TCtxWGYwcVlaNTEvWk5pSTE2Q2RwQWtFWEtDVEVCczl0UlMzOHRRV2pYRjVD?= =?utf-8?B?ajM3MWMzZ3I3QXQ0andaY2VaSnRpcytkWERFNG94MFdwMXBaUTlOZjBpeU9n?= =?utf-8?B?bTJvN3JCM3hUekhkNXljclgzdzJWZy9IaGUzd2tsV1RpenVua1Vna3MvS1lt?= =?utf-8?B?YjZJNDlWSE9DbWVySG1EdTFZUEtKbHp4dnZIUHI0b2o5YllqbFZpRHpxcHpU?= =?utf-8?B?VDBZWlR1blpVSlZKUm9IMktoWlhlRXpCMFVLczExdUVDcHhxVm4zRkpFbmQx?= =?utf-8?B?NVlmcVAwcndjSjFoMloyR0RrckN1bnViaTRMMXdrWWZzMnkyTmorcmhsK0k4?= =?utf-8?B?aTlGUElHZ21ObUZNNmhBK2xxdkdwR3ZQZFp0dUNwN3lDVFF2SVdVRW11SDRz?= =?utf-8?B?Y2Ivckx0QnpKZ2txTHhTMHdhSEtsaU5SdDFDTVZnck1LSzBqYm5PbEZLMEZL?= =?utf-8?B?TERoYzltSFp6SDJGMUIrSDBBRklobVZVTWRRSE51SDd5Z1ZOZVJKeXhza3hK?= =?utf-8?B?KzEreDFYWjZNbnBXUWJkN3JOVGFTQTRjRkl6dlYzQlFtWXhTRk4zbVhHam0x?= =?utf-8?B?R0JGdzNqdy83Vm50UmpiMzNXK2w1MHJFL21VQzRZVGNLU2JabUoxNkR1R2Zi?= =?utf-8?B?WlFYRlNxalFIYmlXWUs2UTkyUUxHMXZxOFpSUlVlVGFGYTV5UElMajRXS0li?= =?utf-8?B?MGgrSHczcjNGazltWWlaTVU2eWxpKzFzTy9oVUdMb3FGanpsdmwxUjlCZW1s?= =?utf-8?B?MmJWR1hvMDNoUHNjK25EL21iZGxUVDcvOEFDWXNVcjhmYlhNQlFPUnNITDhz?= =?utf-8?B?dzFLZWRjdG96SjBBaXFNQXg1SGFiOG5IWU1PaU9mZEZmL0xROVEva28weWpz?= =?utf-8?B?NGFsTnhVNk1qWCtkaUswcll4Z2MySUdEMUNSZHByQWh4alJUQW9RQ3ViWmdx?= =?utf-8?B?VkVPbkhXbEt4MjhSUWFSNmUzcTFjOWhqTkdvbi9aM29Kd1BLaVlVWmRaODZ1?= =?utf-8?B?dUlCMnBwU3l6TmU2bldISWIxeXlnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1264; 6:2SX4M05GURpvim72IU1qTTmvslWX9ayZu68R+EcaD4h8e9mJM1f2t6f9Tnjehgf5UQyzBPjROovGg9M5JclAVpDcF4bp7xvCiMlNiAO0zVWdNISzyX3AOwJH0K8rGlBWpJUmqXItUY2HYPL1zFSTrprz9GcAwaND5VZ1CovCUB4WFCOgtmagHK8Plzl3UeSkDtD8KfI6m1UPgRHX1+yo76pEIt797Y5uQnfTkQVFso2TltX52iSMG1LlgV7GtYlxbg/vTSSpL8MxQJj/d6Gf4yA314ibr/oYKgxd9OXuy1TQZWsI9M5+mC4xvBor+ME3QPRTmSbSNb7SKVEAh0eFfqbkMAJw8OY/BHFN5lnmY7M=; 5:TbwW6RTA7t0PvUVo+SvVYamRcOKm55gU3bYgrSUF9MAOAAXnMCdrg1yv3Vvi8HTHVf0EWs/NxQFlBgJvdFtpYnVBVZG+jF3nZLX/Gn2zKAfMxjjscXi/UJb58gIBXGS3Zw2iA56yZ8rfLQT46SfkJRTRcyVOrK09JikTfMl4smk=; 24:5eckEhZS9FOvH3whkKcdriKeFSmNb0jVMUWnaRhFRqvXkD4ziR53izTlrRZ5mpWbe1Z3jBvfGk+VXGw7sfBPkACJRJKAK8JxH4Y7lgqSzPI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1264; 7:Rs6Kx5k0GR57sZSyCP3aCaOJCuS/jIShR5mGb/Ud+J6vUouM9y+X/fDhimpbhQe8v7Z8zISaTlR2+BH7koeZE+BpyKnfJo295GFqvX4pKre+db6MkzpOqtWzau9GG29xMBb2OybGLYU7n++O6cW39nj492gjkTBlJHls/cKLrWZP5NhWdHblkvc7pmyj6yBtwLbFfLxnxQW2s1uNUhwFNHBIehqsmrrxIPq4lFNxkJZG3iCjEyEcZ7HpfO58qtBlhWP1E9CvQ74O42dtLj+gc5YAxYzVSqBc9JLiw/1rWj6wOgLbJf8x2SHAG1Sq/Y8naTzEUX5zXPN43M2h2xvuuTcgbMELqYuOYo/ipVXI/lo= X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2016 12:16:51.6729 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.84]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1264 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.84 X-MS-Exchange-CrossPremises-AuthSource: AM1FFO11FD052.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR04MB1264.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 12:17:18 -0000 SSBhZ3JlZSB3aXRoIEhhbm5lcy4gVGhlIGNoYW5nZXMgbmVlZCB0byBPU0NPQVAgd2FzIHF1aXRl IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgY2xlYXIgZnJvbSB0aGUgYmVnaW5uaW5nLCB3ZSB3ZXJlIHdh aXRpbmcgZm9yIE9TQ09BUCB0byBiZSBzdGFibGUuIFRoZSBtaW5vciBjaGFuZ2VzIGNvdWxkIGhh dmUgYmVlbiBkaXJlY3RseSB0YWtlbiBpbnRvIE9TQ09BUCB3aXRoIGFuIG9wdGlvbmFsIFNlbmRl cklEIGZpZWxkLiBJZiB0aGF0IGlzIG5vdCBwb3NzaWJsZSwgdGhlbiBpdCBjYW4gYmUgZG9uZSBk aXJlY3RseSBpbiB0aGUgQUNFIGRyYWZ0LiBJIGRvIG5vdCBzZWUgYW55IHZhbHVlIGluIGFuIGFk ZGl0aW9uYWwgZHJhZnQgdG8gc29sdmUgdGhpcyBtaW5vciBzdWItaXNzdWUuDQoNClNhbmRlZXAN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBY2UgW21haWx0bzphY2Ut Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IFNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAxMiwgMjAxNiAxOjUxIFBNDQo+IFRvOiBHw7ZyYW4gU2VsYW5k ZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT47IE1hcmNvIFRpbG9jYQ0KPiA8bWFyY29A c2ljcy5zZT47IEFjZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0FjZV0gW2NvcmVdIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aWxvY2EtY29yZS0NCj4gbXVsdGlj YXN0LW9zY29hcC0wMC50eHQNCj4NCj4gSGkgR29lcmFuLA0KPg0KPiB0aGVyZSB3YXMgbmV2ZXIg YW55IGRvdWJ0IHRoYXQgd2UgY2FuIHVzZSBDT1NFIHRvIGRlc2lnbiBhIHNlY3VyaXR5DQo+IHNv bHV0aW9uIHVzaW5nIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGJ1aWxkaW5nIGJsb2Nrcy4NCj4NCj4g QnR3LCBpbiB0aGUgbWVhbndoaWxlIHdlIGhhdmUgYWN0dWFsbHkgY29uY2x1ZGVkIHRoZSBkaXNj dXNzaW9uIGluIEFDRSBvbg0KPiB0aGUgZ3JvdXAgY29tbXVuaWNhdGlvbiBzZWN1cml0eSB0b3Bp Yywgc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtDQo+IGFyY2hpdmUvd2ViL2FjZS9jdXJy ZW50L21zZzAxOTY3Lmh0bWwNCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4gUFM6IFlvdSBjYW5u b3QgZGVjb3VwbGUgdGhlIHF1ZXN0aW9uIG9mIGFkb3B0aW9uIG9mDQo+IGRyYWZ0LXNvbWFyYWp1 LWFjZS1tdWx0aWNhc3QtMDEgZnJvbSB0aGUgcXVlc3Rpb24gb2Ygc291cmNlIGF1dGhlbnRpY2F0 aW9uDQo+IHNpbmNlIHRoaXMgd2FzIHRoZSBjb3JlIGlzc3VlIG9mIHRoZSBkZWJhdGUuDQo+DQo+ IE9uIDEwLzEyLzIwMTYgMDE6MzEgUE0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4gPg0KPiA+ IEhpIEhhbm5lcywNCj4gPg0KPiA+IEnigJltIGEgYml0IHN1cnByaXNlZCBhdCB5b3VyIHJlYWN0 aW9uLiBJZiB5b3UgaGF2ZSBmb2xsb3dlZCB0aGUNCj4gPiBkaXNjdXNzaW9uIG9uIE9TQ09BUCB5 b3Uga25vdyB0aGF0IG9uZSByZWN1cnJpbmcgcmVxdWVzdCBoYXMgYmVlbiBvbg0KPiA+IHN1cHBv cnQgZm9yIG11bHRpY2FzdC4gVGhpcyBkcmFmdCBpcyBhZGRyZXNzaW5nIHRoYXQgcmVxdWVzdC4N Cj4gPg0KPiA+IGRyYWZ0LXNvbWFyYWp1LWFjZS1tdWx0aWNhc3QtMDEgaXMgcmVmZXJyaW5nIHRv IE9TQ09BUCBmb3Igc2VjdXJlDQo+ID4gZ3JvdXAgY29tbXVuaWNhdGlvbiBhbmQgd2UgcHJvcG9z ZSB0aGlzIGRyYWZ0IHRvIGJlIHRoZSB3YXkgdG8gZXh0ZW5kDQo+ID4gT1NDT0FQIGZvciB0aGF0 IHB1cnBvc2UuDQo+ID4NCj4gPiBJbiB0aGUgImNvbnRyb3ZlcnNpYWwsIGxvbmcsIGFuZCB0b3Vn aOKAnSBkaXNjdXNzaW9uIHlvdSByZWZlciB0bywgb25lDQo+ID4gY2VudHJhbCBpc3N1ZSByZWxh dGVzIHRvIHRoZSB1c2Ugb2Ygc3ltbWV0cmljIGtleXMgb25seSBpbiBncm91cA0KPiA+IGNvbW11 bmljYXRpb24uIE91ciBkcmFmdCBtYW5kYXRlcyB0aGUgdXNlIG9mIGFzeW1tZXRyaWMga2V5cyBz aW5jZQ0KPiA+IHRoYXQgcHJvdmlkZXMgc291cmNlIGF1dGhlbnRpY2F0aW9uLiBTaG91bGQgaXQg YmUgYWdyZWVkIHRoYXQgc291cmNlDQo+ID4gYXV0aGVudGljYXRpb24gZm9yIHNvbWUgcHVycG9z ZSBpcyBub3QgbmVjZXNzYXJ5LCBpdCBpcyBhIHNpbXBsZQ0KPiA+IG1vZGlmaWNhdGlvbiBvZiB0 aGlzIGRyYWZ0IC0gc2ltcGx5IG1ha2luZyB0aGUgY291bnRlciBzaWduYXR1cmUgaW4NCj4gPiB0 aGUgQ09TRSBvYmplY3Qgbm9uLW1hbmRhdG9yeS4NCj4gPg0KPiA+IEl0IHdhcyBvdXIgaG9wZSB0 aGF0IHdlIGluIHRoaXMgd2F5IGNhbiBkZWNvdXBsZSB0aGUgcXVlc3Rpb24gb2YNCj4gPiBhZG9w dGlvbiBvZiBkcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0LTAxIGZyb20gdGhlIHF1ZXN0aW9u IG9mDQo+ID4gc291cmNlIGF1dGhlbnRpY2F0aW9uLg0KPiA+DQo+ID4gR8O2cmFuDQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBPbiAyMDE2LTEwLTEyIDEwOjQwLCAiQWNlIG9uIGJlaGFsZiBvZiBI YW5uZXMgVHNjaG9mZW5pZyINCj4gPiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPiA+DQo+ID4+IEhpIE1hcmNvLCBI aSBGcmFuY2VzY2EsIEhpIEdvZXJhbiwNCj4gPj4NCj4gPj4gSSBhbSBhIGJpdCBzdXJwcmlzZWQg YWJvdXQgeW91ciBkb2N1bWVudCBzdWJtaXNzaW9uIHNpbmNlIHlvdSBndXlzDQo+ID4+IGhhdmUg YmVlbiBwcmV0dHkgc2lsZW50IGluIHRoZSBncm91cCBjb21tdW5pY2F0aW9uIHNlY3VyaXR5DQo+ ID4+IGRpc2N1c3Npb24sIHdoaWNoIHdhcyBxdWl0ZSBjb250cm92ZXJzaWFsLCBsb25nLCBhbmQg dG91Z2guIFRoYXQncw0KPiA+PiB3aGVyZSB5b3VyIHN1cHBvcnQgd291bGQgaGF2ZSBiZWVuIG5l ZWRlZC4gQWRkaW5nIHRoZSBmZXcgc21hbGwgYml0cw0KPiA+PiB0byB0aGUgYWxyZWFkeSB3cml0 dGVuIGRyYWZ0IGlzbid0IHRoZSBwcm9ibGVtLg0KPiA+Pg0KPiA+PiBDaWFvDQo+ID4+IEhhbm5l cw0KPiA+Pg0KPiA+PiBPbiAxMC8xMi8yMDE2IDEwOjEyIEFNLCBNYXJjbyBUaWxvY2Egd3JvdGU6 DQo+ID4+PiBEZWFyIENvUkUvQUNFLA0KPiA+Pj4NCj4gPj4+IFdlIGhhdmUgc3VibWl0dGVkIGEg ZHJhZnQgb24gc2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVANCj4gPj4+IGFkZHJl c3Npbmcgc2VjdXJpdHkgZm9yIHRoZSBzZXR0aW5nIG9mIGEgbXVsdGljYXN0IENvQVAgcmVxdWVz dCB3aXRoDQo+ID4+PiB1bmljYXN0IHJlc3BvbnNlcyBhcyBkZXNjcmliZWQgaW4gUkZDNzM5MC4N Cj4gPj4+DQo+ID4+PiBUaGlzIGRyYWZ0IGJ1aWxkcyBvbiB0aGUgcmVjZW50bHkgdXBkYXRlZCB2 ZXJzaW9uIG9mIE9TQ09BUCwNCj4gPj4+IGV4dGVuZGVkIHdpdGggbWFuZGF0b3J5IFNlbmRlciBJ RCBhbmQgbXVsdGlwbGUgUmVjaXBpZW50IENvbnRleHRzLg0KPiA+Pj4gSXQgYWxzbyBlbmFibGVz IHNvdXJjZSBhdXRoZW50aWNhdGlvbiB3aXRoIGFzeW1tZXRyaWMgc2lnbmF0dXJlcw0KPiA+Pj4g aW1wbGVtZW50ZWQgYXMgY291bnRlciBzaWduYXR1cmVzIGluY2x1ZGVkIHdpdGggdGhlIENPU0Ug b2JqZWN0cw0KPiBkZWZpbmVkIGJ5IE9TQ09BUC4NCj4gPj4+DQo+ID4+PiBXZSBob3BlIHRoYXQg Ynkgc3VibWl0dGluZyBub3cgd2UgY291bGQgZ2V0IHNvbWUgZmlyc3QgZGlzY3Vzc2lvbiB0bw0K PiA+Pj4gYWxsb3cgdXBkYXRlcyBiZWZvcmUgdGhlIGN1dG9mZi4NCj4gPj4+DQo+ID4+PiBUaGlz IGRyYWZ0IHByb3ZpZGVzIHRoZSBtaXNzaW5nIGxpbmsgYmV0d2Vlbg0KPiA+Pj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvbWFyYWp1LWFjZS1tdWx0aWNhc3QgYW5kIE9TQ09B UC4NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBNYXJjbw0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gPj4+IEZy b206ICoqIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPj4+IDxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4NCj4gPj4+IERhdGU6IFdlZCwgT2N0IDEyLCAyMDE2IGF0IDk6Mjcg QU0NCj4gPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4+IGRy YWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDAudHh0DQo+ID4+PiBUbzogTWFyY28g VGlsb2NhIDxtYXJjb0BzaWNzLnNlIDxtYWlsdG86bWFyY29Ac2ljcy5zZT4+LCBHb2VyYW4NCj4g Pj4+IFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20NCj4gPj4+IDxtYWlsdG86 Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj4sDQo+ID4+PiBGcmFuY2VzY2EgUGFsb21iaW5p IDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbQ0KPiA+Pj4gPG1haWx0bzpmcmFuY2Vz Y2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0w MC50eHQNCj4gPj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2Nh IFBhbG9tYmluaSBhbmQgcG9zdGVkIHRvDQo+ID4+PiB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiA+ Pj4NCj4gPj4+IE5hbWU6ICAgICAgICAgICBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Nj b2FwDQo+ID4+PiBSZXZpc2lvbjogICAgICAgMDANCj4gPj4+IFRpdGxlOiAgICAgICAgICBTZWN1 cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUA0KPiA+Pj4gRG9jdW1lbnQgZGF0ZTogIDIw MTYtMTAtMTINCj4gPj4+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g Pj4+IFBhZ2VzOiAgICAgICAgICAxNQ0KPiA+Pj4gVVJMOg0KPiA+Pj4NCj4gPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qt b3NjDQo+ID4+PiBvYXAtMA0KPiA+Pj4gMC50eHQNCj4gPj4+DQo+ID4+PiA8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vcw0K PiA+Pj4gY29hcC0NCj4gPj4+IDAwLnR4dD4NCj4gPj4+IFN0YXR1czoNCj4gPj4+DQo+ID4+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNh c3Qtb3Njb2FwLw0KPiA+Pj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAvPg0KPiA+Pj4gSHRtbGl6ZWQ6DQo+ID4+PiAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1v c2NvYXAtMDANCj4gPj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2Nh LWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMD4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWJzdHJhY3Q6 DQo+ID4+PiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgYXBwbGljYXRp b24gbGF5ZXIgcHJvdGVjdGlvbiBvZg0KPiA+Pj4gICAgbWVzc2FnZXMgZXhjaGFuZ2VkIHdpdGgg dGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKQ0KPiA+Pj4gICAgaW4g YSBncm91cCBjb21tdW5pY2F0aW9uIGNvbnRleHQuICBUaGUgcHJvcG9zZWQgYXBwcm9hY2ggcmVs aWVzIG9uDQo+ID4+PiAgICBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUCAoT1NDT0FQKSBhbmQgdGhl IENCT1IgT2JqZWN0IFNpZ25pbmcgYW5kDQo+ID4+PiAgICBFbmNyeXB0aW9uIChDT1NFKSBmb3Jt YXQuICBBbGwgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZ1bGZpbGxlZCBieQ0KPiA+Pj4gICAgT1ND T0FQIGFyZSBtYWludGFpbmVkIGZvciBtdWx0aWNhc3QgQ29BUCByZXF1ZXN0IG1lc3NhZ2VzIGFu ZA0KPiByZWxhdGVkDQo+ID4+PiAgICB1bmljYXN0IENvQVAgcmVzcG9uc2UgbWVzc2FnZXMuICBT b3VyY2UgYXV0aGVudGljYXRpb24gb2YgYWxsDQo+ID4+PiAgICBtZXNzYWdlcyBleGNoYW5nZWQg d2l0aGluIHRoZSBncm91cCBpcyBlbnN1cmVkLCBieSBtZWFucyBvZiBkaWdpdGFsDQo+ID4+PiAg ICBzaWduYXR1cmVzIHByb2R1Y2VkIHRocm91Z2ggYXN5bW1ldHJpYyBwcml2YXRlIGtleXMgb2Yg c2VuZGVyDQo+IGRldmljZXMNCj4gPj4+ICAgIGFuZCBlbWJlZGRlZCBpbiB0aGUgcHJvdGVjdGVk IENvQVAgbWVzc2FnZXMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCj4gPj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdA0KPiA+Pj4gdG9vbHMuaWV0Zi5vcmcgPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQo+ID4+Pg0KPiA+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4gQWNlIG1haWxpbmcgbGlzdA0KPiA+Pj4gQWNlQGlldGYub3JnDQo+ ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiA+Pj4NCj4g Pj4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+IEFjZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+ID4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBw bGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJl c3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBv ciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFs bCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Wed Oct 12 05:31:58 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3F129447 for ; Wed, 12 Oct 2016 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bPCwlUr8hcNW for ; Wed, 12 Oct 2016 05:31:54 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9AE851293F4 for ; Wed, 12 Oct 2016 05:31:53 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-0a-57fe2d366d52 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 51.17.02458.63D2EF75; Wed, 12 Oct 2016 14:31:51 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.183]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 14:31:49 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig Thread-Topic: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt Thread-Index: AQHSJGBb3IlreYskZUK0h4lx2n498qCkXjyAgABRfAD//+O0gIAAC3CA Date: Wed, 12 Oct 2016 12:31:48 +0000 Message-ID: <0DA0C0F0-BDE4-47FA-868F-849019929B31@ericsson.com> References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> In-Reply-To: <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-1FA6460A-72A4-4F04-8A65-6AF92BD791A3"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7k6657r9wg1nLjCy+f+thtli68x6r xZy1e9kcmD0Wb9rP5rFkyU8mj95jv9kCmKO4bFJSczLLUov07RK4MhY8Ws9asCG+4tKEY4wN jPdiuhg5OSQETCT2T/rN3MXIxSEksJ5RYs+2sywgCSGBJYwSWzvyQGw2AReJBw2PmEBsEQFD ieszp7OC2MwC9hIn5kxmBrGFBdIlzrR3s0PUZEgsenuPBcJ2k7h/5BZQDQcHi4CqxMy7MiBh XqDW1S17GSH2PmSUaHw0E6yeU8BaYvWdzWwgNqOAmMT3U2uYIHaJS9x6Mp8J4mgRiYcXT7NB 2KISLx//YwUZxCwwmVHiyc1XjBAbBCVOznzCMoFReBaS/lnI6mYhqYMo0pTY370cylaUmNL9 kB3CtpaY8esgG4RtKvH66EdGZDULGDlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG28Et v612MB587niIUYCDUYmHd4HG33Ah1sSy4srcQ4wqQHMebVh9gVGKJS8/L1VJhPeU1r9wId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhjNV59+ecq+QaZY 78CZmUcNkhaZz/ZtUz1gOUdvCgNj/Gq9XW6xn64WWDn+/tR0UTqxYGPlsUXxeme/v21jmqai sGye4JWMAKXzUQambc/PNCYtOfuw6NY1cxnB7iM8/o8iBZedrLZkudCq7dCQ8EZdpjZqHdOC pbsKnvBt6N3gpVV9Y9LBtepKLMUZiYZazEXFiQA3eg3fvwIAAA== Archived-At: Cc: Marco Tiloca , "Ace@ietf.org" Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 12:31:56 -0000 --Apple-Mail-1FA6460A-72A4-4F04-8A65-6AF92BD791A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpJIG11c3QgYWRtaXQgSSBkaWRuJ3QgdW5kZXJzdGFuZCB0aGF0IHdhcyB0 aGUgY29uY2x1c2lvbi4gU28sIGlzIHNvdXJjZSBhdXRoZW50aWNhdGlvbiBtYW5kYXRvcnkgb3Ig bm90Pw0KDQoiZGVjb3VwbGVkIiBtZWFudCB0aGF0IHdlIGNvdWxkIHdvcmsgb24gYSBzb2x1dGlv biB3aGljaCBhbGxvd2VkIHRvIGJlIGFkYXB0ZWQgdG8gYWxsIHN5bW1ldHJpYyBvciBhc3ltbWV0 cmljIGtleXMsIG11Y2ggaW4gdGhlIHNlbnNlIEFiaGluYXYgZXhwcmVzc2VkIGluIHRoZSByZWZl cnJlZCBsaW5rLiANCg0KR8O2cmFuDQoNCj4gT24gMTIgb2t0LiAyMDE2LCBhdCAxMzo1MCwgSGFu bmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPiANCj4g SGkgR29lcmFuLA0KPiANCj4gdGhlcmUgd2FzIG5ldmVyIGFueSBkb3VidCB0aGF0IHdlIGNhbiB1 c2UgQ09TRSB0byBkZXNpZ24gYSBzZWN1cml0eQ0KPiBzb2x1dGlvbiB1c2luZyB0aGUgYWxyZWFk eSBleGlzdGluZyBidWlsZGluZyBibG9ja3MuDQo+IA0KPiBCdHcsIGluIHRoZSBtZWFud2hpbGUg d2UgaGF2ZSBhY3R1YWxseSBjb25jbHVkZWQgdGhlIGRpc2N1c3Npb24gaW4gQUNFDQo+IG9uIHRo ZSBncm91cCBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IHRvcGljLCBzZWUNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTk2Ny5odG1sDQo+IA0K PiBDaWFvDQo+IEhhbm5lcw0KPiANCj4gUFM6IFlvdSBjYW5ub3QgZGVjb3VwbGUgdGhlIHF1ZXN0 aW9uIG9mIGFkb3B0aW9uIG9mDQo+IGRyYWZ0LXNvbWFyYWp1LWFjZS1tdWx0aWNhc3QtMDEgZnJv bSB0aGUgcXVlc3Rpb24gb2Ygc291cmNlDQo+IGF1dGhlbnRpY2F0aW9uIHNpbmNlIHRoaXMgd2Fz IHRoZSBjb3JlIGlzc3VlIG9mIHRoZSBkZWJhdGUuDQo+IA0KPj4gT24gMTAvMTIvMjAxNiAwMToz MSBQTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4gDQo+PiBIaSBIYW5uZXMsDQo+PiANCj4+ IEnigJltIGEgYml0IHN1cnByaXNlZCBhdCB5b3VyIHJlYWN0aW9uLiBJZiB5b3UgaGF2ZSBmb2xs b3dlZCB0aGUgZGlzY3Vzc2lvbg0KPj4gb24gT1NDT0FQIHlvdSBrbm93IHRoYXQgb25lIHJlY3Vy cmluZyByZXF1ZXN0IGhhcyBiZWVuIG9uIHN1cHBvcnQgZm9yDQo+PiBtdWx0aWNhc3QuIFRoaXMg ZHJhZnQgaXMgYWRkcmVzc2luZyB0aGF0IHJlcXVlc3QuDQo+PiANCj4+IGRyYWZ0LXNvbWFyYWp1 LWFjZS1tdWx0aWNhc3QtMDEgaXMgcmVmZXJyaW5nIHRvIE9TQ09BUCBmb3Igc2VjdXJlIGdyb3Vw DQo+PiBjb21tdW5pY2F0aW9uIGFuZCB3ZSBwcm9wb3NlIHRoaXMgZHJhZnQgdG8gYmUgdGhlIHdh eSB0byBleHRlbmQgT1NDT0FQIGZvcg0KPj4gdGhhdCBwdXJwb3NlLg0KPj4gDQo+PiBJbiB0aGUg ImNvbnRyb3ZlcnNpYWwsIGxvbmcsIGFuZCB0b3VnaOKAnSBkaXNjdXNzaW9uIHlvdSByZWZlciB0 bywgb25lDQo+PiBjZW50cmFsIGlzc3VlIHJlbGF0ZXMgdG8gdGhlIHVzZSBvZiBzeW1tZXRyaWMg a2V5cyBvbmx5IGluIGdyb3VwDQo+PiBjb21tdW5pY2F0aW9uLiBPdXIgZHJhZnQgbWFuZGF0ZXMg dGhlIHVzZSBvZiBhc3ltbWV0cmljIGtleXMgc2luY2UgdGhhdA0KPj4gcHJvdmlkZXMgc291cmNl IGF1dGhlbnRpY2F0aW9uLiBTaG91bGQgaXQgYmUgYWdyZWVkIHRoYXQgc291cmNlDQo+PiBhdXRo ZW50aWNhdGlvbiBmb3Igc29tZSBwdXJwb3NlIGlzIG5vdCBuZWNlc3NhcnksIGl0IGlzIGEgc2lt cGxlDQo+PiBtb2RpZmljYXRpb24gb2YgdGhpcyBkcmFmdCAtIHNpbXBseSBtYWtpbmcgdGhlIGNv dW50ZXIgc2lnbmF0dXJlIGluIHRoZQ0KPj4gQ09TRSBvYmplY3Qgbm9uLW1hbmRhdG9yeS4NCj4+ IA0KPj4gSXQgd2FzIG91ciBob3BlIHRoYXQgd2UgaW4gdGhpcyB3YXkgY2FuIGRlY291cGxlIHRo ZSBxdWVzdGlvbiBvZiBhZG9wdGlvbg0KPj4gb2YgZHJhZnQtc29tYXJhanUtYWNlLW11bHRpY2Fz dC0wMSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBzb3VyY2UNCj4+IGF1dGhlbnRpY2F0aW9uLg0KPj4g DQo+PiBHw7ZyYW4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNi0xMC0xMiAxMDo0MCwg IkFjZSBvbiBiZWhhbGYgb2YgSGFubmVzIFRzY2hvZmVuaWciDQo+PiA8YWNlLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPj4g DQo+Pj4gSGkgTWFyY28sIEhpIEZyYW5jZXNjYSwgSGkgR29lcmFuLA0KPj4+IA0KPj4+IEkgYW0g YSBiaXQgc3VycHJpc2VkIGFib3V0IHlvdXIgZG9jdW1lbnQgc3VibWlzc2lvbiBzaW5jZSB5b3Ug Z3V5cyBoYXZlDQo+Pj4gYmVlbiBwcmV0dHkgc2lsZW50IGluIHRoZSBncm91cCBjb21tdW5pY2F0 aW9uIHNlY3VyaXR5IGRpc2N1c3Npb24sIHdoaWNoDQo+Pj4gd2FzIHF1aXRlIGNvbnRyb3ZlcnNp YWwsIGxvbmcsIGFuZCB0b3VnaC4gVGhhdCdzIHdoZXJlIHlvdXIgc3VwcG9ydA0KPj4+IHdvdWxk IGhhdmUgYmVlbiBuZWVkZWQuIEFkZGluZyB0aGUgZmV3IHNtYWxsIGJpdHMgdG8gdGhlIGFscmVh ZHkgd3JpdHRlbg0KPj4+IGRyYWZ0IGlzbid0IHRoZSBwcm9ibGVtLg0KPj4+IA0KPj4+IENpYW8N Cj4+PiBIYW5uZXMNCj4+PiANCj4+Pj4gT24gMTAvMTIvMjAxNiAxMDoxMiBBTSwgTWFyY28gVGls b2NhIHdyb3RlOg0KPj4+PiBEZWFyIENvUkUvQUNFLA0KPj4+PiANCj4+Pj4gV2UgaGF2ZSBzdWJt aXR0ZWQgYSBkcmFmdCBvbiBzZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUA0KPj4+ PiBhZGRyZXNzaW5nIHNlY3VyaXR5IGZvciB0aGUgc2V0dGluZyBvZiBhIG11bHRpY2FzdCBDb0FQ IHJlcXVlc3Qgd2l0aA0KPj4+PiB1bmljYXN0IHJlc3BvbnNlcyBhcyBkZXNjcmliZWQgaW4gUkZD NzM5MC4NCj4+Pj4gDQo+Pj4+IFRoaXMgZHJhZnQgYnVpbGRzIG9uIHRoZSByZWNlbnRseSB1cGRh dGVkIHZlcnNpb24gb2YgT1NDT0FQLCBleHRlbmRlZA0KPj4+PiB3aXRoIG1hbmRhdG9yeSBTZW5k ZXIgSUQgYW5kIG11bHRpcGxlIFJlY2lwaWVudCBDb250ZXh0cy4gSXQgYWxzbw0KPj4+PiBlbmFi bGVzIHNvdXJjZSBhdXRoZW50aWNhdGlvbiB3aXRoIGFzeW1tZXRyaWMgc2lnbmF0dXJlcyBpbXBs ZW1lbnRlZCBhcw0KPj4+PiBjb3VudGVyIHNpZ25hdHVyZXMgaW5jbHVkZWQgd2l0aCB0aGUgQ09T RSBvYmplY3RzIGRlZmluZWQgYnkgT1NDT0FQLg0KPj4+PiANCj4+Pj4gV2UgaG9wZSB0aGF0IGJ5 IHN1Ym1pdHRpbmcgbm93IHdlIGNvdWxkIGdldCBzb21lIGZpcnN0IGRpc2N1c3Npb24gdG8NCj4+ Pj4gYWxsb3cgdXBkYXRlcyBiZWZvcmUgdGhlIGN1dG9mZi4NCj4+Pj4gDQo+Pj4+IFRoaXMgZHJh ZnQgcHJvdmlkZXMgdGhlIG1pc3NpbmcgbGluayBiZXR3ZWVuDQo+Pj4+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zb21hcmFqdS1hY2UtbXVsdGljYXN0IGFuZCBPU0NPQVAuDQo+ Pj4+IA0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+IE1hcmNvDQo+Pj4+IA0KPj4+PiANCj4+Pj4g LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQo+Pj4+IEZyb206ICoqIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ Pg0KPj4+PiBEYXRlOiBXZWQsIE9jdCAxMiwgMjAxNiBhdCA5OjI3IEFNDQo+Pj4+IFN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj4gZHJhZnQtdGlsb2NhLWNvcmUtbXVs dGljYXN0LW9zY29hcC0wMC50eHQNCj4+Pj4gVG86IE1hcmNvIFRpbG9jYSA8bWFyY29Ac2ljcy5z ZSA8bWFpbHRvOm1hcmNvQHNpY3Muc2U+PiwgR29lcmFuIFNlbGFuZGVyDQo+Pj4+IDxnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb20gPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+ PiwNCj4+Pj4gRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nv bi5jb20NCj4+Pj4gPG1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4+DQo+ Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aWxv Y2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAwLnR4dA0KPj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEZyYW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0byB0aGUNCj4+ Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+PiANCj4+Pj4gTmFtZTogICAgICAgICAgIGRyYWZ0LXRp bG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXANCj4+Pj4gUmV2aXNpb246ICAgICAgIDAwDQo+Pj4+ IFRpdGxlOiAgICAgICAgICBTZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29BUA0KPj4+ PiBEb2N1bWVudCBkYXRlOiAgMjAxNi0xMC0xMg0KPj4+PiBHcm91cDogICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQo+Pj4+IFBhZ2VzOiAgICAgICAgICAxNQ0KPj4+PiBVUkw6ICAgICAg ICAgICANCj4+Pj4gDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTANCj4+Pj4gMC50eHQNCj4+Pj4gDQo+ Pj4+IDxodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGlsb2NhLWNv cmUtbXVsdGljYXN0LW9zY29hcC0NCj4+Pj4gMDAudHh0Pg0KPj4+PiBTdGF0dXM6ICAgICAgIA0K Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aWxvY2EtY29yZS1t dWx0aWNhc3Qtb3Njb2FwLw0KPj4+PiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC8+DQo+Pj4+IEh0bWxpemVkOiAgICAg DQo+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1tdWx0 aWNhc3Qtb3Njb2FwLTAwDQo+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMD4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBBYnN0 cmFjdDoNCj4+Pj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgYXBwbGlj YXRpb24gbGF5ZXIgcHJvdGVjdGlvbiBvZg0KPj4+PiAgIG1lc3NhZ2VzIGV4Y2hhbmdlZCB3aXRo IHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkNCj4+Pj4gICBpbiBh IGdyb3VwIGNvbW11bmljYXRpb24gY29udGV4dC4gIFRoZSBwcm9wb3NlZCBhcHByb2FjaCByZWxp ZXMgb24NCj4+Pj4gICBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUCAoT1NDT0FQKSBhbmQgdGhlIENC T1IgT2JqZWN0IFNpZ25pbmcgYW5kDQo+Pj4+ICAgRW5jcnlwdGlvbiAoQ09TRSkgZm9ybWF0LiAg QWxsIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmdWxmaWxsZWQgYnkNCj4+Pj4gICBPU0NPQVAgYXJl IG1haW50YWluZWQgZm9yIG11bHRpY2FzdCBDb0FQIHJlcXVlc3QgbWVzc2FnZXMgYW5kIHJlbGF0 ZWQNCj4+Pj4gICB1bmljYXN0IENvQVAgcmVzcG9uc2UgbWVzc2FnZXMuICBTb3VyY2UgYXV0aGVu dGljYXRpb24gb2YgYWxsDQo+Pj4+ICAgbWVzc2FnZXMgZXhjaGFuZ2VkIHdpdGhpbiB0aGUgZ3Jv dXAgaXMgZW5zdXJlZCwgYnkgbWVhbnMgb2YgZGlnaXRhbA0KPj4+PiAgIHNpZ25hdHVyZXMgcHJv ZHVjZWQgdGhyb3VnaCBhc3ltbWV0cmljIHByaXZhdGUga2V5cyBvZiBzZW5kZXIgZGV2aWNlcw0K Pj4+PiAgIGFuZCBlbWJlZGRlZCBpbiB0aGUgcHJvdGVjdGVkIENvQVAgbWVzc2FnZXMuDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+PiBzdWJtaXNzaW9uDQo+ Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcNCj4+Pj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+Pj4+IA0KPj4+ PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gQWNl IG1haWxpbmcgbGlzdA0KPj4+PiBBY2VAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+IEFjZUBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gDQo= --Apple-Mail-1FA6460A-72A4-4F04-8A65-6AF92BD791A3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9jCCBfIw ggPaoAMCAQICED5j3SSNCPxYeGdCFol+BckwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjIyMDky NjE0WhcNMTcxMjIyMDkyNjEzWjBrMREwDwYDVQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPR8O2cmFu IFNlbGFuZGVyMSowKAYJKoZIhvcNAQkBFhtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20xEDAO BgNVBAUTB2VyYWdvc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSU5mmTfwCXmA8 +o6zD0QBUzHdSI8Nnh1/IJqdUCNMsXGhyh13VB0fb/dlvGxNuFK7EKzKAmV54EVajL+FRucgxen9 lcC7bp4f1qd3au9kgOXYKzHuw9btR1xuqWG+fvzrZGaSAt2bewZenaZnyZWxoX9o7ia2ZviWktr0 frBlXciopyIlMnIgZ4D4eif47wlcX/ZPATYvm+AkdIH6/PqkY/8Cq3FMILYvrRvO5X1przyuLH+d suuETUeGbbHQrU+C2DKJnE6xVm4K9nXBvpcfkdKVQuqqg7O71Sd1QRDyt6BCXjrSZ4prRy/n26DU 6FMcIn2DkeXdWnm8SpxxoE/zAgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEF BQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYB BQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjAmBgNVHREEHzAdgRtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBSB4nTbn3t1sB2zhLxonZW3Hhv9/zAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBANSVTbxCbSceXCp/tX+UCloB 5q5UI743Q5vKV+h+TB86caGnHBuBtHatVJTD/k+myt8+B+Iu60M2UrX3gBmwSTW6Y8MZhtXYijOM OPvKVyqHkf9ikVMWDBKG+b6O9UB+EomtcfZ7cElXCu/AjXW4Q7CZWVwPrJORLec6mfER9usYEa0O x+meWW5sRDKVHTFgVgsub3+4ouzgOQpsqGrQydYhovIptNPalWGSSTMYpW+r6rukSQ/sUjl54pCA SZj5zs9mQu9fhRtm4I+9HcBNSe1+yq6ECW0Zvc82ynYTFx3w0Art1hmmnd7euM17JzpORrh3y07D ey0wc3RoP4z4ISNffsC+z+jVMl54H1PYYiDuHiPf+cMorlMXFPs7rTFgZS/mY1B2v+qZP9O9k4i/ g4HPQlsJgnWxC5TWluMsOHzQS35FR+oei/35aDwNYvdPixeWNhUmkR4vtfydjpLW+3eKyxcf0Hf/ SVJuzMYrnssBFe+jYNGJYGvdOFjJFffqKCcRocJ0l25ALTVDtv3kpZap6YZXaBAeYTncGWVyv9te bhtILVdqlO7sLtP3zAGZ46bPTW/54F7TOwZ+kfI0vptFgJN5iAA8GwOvhBatrNw9oA9dM2ioAlBb iD3gQ8Fz7Mxq/5AkpSdt3Gzxd7HNwhi5GIkuyPtq1U7B/o19KWC7MYICljCCApICAQEwTjA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQ PmPdJI0I/Fh4Z0IWiX4FyTAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEwMTIxMjMxMzVaMCMGCSqGSIb3DQEJBDEWBBS1axrrNJBIdy8g U4xKW76l7oVtLDBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJMF8GCyqGSIb3 DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIQPmPdJI0I/Fh4Z0IWiX4FyTANBgkqhkiG9w0BAQEFAASCAQB0k4yiMuEp cFTHb+/wPv0jDf0rZsPZxYBj115VP36I8z9qCTYj1qIhqtcXPKxoxz42Z3UtwTzXVsgERIqQHTGS vnpfO8UkHzcGAH98kKDoivCd9JMxMriHhjH0ldtPNATIKZMX5gRs1AYcYzMmjTv+myOR9sLeqNdY HhI5yK3qPNfygRiIEC9hiLDaW0sleMBruPP1zptMz0ovvlfTfuy4LhA7x0bvxs3QK5UVEya8iB+N Td2RYOTcWiraIWfh5v4D6SFck6diNdn5rmWj4MTYY5QOCxkEKtKa+0ROFjB05SKKQwvc66/XErjz mxo96lZ9sNktjOQGxO0UD9+2VRshAAAAAAAA --Apple-Mail-1FA6460A-72A4-4F04-8A65-6AF92BD791A3-- From nobody Wed Oct 12 05:37:43 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262E21294AC for ; Wed, 12 Oct 2016 05:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vsX5aMBcj8Rk for ; Wed, 12 Oct 2016 05:37:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 68E2D1293F4 for ; Wed, 12 Oct 2016 05:37:38 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-ac-57fe2e9095d5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 4B.57.03250.09E2EF75; Wed, 12 Oct 2016 14:37:36 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.183]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 14:37:35 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Kumar SS, Sandeep" Thread-Topic: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt Thread-Index: AQHSJGBb3IlreYskZUK0h4lx2n498qCkXjyAgABRfAD//+O0gIAAB1EAgAAFywA= Date: Wed, 12 Oct 2016 12:37:35 +0000 Message-ID: <576F0CEA-E700-4864-B926-551130819293@ericsson.com> References: <2c0f8002-966e-0e40-cc85-0a6ba3e58916@gmx.net> <060bdcd2-5edb-d324-05d8-38ce63b5afcf@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-411AE7E8-EEC8-42F2-B324-DCBF6C0ED8A4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7ge4EvX/hBoceaFl8/9bDbLF05z1W izlr97JZLDm8iNGBxWPxpv1sHkuW/GTyOHBgN5NH77HfbAEsUVw2Kak5mWWpRfp2CVwZX/4/ YCo4kldxf9I7tgbGQ9ldjJwcEgImEoveHGfqYuTiEBJYzyjRf3UDM0hCSGAJo8SjExogNpuA i8SDhkdMILaIgLHE9VUnWUFsZoECid7X38HiwgLpEmfau9khajIkFr29xwJh+0ksO3qcDcRm EVCVOPB7FpjNK2Av0TxtEzvErrVMElcfVnYxcnBwCoRJdD5TAAkzCohJfD+1hglilbjErSfz mSBuFpF4ePE0G4QtKvHy8T9WkPuZBSYzSvxeupcJYr6gxMmZT1gmMArPQtI/C1ndLCR1EEWa Evu7l0PZihJTuh+yQ9jWEjN+HWSDsE0lXh/9yIisZgEjxypG0eLU4qTcdCMjvdSizOTi4vw8 vbzUkk2MwAg8uOW3wQ7Gl88dDzEKcDAq8fAu0PgbLsSaWFZcmXuIUQVozqMNqy8wSrHk5eel KonwntL6Fy7Em5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD o3Nu/9l5luWsbncOp7zqOtMWOX+FraZRXuPD/Qz7Y6MtT09Pddja0hDK7mefNc1A8d8l3cR3 hR//dBoFHQj5PMOpLdzN3SXrUdePCmP5n5n7Ih4YXEozeShbqvZQ20NrxQcnVyUle+vtLWIe 2XsL6lYyR12c7n3g1Ymn8lJrHnaHNi5n57BVYinOSDTUYi4qTgQAMC/dS8gCAAA= Archived-At: Cc: Hannes Tschofenig , Marco Tiloca , "Ace@ietf.org" Subject: Re: [Ace] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 12:37:42 -0000 --Apple-Mail-411AE7E8-EEC8-42F2-B324-DCBF6C0ED8A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgU2FuZGVlcCwNCg0KV2hpbGUgaXQgaXMgcG9zc2libGUgdG8gbWVyZ2UgdGhlIGRyYWZ0cywg T1NDT0FQIGlzIGFscmVhZHkgYSBsb25nIGRyYWZ0IGFuZCB3ZSBwcmVmZXJyZWQgdG8gc2VwYXJh dGUgdGhlIGdlbmVyYWwgc2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gaW50byBhIHNlcGFyYXRl IHRleHQsIHdoaWNoIG1heSBiZSBhcHBsaWVkIGluIG90aGVyIGNvbnRleHRzIGJlc2lkZSB0aGUg ImxvdyBsYXRlbmN5IiBzZXR0aW5nLiANCg0KR8O2cmFuDQoNCj4gT24gMTIgb2t0LiAyMDE2LCBh dCAxNDoxNywgS3VtYXIgU1MsIFNhbmRlZXAgPHNhbmRlZXAua3VtYXJAcGhpbGlwcy5jb20+IHdy b3RlOg0KPiANCj4gSSBhZ3JlZSB3aXRoIEhhbm5lcy4gVGhlIGNoYW5nZXMgbmVlZCB0byBPU0NP QVAgd2FzIHF1aXRlIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgY2xlYXIgZnJvbSB0aGUgYmVnaW5uaW5n LCB3ZSB3ZXJlIHdhaXRpbmcgZm9yIE9TQ09BUCB0byBiZSBzdGFibGUuIFRoZSBtaW5vciBjaGFu Z2VzIGNvdWxkIGhhdmUgYmVlbiBkaXJlY3RseSB0YWtlbiBpbnRvIE9TQ09BUCB3aXRoIGFuIG9w dGlvbmFsIFNlbmRlcklEIGZpZWxkLiBJZiB0aGF0IGlzIG5vdCBwb3NzaWJsZSwgdGhlbiBpdCBj YW4gYmUgZG9uZSBkaXJlY3RseSBpbiB0aGUgQUNFIGRyYWZ0LiBJIGRvIG5vdCBzZWUgYW55IHZh bHVlIGluIGFuIGFkZGl0aW9uYWwgZHJhZnQgdG8gc29sdmUgdGhpcyBtaW5vciBzdWItaXNzdWUu DQo+IA0KPiBTYW5kZWVwDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVz IFRzY2hvZmVuaWcNCj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMiwgMjAxNiAxOjUxIFBN DQo+PiBUbzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+OyBN YXJjbyBUaWxvY2ENCj4+IDxtYXJjb0BzaWNzLnNlPjsgQWNlQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW0FjZV0gW2NvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC10aWxvY2EtY29yZS0NCj4+IG11bHRpY2FzdC1vc2NvYXAtMDAudHh0DQo+PiANCj4+IEhpIEdv ZXJhbiwNCj4+IA0KPj4gdGhlcmUgd2FzIG5ldmVyIGFueSBkb3VidCB0aGF0IHdlIGNhbiB1c2Ug Q09TRSB0byBkZXNpZ24gYSBzZWN1cml0eQ0KPj4gc29sdXRpb24gdXNpbmcgdGhlIGFscmVhZHkg ZXhpc3RpbmcgYnVpbGRpbmcgYmxvY2tzLg0KPj4gDQo+PiBCdHcsIGluIHRoZSBtZWFud2hpbGUg d2UgaGF2ZSBhY3R1YWxseSBjb25jbHVkZWQgdGhlIGRpc2N1c3Npb24gaW4gQUNFIG9uDQo+PiB0 aGUgZ3JvdXAgY29tbXVuaWNhdGlvbiBzZWN1cml0eSB0b3BpYywgc2VlIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtDQo+PiBhcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTk2Ny5odG1sDQo+ PiANCj4+IENpYW8NCj4+IEhhbm5lcw0KPj4gDQo+PiBQUzogWW91IGNhbm5vdCBkZWNvdXBsZSB0 aGUgcXVlc3Rpb24gb2YgYWRvcHRpb24gb2YNCj4+IGRyYWZ0LXNvbWFyYWp1LWFjZS1tdWx0aWNh c3QtMDEgZnJvbSB0aGUgcXVlc3Rpb24gb2Ygc291cmNlIGF1dGhlbnRpY2F0aW9uDQo+PiBzaW5j ZSB0aGlzIHdhcyB0aGUgY29yZSBpc3N1ZSBvZiB0aGUgZGViYXRlLg0KPj4gDQo+Pj4gT24gMTAv MTIvMjAxNiAwMTozMSBQTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4+IA0KPj4+IEhpIEhh bm5lcywNCj4+PiANCj4+PiBJ4oCZbSBhIGJpdCBzdXJwcmlzZWQgYXQgeW91ciByZWFjdGlvbi4g SWYgeW91IGhhdmUgZm9sbG93ZWQgdGhlDQo+Pj4gZGlzY3Vzc2lvbiBvbiBPU0NPQVAgeW91IGtu b3cgdGhhdCBvbmUgcmVjdXJyaW5nIHJlcXVlc3QgaGFzIGJlZW4gb24NCj4+PiBzdXBwb3J0IGZv ciBtdWx0aWNhc3QuIFRoaXMgZHJhZnQgaXMgYWRkcmVzc2luZyB0aGF0IHJlcXVlc3QuDQo+Pj4g DQo+Pj4gZHJhZnQtc29tYXJhanUtYWNlLW11bHRpY2FzdC0wMSBpcyByZWZlcnJpbmcgdG8gT1ND T0FQIGZvciBzZWN1cmUNCj4+PiBncm91cCBjb21tdW5pY2F0aW9uIGFuZCB3ZSBwcm9wb3NlIHRo aXMgZHJhZnQgdG8gYmUgdGhlIHdheSB0byBleHRlbmQNCj4+PiBPU0NPQVAgZm9yIHRoYXQgcHVy cG9zZS4NCj4+PiANCj4+PiBJbiB0aGUgImNvbnRyb3ZlcnNpYWwsIGxvbmcsIGFuZCB0b3VnaOKA nSBkaXNjdXNzaW9uIHlvdSByZWZlciB0bywgb25lDQo+Pj4gY2VudHJhbCBpc3N1ZSByZWxhdGVz IHRvIHRoZSB1c2Ugb2Ygc3ltbWV0cmljIGtleXMgb25seSBpbiBncm91cA0KPj4+IGNvbW11bmlj YXRpb24uIE91ciBkcmFmdCBtYW5kYXRlcyB0aGUgdXNlIG9mIGFzeW1tZXRyaWMga2V5cyBzaW5j ZQ0KPj4+IHRoYXQgcHJvdmlkZXMgc291cmNlIGF1dGhlbnRpY2F0aW9uLiBTaG91bGQgaXQgYmUg YWdyZWVkIHRoYXQgc291cmNlDQo+Pj4gYXV0aGVudGljYXRpb24gZm9yIHNvbWUgcHVycG9zZSBp cyBub3QgbmVjZXNzYXJ5LCBpdCBpcyBhIHNpbXBsZQ0KPj4+IG1vZGlmaWNhdGlvbiBvZiB0aGlz IGRyYWZ0IC0gc2ltcGx5IG1ha2luZyB0aGUgY291bnRlciBzaWduYXR1cmUgaW4NCj4+PiB0aGUg Q09TRSBvYmplY3Qgbm9uLW1hbmRhdG9yeS4NCj4+PiANCj4+PiBJdCB3YXMgb3VyIGhvcGUgdGhh dCB3ZSBpbiB0aGlzIHdheSBjYW4gZGVjb3VwbGUgdGhlIHF1ZXN0aW9uIG9mDQo+Pj4gYWRvcHRp b24gb2YgZHJhZnQtc29tYXJhanUtYWNlLW11bHRpY2FzdC0wMSBmcm9tIHRoZSBxdWVzdGlvbiBv Zg0KPj4+IHNvdXJjZSBhdXRoZW50aWNhdGlvbi4NCj4+PiANCj4+PiBHw7ZyYW4NCj4+PiANCj4+ PiANCj4+PiANCj4+PiANCj4+PiBPbiAyMDE2LTEwLTEyIDEwOjQwLCAiQWNlIG9uIGJlaGFsZiBv ZiBIYW5uZXMgVHNjaG9mZW5pZyINCj4+PiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPj4+IA0KPj4+PiBIaSBNYXJj bywgSGkgRnJhbmNlc2NhLCBIaSBHb2VyYW4sDQo+Pj4+IA0KPj4+PiBJIGFtIGEgYml0IHN1cnBy aXNlZCBhYm91dCB5b3VyIGRvY3VtZW50IHN1Ym1pc3Npb24gc2luY2UgeW91IGd1eXMNCj4+Pj4g aGF2ZSBiZWVuIHByZXR0eSBzaWxlbnQgaW4gdGhlIGdyb3VwIGNvbW11bmljYXRpb24gc2VjdXJp dHkNCj4+Pj4gZGlzY3Vzc2lvbiwgd2hpY2ggd2FzIHF1aXRlIGNvbnRyb3ZlcnNpYWwsIGxvbmcs IGFuZCB0b3VnaC4gVGhhdCdzDQo+Pj4+IHdoZXJlIHlvdXIgc3VwcG9ydCB3b3VsZCBoYXZlIGJl ZW4gbmVlZGVkLiBBZGRpbmcgdGhlIGZldyBzbWFsbCBiaXRzDQo+Pj4+IHRvIHRoZSBhbHJlYWR5 IHdyaXR0ZW4gZHJhZnQgaXNuJ3QgdGhlIHByb2JsZW0uDQo+Pj4+IA0KPj4+PiBDaWFvDQo+Pj4+ IEhhbm5lcw0KPj4+PiANCj4+Pj4+IE9uIDEwLzEyLzIwMTYgMTA6MTIgQU0sIE1hcmNvIFRpbG9j YSB3cm90ZToNCj4+Pj4+IERlYXIgQ29SRS9BQ0UsDQo+Pj4+PiANCj4+Pj4+IFdlIGhhdmUgc3Vi bWl0dGVkIGEgZHJhZnQgb24gc2VjdXJlIGdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVANCj4+ Pj4+IGFkZHJlc3Npbmcgc2VjdXJpdHkgZm9yIHRoZSBzZXR0aW5nIG9mIGEgbXVsdGljYXN0IENv QVAgcmVxdWVzdCB3aXRoDQo+Pj4+PiB1bmljYXN0IHJlc3BvbnNlcyBhcyBkZXNjcmliZWQgaW4g UkZDNzM5MC4NCj4+Pj4+IA0KPj4+Pj4gVGhpcyBkcmFmdCBidWlsZHMgb24gdGhlIHJlY2VudGx5 IHVwZGF0ZWQgdmVyc2lvbiBvZiBPU0NPQVAsDQo+Pj4+PiBleHRlbmRlZCB3aXRoIG1hbmRhdG9y eSBTZW5kZXIgSUQgYW5kIG11bHRpcGxlIFJlY2lwaWVudCBDb250ZXh0cy4NCj4+Pj4+IEl0IGFs c28gZW5hYmxlcyBzb3VyY2UgYXV0aGVudGljYXRpb24gd2l0aCBhc3ltbWV0cmljIHNpZ25hdHVy ZXMNCj4+Pj4+IGltcGxlbWVudGVkIGFzIGNvdW50ZXIgc2lnbmF0dXJlcyBpbmNsdWRlZCB3aXRo IHRoZSBDT1NFIG9iamVjdHMNCj4+IGRlZmluZWQgYnkgT1NDT0FQLg0KPj4+Pj4gDQo+Pj4+PiBX ZSBob3BlIHRoYXQgYnkgc3VibWl0dGluZyBub3cgd2UgY291bGQgZ2V0IHNvbWUgZmlyc3QgZGlz Y3Vzc2lvbiB0bw0KPj4+Pj4gYWxsb3cgdXBkYXRlcyBiZWZvcmUgdGhlIGN1dG9mZi4NCj4+Pj4+ IA0KPj4+Pj4gVGhpcyBkcmFmdCBwcm92aWRlcyB0aGUgbWlzc2luZyBsaW5rIGJldHdlZW4NCj4+ Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zb21hcmFqdS1hY2UtbXVsdGlj YXN0IGFuZCBPU0NPQVAuDQo+Pj4+PiANCj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+IE1hcmNv DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0t LS0tLS0tDQo+Pj4+PiBGcm9tOiAqKiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+PiA8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQo+Pj4+PiBEYXRlOiBXZWQsIE9jdCAx MiwgMjAxNiBhdCA5OjI3IEFNDQo+Pj4+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+Pj4+PiBkcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAwLnR4dA0K Pj4+Pj4gVG86IE1hcmNvIFRpbG9jYSA8bWFyY29Ac2ljcy5zZSA8bWFpbHRvOm1hcmNvQHNpY3Mu c2U+PiwgR29lcmFuDQo+Pj4+PiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t DQo+Pj4+PiA8bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4+LA0KPj4+Pj4gRnJh bmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20NCj4+Pj4+ IDxtYWlsdG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+Pg0KPj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRpbG9jYS1jb3Jl LW11bHRpY2FzdC1vc2NvYXAtMDAudHh0DQo+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEZyYW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0bw0KPj4+Pj4gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4+Pj4+IA0KPj4+Pj4gTmFtZTogICAgICAgICAgIGRyYWZ0LXRpbG9j YS1jb3JlLW11bHRpY2FzdC1vc2NvYXANCj4+Pj4+IFJldmlzaW9uOiAgICAgICAwMA0KPj4+Pj4g VGl0bGU6ICAgICAgICAgIFNlY3VyZSBncm91cCBjb21tdW5pY2F0aW9uIGZvciBDb0FQDQo+Pj4+ PiBEb2N1bWVudCBkYXRlOiAgMjAxNi0xMC0xMg0KPj4+Pj4gR3JvdXA6ICAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPj4+Pj4gUGFnZXM6ICAgICAgICAgIDE1DQo+Pj4+PiBVUkw6DQo+ Pj4+PiANCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10 aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3NjDQo+Pj4+PiBvYXAtMA0KPj4+Pj4gMC50eHQNCj4+Pj4+ IA0KPj4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aWxv Y2EtY29yZS1tdWx0aWNhc3Qtb3MNCj4+Pj4+IGNvYXAtDQo+Pj4+PiAwMC50eHQ+DQo+Pj4+PiBT dGF0dXM6DQo+Pj4+PiANCj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAvDQo+Pj4+PiA8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC8+DQo+ Pj4+PiBIdG1saXplZDoNCj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwLTAwDQo+Pj4+PiA8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2FzdC1vc2NvYXAtMDA+DQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGEgbWV0aG9kIGZvciBhcHBsaWNhdGlvbiBsYXllciBwcm90ZWN0aW9uIG9mDQo+Pj4+PiAgIG1l c3NhZ2VzIGV4Y2hhbmdlZCB3aXRoIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2Nv bCAoQ29BUCkNCj4+Pj4+ICAgaW4gYSBncm91cCBjb21tdW5pY2F0aW9uIGNvbnRleHQuICBUaGUg cHJvcG9zZWQgYXBwcm9hY2ggcmVsaWVzIG9uDQo+Pj4+PiAgIE9iamVjdCBTZWN1cml0eSBvZiBD b0FQIChPU0NPQVApIGFuZCB0aGUgQ0JPUiBPYmplY3QgU2lnbmluZyBhbmQNCj4+Pj4+ICAgRW5j cnlwdGlvbiAoQ09TRSkgZm9ybWF0LiAgQWxsIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmdWxmaWxs ZWQgYnkNCj4+Pj4+ICAgT1NDT0FQIGFyZSBtYWludGFpbmVkIGZvciBtdWx0aWNhc3QgQ29BUCBy ZXF1ZXN0IG1lc3NhZ2VzIGFuZA0KPj4gcmVsYXRlZA0KPj4+Pj4gICB1bmljYXN0IENvQVAgcmVz cG9uc2UgbWVzc2FnZXMuICBTb3VyY2UgYXV0aGVudGljYXRpb24gb2YgYWxsDQo+Pj4+PiAgIG1l c3NhZ2VzIGV4Y2hhbmdlZCB3aXRoaW4gdGhlIGdyb3VwIGlzIGVuc3VyZWQsIGJ5IG1lYW5zIG9m IGRpZ2l0YWwNCj4+Pj4+ICAgc2lnbmF0dXJlcyBwcm9kdWNlZCB0aHJvdWdoIGFzeW1tZXRyaWMg cHJpdmF0ZSBrZXlzIG9mIHNlbmRlcg0KPj4gZGV2aWNlcw0KPj4+Pj4gICBhbmQgZW1iZWRkZWQg aW4gdGhlIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2VzLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gDQo+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4+PiB0b29scy5pZXRmLm9y ZyA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4+Pj4+IA0KPj4+Pj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IEFjZSBtYWlsaW5nIGxp c3QNCj4+Pj4+IEFjZUBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+PiBBY2VAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJv dGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywg ZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --Apple-Mail-411AE7E8-EEC8-42F2-B324-DCBF6C0ED8A4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9jCCBfIw ggPaoAMCAQICED5j3SSNCPxYeGdCFol+BckwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjIyMDky NjE0WhcNMTcxMjIyMDkyNjEzWjBrMREwDwYDVQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPR8O2cmFu IFNlbGFuZGVyMSowKAYJKoZIhvcNAQkBFhtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20xEDAO BgNVBAUTB2VyYWdvc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSU5mmTfwCXmA8 +o6zD0QBUzHdSI8Nnh1/IJqdUCNMsXGhyh13VB0fb/dlvGxNuFK7EKzKAmV54EVajL+FRucgxen9 lcC7bp4f1qd3au9kgOXYKzHuw9btR1xuqWG+fvzrZGaSAt2bewZenaZnyZWxoX9o7ia2ZviWktr0 frBlXciopyIlMnIgZ4D4eif47wlcX/ZPATYvm+AkdIH6/PqkY/8Cq3FMILYvrRvO5X1przyuLH+d suuETUeGbbHQrU+C2DKJnE6xVm4K9nXBvpcfkdKVQuqqg7O71Sd1QRDyt6BCXjrSZ4prRy/n26DU 6FMcIn2DkeXdWnm8SpxxoE/zAgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEF BQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYB BQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjAmBgNVHREEHzAdgRtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBSB4nTbn3t1sB2zhLxonZW3Hhv9/zAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBANSVTbxCbSceXCp/tX+UCloB 5q5UI743Q5vKV+h+TB86caGnHBuBtHatVJTD/k+myt8+B+Iu60M2UrX3gBmwSTW6Y8MZhtXYijOM OPvKVyqHkf9ikVMWDBKG+b6O9UB+EomtcfZ7cElXCu/AjXW4Q7CZWVwPrJORLec6mfER9usYEa0O x+meWW5sRDKVHTFgVgsub3+4ouzgOQpsqGrQydYhovIptNPalWGSSTMYpW+r6rukSQ/sUjl54pCA SZj5zs9mQu9fhRtm4I+9HcBNSe1+yq6ECW0Zvc82ynYTFx3w0Art1hmmnd7euM17JzpORrh3y07D ey0wc3RoP4z4ISNffsC+z+jVMl54H1PYYiDuHiPf+cMorlMXFPs7rTFgZS/mY1B2v+qZP9O9k4i/ g4HPQlsJgnWxC5TWluMsOHzQS35FR+oei/35aDwNYvdPixeWNhUmkR4vtfydjpLW+3eKyxcf0Hf/ SVJuzMYrnssBFe+jYNGJYGvdOFjJFffqKCcRocJ0l25ALTVDtv3kpZap6YZXaBAeYTncGWVyv9te bhtILVdqlO7sLtP3zAGZ46bPTW/54F7TOwZ+kfI0vptFgJN5iAA8GwOvhBatrNw9oA9dM2ioAlBb iD3gQ8Fz7Mxq/5AkpSdt3Gzxd7HNwhi5GIkuyPtq1U7B/o19KWC7MYICljCCApICAQEwTjA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQ PmPdJI0I/Fh4Z0IWiX4FyTAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEwMTIxMjM3MzVaMCMGCSqGSIb3DQEJBDEWBBSmnSFjbWfDkFM3 DSF3+6bYgHc75DBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJMF8GCyqGSIb3 DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIQPmPdJI0I/Fh4Z0IWiX4FyTANBgkqhkiG9w0BAQEFAASCAQByoW/1Y5AZ tD6cvBj+Mg++GFntbSdKVlDZVNq2zwvmGOQ1vVFcNfb+z+FUpe+vuKFODiEJqiw2POctUBDADgUq xS0Gn/Ev8yHqEiFcEMvYfAXRZtjm5lGLgPBA5fmwSWX9RdIcIAKIFA/hQRBhpriA5RWsvASZe9wj Y1AyOdJbmUiRjDoInr+vxKw/KS8qRwqrRvsnvVEei9styofcfq6Xkmnhs2RSmVw5n6U07yxhwIt6 7e5oXnrvOdHPumUiDJJeWBrlxw39Rope+2ELGG4bxg5bUhooNOgCShXM33+P0CNH9J3FLts86Rxi OJcRs5nZHIxU4bz9QOzYV1WSVKiIAAAAAAAA --Apple-Mail-411AE7E8-EEC8-42F2-B324-DCBF6C0ED8A4-- From nobody Wed Oct 12 05:41:37 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E71293F4 for ; Wed, 12 Oct 2016 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lKT_hvhYEOsD for ; Wed, 12 Oct 2016 05:41:33 -0700 (PDT) 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 9753E1293F3 for ; Wed, 12 Oct 2016 05:41:32 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LvENG-1auKKD1lTe-010Lt8; Wed, 12 Oct 2016 14:41:27 +0200 To: "Calvo Alonso, Daniel" , "ace@ietf.org" References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <613d3596-c721-7285-82ea-03176898e22a@gmx.net> Date: Wed, 12 Oct 2016 14:41:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5juMo1iO9oMk5r6EVmxeovPvNNDL72bNr" X-Provags-ID: V03:K0:jh5eXKUJU7EgBSRk+EcdGMFyrY2/7JG9X9SW1aNRHaOleTYJkFG EMzBNqru0NuQe8OZnnx3pdssyMkFCXFjYjZV/MyWBgFrqZgW3ejDA4BLKek30xuQKTIluNd QRisEgJ/EjqPZIXSZBNmcyCZavfO7tH2BOQwN8xlGa7FUTnUo12oNskKosMkIZzeMdjtm+V WWXgAKIA6WeiGTB7YFjiw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZIMqQUlbEDg=:2QYy0I4zZynJlf2ED/m3zU N7nhOz+hCn/E9ROnUpQE0fbo6yazPKKDKGxRlD9vAJINAHrHngXbDSSToq0xqOrJAWVBTETbN dW3Pp/glmHbV6ZcUZ0e64w44uBufuYDpmQVDsp2ChGHvZN2xLDx1s9tue7zuTWtOLO+B+nqEa b/GjgVFieRacDaY/STHHY9dXvAjhpGP0nWtzzPfaz7IYzLJ9YSm8CZo2EzXWH1iEgGJ6Lyoe7 IYjB+kyUOveWYBXCwTw5V9ZkbUIKSuyfM5kcRepRUJp368BCvdgiW8crOiSHzAPk1+3ZPEVh7 6/GJfHNFkzAUCoClywZt9R0xpGke6BQx1dlAYiUaZR4Mfeu6ioDJawhaKbGcSyx9ASN7dtTtD 5jBXX4JXn55R1FFjUaylI08FcxHecyAZrVFKPeWqhY6BDZENQq//J3IhT4DgTFfipRrBj/uMd sJ7S/Lb2ysh4bDP3VCfhTeKSk+xPSTIhI1JkfJ+RGrQbKZh5HuYRL7h3Aqw3rr3LAdtObz2uK nyvI0zaLrGvW52cS2MQ9wtPqCLgKExbseXH277I3LEgSGHYRfnGHzf39/2UWJXSs7Eo8EIbUH mzopP0nhco+Szi0zLvsU4jsBLO6ueEMrokQ6zSL2cTZJhU3i1RhXGgtI4o6bIDABHKWS2tMnq teX7Wu3YgY7L6fpAEgQuOmG7Fp+Q8I3Bl4xQJnTN7mpM20PYfxvfbhZOwEhpRy54oZFoxL+el xIS6dRrifdAraqThh0Rmc92di3Q235at7WkLCCEBg5AiIPYwiddifDrd/e4= Archived-At: Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 12:41:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5juMo1iO9oMk5r6EVmxeovPvNNDL72bNr Content-Type: multipart/mixed; boundary="7D27ScluM93TsCAPAUr3gABaPBc7FBRGd"; protected-headers="v1" From: Hannes Tschofenig To: "Calvo Alonso, Daniel" , "ace@ietf.org" Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Message-ID: <613d3596-c721-7285-82ea-03176898e22a@gmx.net> Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> In-Reply-To: <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> --7D27ScluM93TsCAPAUr3gABaPBc7FBRGd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, thanks for the description. How close is the implementation to the ACE-OAuth framework? I am asking this question since you could have re-used lots of existing code since there are many open source implementations of OAuth authorization servers around (even in Java). The use of Java for the client only makes sense if you are planning to run it on an Android phone/tablet (which is one of the use cases, of course). If the client (or the resource server) are running on an IoT device then Java is not that common (at least not on the low end devices, which the ACE group is mostly focused on). Most IoT devices are using C (or C++ at best). Maybe there is a chance that your European funded research project contributes code to a C-implementation of COSE, where preliminary work has been done already by a student in Sweden, see https://github.com/Gunzter/COSE-C Adding proof-of-possession support to OAuth authorization servers would also be appreciated. I think that these student projects from Trier University give some insight into how existing components can be re-used. In this case the scenario was to write an Android app to interact with an authorization server to obtain an access token that can be used to gain access to a smart door lock. Code from one group: https://github.com/StudienprojektUniTrier Code from the second group: http://tschofenig.priv.at/Trier-Gruppe3.zip Ciao Hannes PS: Is there a plan to take the privacy aspects from draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 and to align them with the ACE framework? On 09/28/2016 12:42 PM, Calvo Alonso, Daniel wrote: > Hi Hannes, >=20 > Sorry for the delayed answer but I have been travelling for a couple of= days. >=20 > This code is a first JAVA prototype that implements the actors, message= s and flows that are defined in draft-cuellar-ace-pat-priv-enhanced-auth= z-tokens-03. >=20 > I will try to give you an overview: > - You can find several examples that demonstrate the features of the dr= aft/prototype in src/test/java/com/atos/ari/rerum/ace. For instance in Co= mpleteTestSuccess.java: > - We have a ResourceServer (lines 74-86) that hosts a resource = which will be used for the tests (this functionality would be implemented= in a constrained device) > - We have an AuthorizationServer (lines 89-106) that will perfo= rm the authorization process on behalf of the ResourceServer and which us= es a set of policies defined a JSON file. This is out of the scope of the= draft, but we have followed this approach to achieve a complete test. > - A client wants to get access to the resource but as it does n= ot have an valid access token, the resource server will return an Unautho= rized response with the information about the AuthorizationServer that mu= st be contacted (lines 127-135). > - The client uses this information to ask the AuthorizationServ= er an AccessToken that covers its request over the ResourceServer. In thi= s case, a GET operation. (lines 138- 141) > - The client uses part of the ClientToken to perform an authori= zed resource request to the resource server (lines 143 - 152) > - The client uses part of the ClientToken to unencrypt the answ= er received from the ResourceServer (lines 155 -167 ) > - In the rest of the code, a similar process if followed to per= form a POST operation. > - The implementation of the actors can be found under src/main/java/com= /atos/ari/rerum/ace folder: AuthorizationServer, Client, ResourceAce and = ResourceServer. All these classes are used in the examples like the one I= mentioned before. > - In src/main/java/com/atos/ari/rerum/ace/messages, you can find the cl= asses that implement the different messages that are exchanged as part of= the protocol flow, e.g., the sam information message (SamInformationMess= age), the access token request message (AccessRequestMessage), the client= token (TicketTransferMessage, TicketTransferMessageFace) and the access = token (AccessToken). The access token is embedded in the payload as descr= ibed in the draft. We use AcePayload class for this part. As you can see,= the contents of the payload are encrypted to protect data confidentialit= y. > In src/main/java/com/atos/ari/rerum/ace/crypto, you can find the classe= s that implement the different algorithms that are initially proposed in = the draft. For instance: > - AEAD_CHACHA20_POLY130 for authenticat4ed encryption of payloa= ds. > - Poly1305 to generate the verifier (part of the ClientToken t= hat is sent from the AuthorizationServer to the Client and used to encryp= t payload) >=20 > The next step would be to implement the Client actor and its functional= ity in a real constrained device. As I explained you in Berlin, this is i= n our roadmap but we are going also to follow your comments and try to al= ign first this draft with draft-ietf-ace-oauth-authz-02. >=20 > @Jorge, @Prabha, please correct me if anything is not totally correct a= nd feel free to add what you consider of interest. >=20 > I hope that this explanation is useful to understand better the code bu= t if you have more doubts, please don't hesitate in ask me again! >=20 > BR, >=20 > Daniel >=20 >=20 > Daniel Calvo > Energy and Transport Market > Atos Research and Innovation > Tel: +34 946 66 20 82 > daniel.calvo@atos.net > C/Real Consulado s/n, > Pol=EDgono Industrial Candina > 39011 Santander > www.atosresearch.eu >=20 >=20 >=20 > Feel free to download our booklet at > https://atos.net/en/insights-and-innovation/innovation-labs >=20 > This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-= mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liab= ility cannot be triggered for the message content. Although the sender en= deavors to maintain a computer virus-free network, the sender does not wa= rrant that this transmission is virus-free and will not be liable for any= damages resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n conf= idencial destinada solamente a la(s) persona(s) mencionadas anteriormente= y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por inform= ar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos = no se hace responsable por su contenido. Su contenido no constituye ning=FA= n compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas p= artes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el e= misor no puede garantizar nada al respecto y no ser=E1 responsable de cua= lesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. > This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-= mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liab= ility cannot be triggered for the message content. Although the sender en= deavors to maintain a computer virus-free network, the sender does not wa= rrant that this transmission is virus-free and will not be liable for any= damages resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n conf= idencial destinada solamente a la(s) persona(s) mencionadas anteriormente= y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por inform= ar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos = no se hace responsable por su contenido. Su contenido no constituye ning=FA= n compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas p= artes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el e= misor no puede garantizar nada al respecto y no ser=E1 responsable de cua= lesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, September 26, 2016 10:24 AM > To: Calvo Alonso, Daniel; ace@ietf.org > Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose > Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-= authz-tokens source code >=20 > Hi Daniel, >=20 > could you provide a bit of info what you have implemented? > (I know that I can look at the code myself but you probably know all th= e details from the top of your head.) >=20 > Ciao > Hannes >=20 >=20 > On 08/31/2016 10:11 AM, Calvo Alonso, Daniel wrote: >> Dear all, >> >> As I promised during my presentation in the ACE WG meeting in Berlin, >> this is the correct link to >> draft-cuellar-ace-pat-priv-enhanced-authz-tokens prototype source code= : >> >> _https://gitlab.atosresearch.eu/ari/ACE-PAT-pub_ >> >> Please, don't hesitate in contact me in case you have any doubt or pro= blem. >> >> With my best regards, >> >> *Daniel Calvo* >> Energy and Transport Market >> Atos Research and Innovation >> Tel: +34 946 66 20 82 >> _daniel.calvo@atos.net_ C/Real >> Consulado s/n, Pol=EDgono Industrial Candina >> 39011 Santander >> _www.atosresearch.eu_ >> >> >> *Feel free to download our booklet at* >> _http://atos.net/en-us/home/we-are/insights-innovation/research-and-in= >> novation.html_ >> >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy= it. >> As its integrity cannot be secured on the Internet, the Atos group >> liability cannot be triggered for the message content. Although the >> sender endeavors to maintain a computer virus-free network, the sender= >> does not warrant that this transmission is virus-free and will not be >> liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n >> confidencial destinada solamente a la(s) persona(s) mencionadas >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red, Atos= >> no se hace responsable por su contenido. Su contenido no constituye >> ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita p= or >> ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de= >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus= =2E >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy= it. >> As its integrity cannot be secured on the Internet, the Atos group >> liability cannot be triggered for the message content. Although the >> sender endeavors to maintain a computer virus-free network, the sender= >> does not warrant that this transmission is virus-free and will not be >> liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n >> confidencial destinada solamente a la(s) persona(s) mencionadas >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red, Atos= >> no se hace responsable por su contenido. Su contenido no constituye >> ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita p= or >> ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de= >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus= =2E >> >> >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy= it. >> As its integrity cannot be secured on the Internet, the Atos group >> liability cannot be triggered for the message content. Although the >> sender endeavors to maintain a computer virus-free network, the sender= >> does not warrant that this transmission is virus-free and will not be >> liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n >> confidencial destinada solamente a la(s) persona(s) mencionadas >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red, Atos= >> no se hace responsable por su contenido. Su contenido no constituye >> ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita p= or >> ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de= >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus= =2E >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-= mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liab= ility cannot be triggered for the message content. Although the sender en= deavors to maintain a computer virus-free network, the sender does not wa= rrant that this transmission is virus-free and will not be liable for any= damages resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n conf= idencial destinada solamente a la(s) persona(s) mencionadas anteriormente= y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por inform= ar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos = no se hace responsable por su contenido. Su contenido no constituye ning=FA= n compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas p= artes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el e= misor no puede garantizar nada al respecto y no ser=E1 responsable de cua= lesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --7D27ScluM93TsCAPAUr3gABaPBc7FBRGd-- --5juMo1iO9oMk5r6EVmxeovPvNNDL72bNr 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/i91AAoJEGhJURNOOiAtbS8IAJmFQrKh7HvxwXxvlBvRuHwR 5IRJJtAxuU73IwsnzKYanAqXaMDmxUgnV0vTFbhKyALUE575xlRmFV0JlVmg3G3P kLFLBG46dyKyDwwSMTdEeU7fBoQ0LX/Y7zKSC2RlpYIzqdVAilOHsALItDziHdkO o7d1dnU+gjlOM2JXF2r976NOePyB9Oj1EcqEM2VdNmeT3fiwem266IXaBf77dHFb Y0w2vlt6QLZ1ROCwLT96HRGhbANsfBFKFTNp4IgxD0IBcsGoZKsGlBrKgtbCVcg6 Y/I7ygYI+UFSnZfvbdUfWMWnqo+GEYm4Gg2KRxRNRaB/SrOkRZeMYMyvOM7vdTY= =vufK -----END PGP SIGNATURE----- --5juMo1iO9oMk5r6EVmxeovPvNNDL72bNr-- From nobody Thu Oct 13 02:38:59 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB012970F for ; Thu, 13 Oct 2016 02:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 abFqZxUXhaiK for ; Thu, 13 Oct 2016 02:38:54 -0700 (PDT) Received: from smtppost.atos.net (smtppost.atos.net [193.56.114.165]) (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 E99B2127076 for ; Thu, 13 Oct 2016 02:38:53 -0700 (PDT) Received: from mail1-ext.my-it-solutions.net (mail1-ext.my-it-solutions.net) by smarthost6.atos.net with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 3cd6_2692_9342de36_3b6d_48ce_8d1b_64dc73496319; Thu, 13 Oct 2016 11:38:43 +0200 Received: from mail1-int.my-it-solutions.net ([10.92.32.11]) by mail1-ext.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u9D9cfvv009412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 11:38:41 +0200 Received: from DEERLM99ETQMSX.ww931.my-it-solutions.net ([10.86.142.102]) by mail1-int.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u9D9cfEt001310 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 11:38:41 +0200 Received: from DEERLM99EX1MSX.ww931.my-it-solutions.net ([169.254.1.118]) by DEERLM99ETQMSX.ww931.my-it-solutions.net ([10.86.142.102]) with mapi id 14.03.0294.000; Thu, 13 Oct 2016 11:38:41 +0200 From: "Calvo Alonso, Daniel" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code Thread-Index: AdIDXo/JIWofyYeVRFyCDhU6AnzNSQUYAG8AAGyJrgACwR1PAAAvvhJQ Date: Thu, 13 Oct 2016 09:38:40 +0000 Message-ID: <8A926B4ADC92E345A40FA5363D47FA3003381292@DEERLM99EX1MSX.ww931.my-it-solutions.net> References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> <613d3596-c721-7285-82ea-03176898e22a@gmx.net> In-Reply-To: <613d3596-c721-7285-82ea-03176898e22a@gmx.net> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.142.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 09:38:58 -0000 Hi Hannes, Probably Jorge or Prabha could give you a more accurate answer regarding ho= w close is draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 (and the imp= lementation) to the ACE-Oauth framework since I am more focused on the impl= ementation itself. We are already aware that most of devices targeted by ACE group are not abl= e to run Java apps but our intention with this first prototype was just to = start validating the draft concepts from a high-level perspective. A transl= ation of the client and resource server functionalities to C/C++ is also in= our roadmap for the incoming months so that we could demonstrate the draft= benefits with real use-cases and devices. We will keep you informed about = our advanced in this line. We will review these codes and projects to try to find potential overlappin= gs with our work, thanks!! :) For your last question, I think that again Jorge or Prabha will give you a = more detailed answer, but I guess that they are already working on this. Thanks and BR, Daniel Daniel Calvo Energy and Transport Market Atos Research and Innovation Tel: +34 946 66 20 82 daniel.calvo@atos.net C/Real Consulado s/n, Pol=EDgono Industrial Candina 39011 Santander www.atosresearch.eu Feel free to download our booklet at https://atos.net/en/insights-and-innovation/innovation-labs This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it.=20 As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted.=20 Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional.=20 Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.=20 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.= =20 Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.=20 This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it.=20 As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted.=20 Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente=A0y p= ueden estar protegidos por secreto profesional.=20 Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.=20 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.= =20 Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.=20 -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Wednesday, October 12, 2016 2:41 PM To: Calvo Alonso, Daniel; ace@ietf.org Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-auth= z-tokens source code Hi Daniel, thanks for the description. How close is the implementation to the ACE-OAuth framework? I am asking this question since you could have re-used lots of existing cod= e since there are many open source implementations of OAuth authorization s= ervers around (even in Java). The use of Java for the client only makes sense if you are planning to run = it on an Android phone/tablet (which is one of the use cases, of course). I= f the client (or the resource server) are running on an IoT device then Jav= a is not that common (at least not on the low end devices, which the ACE gr= oup is mostly focused on). Most IoT devices are using C (or C++ at best). Maybe there is a chance that your European funded research project contribu= tes code to a C-implementation of COSE, where preliminary work has been don= e already by a student in Sweden, see https://github.com/Gunzter/COSE-C Adding proof-of-possession support to OAuth authorization servers would als= o be appreciated. I think that these student projects from Trier University give some insight= into how existing components can be re-used. In this case the scenario was= to write an Android app to interact with an authorization server to obtain= an access token that can be used to gain access to a smart door lock. Code from one group: https://github.com/StudienprojektUniTrier Code from the second group: http://tschofenig.priv.at/Trier-Gruppe3.zip Ciao Hannes PS: Is there a plan to take the privacy aspects from draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 and to align them with = the ACE framework? On 09/28/2016 12:42 PM, Calvo Alonso, Daniel wrote: > Hi Hannes, >=20 > Sorry for the delayed answer but I have been travelling for a couple of d= ays. >=20 > This code is a first JAVA prototype that implements the actors, messages = and flows that are defined in draft-cuellar-ace-pat-priv-enhanced-authz-to= kens-03. >=20 > I will try to give you an overview: > - You can find several examples that demonstrate the features of the draf= t/prototype in src/test/java/com/atos/ari/rerum/ace. For instance in Comple= teTestSuccess.java: > - We have a ResourceServer (lines 74-86) that hosts a resource wh= ich will be used for the tests (this functionality would be implemented in = a constrained device) > - We have an AuthorizationServer (lines 89-106) that will perform= the authorization process on behalf of the ResourceServer and which uses a= set of policies defined a JSON file. This is out of the scope of the draft= , but we have followed this approach to achieve a complete test. > - A client wants to get access to the resource but as it does not= have an valid access token, the resource server will return an Unauthorize= d response with the information about the AuthorizationServer that must be = contacted (lines 127-135). > - The client uses this information to ask the AuthorizationServer= an AccessToken that covers its request over the ResourceServer. In this ca= se, a GET operation. (lines 138- 141) > - The client uses part of the ClientToken to perform an authorize= d resource request to the resource server (lines 143 - 152) > - The client uses part of the ClientToken to unencrypt the answer= received from the ResourceServer (lines 155 -167 ) > - In the rest of the code, a similar process if followed to perfo= rm a POST operation. > - The implementation of the actors can be found under src/main/java/com/a= tos/ari/rerum/ace folder: AuthorizationServer, Client, ResourceAce and Reso= urceServer. All these classes are used in the examples like the one I menti= oned before. > - In src/main/java/com/atos/ari/rerum/ace/messages, you can find the clas= ses that implement the different messages that are exchanged as part of the= protocol flow, e.g., the sam information message (SamInformationMessage), = the access token request message (AccessRequestMessage), the client token (= TicketTransferMessage, TicketTransferMessageFace) and the access token (Acc= essToken). The access token is embedded in the payload as described in the = draft. We use AcePayload class for this part. As you can see, the contents = of the payload are encrypted to protect data confidentiality. > In src/main/java/com/atos/ari/rerum/ace/crypto, you can find the classes = that implement the different algorithms that are initially proposed in the = draft. For instance: > - AEAD_CHACHA20_POLY130 for authenticat4ed encryption of payloads= . > - Poly1305 to generate the verifier (part of the ClientToken=20 > that is sent from the AuthorizationServer to the Client and used to=20 > encrypt payload) >=20 > The next step would be to implement the Client actor and its functionalit= y in a real constrained device. As I explained you in Berlin, this is in ou= r roadmap but we are going also to follow your comments and try to align fi= rst this draft with draft-ietf-ace-oauth-authz-02. >=20 > @Jorge, @Prabha, please correct me if anything is not totally correct and= feel free to add what you consider of interest. >=20 > I hope that this explanation is useful to understand better the code but = if you have more doubts, please don't hesitate in ask me again! >=20 > BR, >=20 > Daniel >=20 >=20 > Daniel Calvo > Energy and Transport Market > Atos Research and Innovation > Tel: +34 946 66 20 82 > daniel.calvo@atos.net > C/Real Consulado s/n, > Pol=EDgono Industrial Candina > 39011 Santander > www.atosresearch.eu >=20 >=20 >=20 > Feel free to download our booklet at > https://atos.net/en/insights-and-innovation/innovation-labs >=20 > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, September 26, 2016 10:24 AM > To: Calvo Alonso, Daniel; ace@ietf.org > Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose > Subject: Re: [Ace] Correct url for=20 > draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code >=20 > Hi Daniel, >=20 > could you provide a bit of info what you have implemented? > (I know that I can look at the code myself but you probably know all=20 > the details from the top of your head.) >=20 > Ciao > Hannes >=20 >=20 > On 08/31/2016 10:11 AM, Calvo Alonso, Daniel wrote: >> Dear all, >> >> As I promised during my presentation in the ACE WG meeting in Berlin,=20 >> this is the correct link to=20 >> draft-cuellar-ace-pat-priv-enhanced-authz-tokens prototype source code: >> >> _https://gitlab.atosresearch.eu/ari/ACE-PAT-pub_ >> >> Please, don't hesitate in contact me in case you have any doubt or probl= em. >> >> With my best regards, >> >> *Daniel Calvo* >> Energy and Transport Market >> Atos Research and Innovation >> Tel: +34 946 66 20 82 >> _daniel.calvo@atos.net_ C/Real=20 >> Consulado s/n, Pol=EDgono Industrial Candina >> 39011 Santander >> _www.atosresearch.eu_ >> >> >> *Feel free to download our booklet at*=20 >> _http://atos.net/en-us/home/we-are/insights-innovation/research-and-i >> n >> novation.html_ >> >> >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> >> >> >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 From nobody Fri Oct 14 20:50:45 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C69129409; Fri, 14 Oct 2016 20:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 p9uJoQYC8Kov; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) 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 767741293E1; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) 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 u9F3oSV1024801; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3swr8h0lH6z7xhk; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Message-ID: <5801A7D0.8050100@tzi.org> Date: Sat, 15 Oct 2016 05:51:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: ace@ietf.org, core@ietf.org, cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF97: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 15 Oct 2016 03:50:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF97. Remember that there is still quite some potential for changes. IoT is starting a bit late at IETF97; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). CORE on HOMENET and IPWAVE (Wed) and CORE on ICNRG (Fri) are a bit painful but probably the unavoidable level of conflict. Moves due to other conflict avoidance may make this worse, though. All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten SUNDAY, November 13, 2016 1300-1600 IRTF*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 1330-1530 Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRTF cfrg Crypto Forum Grand BR II OPS v6ops IPv6 Operations WG 1550-1750 Afternoon Session II Grand BR III INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG TUESDAY, November 15, 2016 0930-1200 Morning Session I Grand BR II INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR I TSV quic QUIC WG 1330-1530 Afternoon Session I Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR I RTG rtgarea Routing Area Open Meeting Studio 4 SEC tokbind Token Binding WG Grand BR III TSV tsvwg Transport Area Working Group WG 1550-1820 Afternoon Session II Grand BR II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 Morning Session I Grand BR III OPS anima Autonomic Networking Integrated Model and Approach WG Grand BR II TSV taps Transport Services WG 1110-1210 Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR I TSV tsvwg Transport Area Working Group WG 1330-1500 Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR I INT homenet Home Networking WG Grand BR III INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR II TSV tsvarea Transport Area Open Meeting 1520-1620 Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRTF*** t2trg Thing-to-Thing Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG THURSDAY, November 17, 2016 0930-1100 Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery WG Grand BR II IRTF maprg Measurement and Analysis for Protocols Grand BR I SEC saag Security Area Open Meeting 1110-1210 Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR III INT *** lwig Light-Weight Implementation Guidance WG Grand BR I SEC saag Security Area Open Meeting 1330-1500 Afternoon Session I Studio 3 SEC oauth Web Authorization Protocol WG 1520-1750 Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Environments WG Studio 2 TSV rmcat RTP Media Congestion Avoidance Techniques WG FRIDAY, November 18, 2016 0930-1130 Morning Session I Studio 4 ART *** core Constrained RESTful Environments WG Grand BR II IRTF icnrg Information-Centric Networking Park BR 1 OPS anima Autonomic Networking Integrated Model and Approach WG Park BR 2 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Park BR 1 RTG babel Babel routing protocol WG Studio 4 SEC oauth Web Authorization Protocol WG From prabhakaran.kasinathan@siemens.com Sun Oct 16 01:42:59 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7FA129632 for ; Sun, 16 Oct 2016 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 g-39UKfzxu-n for ; Sun, 16 Oct 2016 01:42:57 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 AA16D129637 for ; Sun, 16 Oct 2016 01:42:56 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id u9G8grOn024212 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 16 Oct 2016 10:42:53 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u9G8grdV004858 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Oct 2016 10:42:53 +0200 Received: from DEFTHW99ER3MSX.ww902.siemens.net (139.22.70.74) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 16 Oct 2016 10:42:52 +0200 Received: from DENBGAT9EH3MSX.ww902.siemens.net ([169.254.7.98]) by DEFTHW99ER3MSX.ww902.siemens.net ([139.22.70.74]) with mapi id 14.03.0319.002; Sun, 16 Oct 2016 10:42:51 +0200 From: "Kasinathan, Prabhakaran" To: "Calvo Alonso, Daniel" , Hannes Tschofenig , "ace@ietf.org" , Ludwig Seitz Thread-Topic: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code Thread-Index: AdIDXo/JIWofyYeVRFyCDhU6AnzNSQUYAG8AAGyJrgACwR1PAAAvvhJQAJUKoTA= Date: Sun, 16 Oct 2016 08:42:50 +0000 Message-ID: References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> <613d3596-c721-7285-82ea-03176898e22a@gmx.net> <8A926B4ADC92E345A40FA5363D47FA3003381292@DEERLM99EX1MSX.ww931.my-it-solutions.net> In-Reply-To: <8A926B4ADC92E345A40FA5363D47FA3003381292@DEERLM99EX1MSX.ww931.my-it-solutions.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.24] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Cuellar, Jorge" , "Gato, Jose" Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 16 Oct 2016 08:44:33 -0000 Dear Hannes, one of our important goals is to align the PAT draft with the ACE-OAuth fra= mework. To be precise, we are working to integrate the privacy aspects of P= AT draft together with proof-of-possession support with the ACE-OAuth frame= work. In the next versions of the draft we will explore them in detail. Also, we would like to thank Ludwig for his detailed review and comments on= the draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03. Most of the minor= comments are fixed, and currently we are investigating some of his other s= uggestions. We have planned to address Ludwig's comments in the next versio= ns of PAT draft. As Daniel has already mentioned C/C++ implementation on constrained nodes i= s in our roadmap. Thank you for attaching student project links, we will lo= ok into them as well. Best regards, Prabhakaran Kasinathan -----Original Message----- From: Calvo Alonso, Daniel [mailto:daniel.calvo@atos.net]=20 Sent: Donnerstag, 13. Oktober 2016 11:39 To: Hannes Tschofenig; ace@ietf.org Cc: Kasinathan, Prabhakaran (CT RDA ITS SEA-DE); Cuellar, Jorge (CT RDA ITS= ); Gato, Jose Subject: RE: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-auth= z-tokens source code Hi Hannes, Probably Jorge or Prabha could give you a more accurate answer regarding ho= w close is draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 (and the imp= lementation) to the ACE-Oauth framework since I am more focused on the impl= ementation itself. We are already aware that most of devices targeted by ACE group are not abl= e to run Java apps but our intention with this first prototype was just to = start validating the draft concepts from a high-level perspective. A transl= ation of the client and resource server functionalities to C/C++ is also in= our roadmap for the incoming months so that we could demonstrate the draft= benefits with real use-cases and devices. We will keep you informed about = our advanced in this line. We will review these codes and projects to try to find potential overlappin= gs with our work, thanks!! :) For your last question, I think that again Jorge or Prabha will give you a = more detailed answer, but I guess that they are already working on this. Thanks and BR, Daniel Daniel Calvo Energy and Transport Market Atos Research and Innovation Tel: +34 946 66 20 82 daniel.calvo@atos.net C/Real Consulado s/n, Pol=EDgono Industrial Candina 39011 Santander www.atosresearch.eu Feel free to download our booklet at https://atos.net/en/insights-and-innovation/innovation-labs This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it.=20 As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted.=20 Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional.=20 Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.=20 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.= =20 Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.=20 This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it.=20 As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted.=20 Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente=A0y p= ueden estar protegidos por secreto profesional.=20 Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.=20 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.= =20 Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.=20 -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Wednesday, October 12, 2016 2:41 PM To: Calvo Alonso, Daniel; ace@ietf.org Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-auth= z-tokens source code Hi Daniel, thanks for the description. How close is the implementation to the ACE-OAuth framework? I am asking this question since you could have re-used lots of existing cod= e since there are many open source implementations of OAuth authorization s= ervers around (even in Java). The use of Java for the client only makes sense if you are planning to run = it on an Android phone/tablet (which is one of the use cases, of course). I= f the client (or the resource server) are running on an IoT device then Jav= a is not that common (at least not on the low end devices, which the ACE gr= oup is mostly focused on). Most IoT devices are using C (or C++ at best). Maybe there is a chance that your European funded research project contribu= tes code to a C-implementation of COSE, where preliminary work has been don= e already by a student in Sweden, see https://github.com/Gunzter/COSE-C Adding proof-of-possession support to OAuth authorization servers would als= o be appreciated. I think that these student projects from Trier University give some insight= into how existing components can be re-used. In this case the scenario was= to write an Android app to interact with an authorization server to obtain= an access token that can be used to gain access to a smart door lock. Code from one group: https://github.com/StudienprojektUniTrier Code from the second group: http://tschofenig.priv.at/Trier-Gruppe3.zip Ciao Hannes PS: Is there a plan to take the privacy aspects from draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 and to align them with = the ACE framework? On 09/28/2016 12:42 PM, Calvo Alonso, Daniel wrote: > Hi Hannes, >=20 > Sorry for the delayed answer but I have been travelling for a couple of d= ays. >=20 > This code is a first JAVA prototype that implements the actors, messages = and flows that are defined in draft-cuellar-ace-pat-priv-enhanced-authz-to= kens-03. >=20 > I will try to give you an overview: > - You can find several examples that demonstrate the features of the draf= t/prototype in src/test/java/com/atos/ari/rerum/ace. For instance in Comple= teTestSuccess.java: > - We have a ResourceServer (lines 74-86) that hosts a resource wh= ich will be used for the tests (this functionality would be implemented in = a constrained device) > - We have an AuthorizationServer (lines 89-106) that will perform= the authorization process on behalf of the ResourceServer and which uses a= set of policies defined a JSON file. This is out of the scope of the draft= , but we have followed this approach to achieve a complete test. > - A client wants to get access to the resource but as it does not= have an valid access token, the resource server will return an Unauthorize= d response with the information about the AuthorizationServer that must be = contacted (lines 127-135). > - The client uses this information to ask the AuthorizationServer= an AccessToken that covers its request over the ResourceServer. In this ca= se, a GET operation. (lines 138- 141) > - The client uses part of the ClientToken to perform an authorize= d resource request to the resource server (lines 143 - 152) > - The client uses part of the ClientToken to unencrypt the answer= received from the ResourceServer (lines 155 -167 ) > - In the rest of the code, a similar process if followed to perfo= rm a POST operation. > - The implementation of the actors can be found under src/main/java/com/a= tos/ari/rerum/ace folder: AuthorizationServer, Client, ResourceAce and Reso= urceServer. All these classes are used in the examples like the one I menti= oned before. > - In src/main/java/com/atos/ari/rerum/ace/messages, you can find the clas= ses that implement the different messages that are exchanged as part of the= protocol flow, e.g., the sam information message (SamInformationMessage), = the access token request message (AccessRequestMessage), the client token (= TicketTransferMessage, TicketTransferMessageFace) and the access token (Acc= essToken). The access token is embedded in the payload as described in the = draft. We use AcePayload class for this part. As you can see, the contents = of the payload are encrypted to protect data confidentiality. > In src/main/java/com/atos/ari/rerum/ace/crypto, you can find the classes = that implement the different algorithms that are initially proposed in the = draft. For instance: > - AEAD_CHACHA20_POLY130 for authenticat4ed encryption of payloads= . > - Poly1305 to generate the verifier (part of the ClientToken=20 > that is sent from the AuthorizationServer to the Client and used to=20 > encrypt payload) >=20 > The next step would be to implement the Client actor and its functionalit= y in a real constrained device. As I explained you in Berlin, this is in ou= r roadmap but we are going also to follow your comments and try to align fi= rst this draft with draft-ietf-ace-oauth-authz-02. >=20 > @Jorge, @Prabha, please correct me if anything is not totally correct and= feel free to add what you consider of interest. >=20 > I hope that this explanation is useful to understand better the code but = if you have more doubts, please don't hesitate in ask me again! >=20 > BR, >=20 > Daniel >=20 >=20 > Daniel Calvo > Energy and Transport Market > Atos Research and Innovation > Tel: +34 946 66 20 82 > daniel.calvo@atos.net > C/Real Consulado s/n, > Pol=EDgono Industrial Candina > 39011 Santander > www.atosresearch.eu >=20 >=20 >=20 > Feel free to download our booklet at > https://atos.net/en/insights-and-innovation/innovation-labs >=20 > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, September 26, 2016 10:24 AM > To: Calvo Alonso, Daniel; ace@ietf.org > Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose > Subject: Re: [Ace] Correct url for > draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code >=20 > Hi Daniel, >=20 > could you provide a bit of info what you have implemented? > (I know that I can look at the code myself but you probably know all=20 > the details from the top of your head.) >=20 > Ciao > Hannes >=20 >=20 > On 08/31/2016 10:11 AM, Calvo Alonso, Daniel wrote: >> Dear all, >> >> As I promised during my presentation in the ACE WG meeting in Berlin,=20 >> this is the correct link to=20 >> draft-cuellar-ace-pat-priv-enhanced-authz-tokens prototype source code: >> >> _https://gitlab.atosresearch.eu/ari/ACE-PAT-pub_ >> >> Please, don't hesitate in contact me in case you have any doubt or probl= em. >> >> With my best regards, >> >> *Daniel Calvo* >> Energy and Transport Market >> Atos Research and Innovation >> Tel: +34 946 66 20 82 >> _daniel.calvo@atos.net_ C/Real=20 >> Consulado s/n, Pol=EDgono Industrial Candina >> 39011 Santander >> _www.atosresearch.eu_ >> >> >> *Feel free to download our booklet at*=20 >> _http://atos.net/en-us/home/we-are/insights-innovation/research-and-i >> n >> novation.html_ >> >> >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> >> >> >> This e-mail and the documents attached are confidential and intended=20 >> solely for the addressee; it may also be privileged. If you receive=20 >> this e-mail in error, please notify the sender immediately and destroy i= t. >> As its integrity cannot be secured on the Internet, the Atos group=20 >> liability cannot be triggered for the message content. Although the=20 >> sender endeavors to maintain a computer virus-free network, the=20 >> sender does not warrant that this transmission is virus-free and will=20 >> not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informaci=F3n=20 >> confidencial destinada solamente a la(s) persona(s) mencionadas=20 >> anteriormente y pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electr=F3nico por error, gracias por=20 >> informar inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red,=20 >> Atos no se hace responsable por su contenido. Su contenido no=20 >> constituye ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n= =20 >> escrita por ambas partes. >> Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el=20 >> emisor no puede garantizar nada al respecto y no ser=E1 responsable de=20 >> cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > This e-mail and the documents attached are confidential and intended sole= ly for the addressee; it may also be privileged. If you receive this e-mail= in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group liabil= ity cannot be triggered for the message content. Although the sender endeav= ors to maintain a computer virus-free network, the sender does not warrant = that this transmission is virus-free and will not be liable for any damages= resulting from any virus transmitted. >=20 > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confid= encial destinada solamente a la(s) persona(s) mencionadas anteriormente y p= ueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por informar= inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos no= se hace responsable por su contenido. Su contenido no constituye ning=FAn = compromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas parte= s. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emi= sor no puede garantizar nada al respecto y no ser=E1 responsable de cualesq= uiera da=F1os que puedan resultar de una transmisi=F3n de virus. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 From nobody Tue Oct 18 01:34:37 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA36129997 for ; Tue, 18 Oct 2016 01:34:34 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RkJCkhqReGrl for ; Tue, 18 Oct 2016 01:34:31 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 882C0129991 for ; Tue, 18 Oct 2016 01:34:31 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f6so148804682qtd.2 for ; Tue, 18 Oct 2016 01:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=o542RSINtbLaiXZl6BiR9LPrGnCeYmPwpm4FVnppWeI=; b=wj2WbAxxzt3jt1AX/XOvvSyZfvFo+VwP7snUOW/bahIP+P8eTab+tDSglZNNgoCtJK anmBFARL3MGVX+7uASZeYTLmGa6B9MtSK7TChc+snvAPckj/BoZfe1ObMUBtN3Ji5rat nYWmzp5262pwgipGgbbqMoQShicxPkkMZQ/UjzH5iaKZxdR5+ed9/AufjbQiIgBrjcZ1 p4dEJDoUTKI8P5lNsPHVdUPG1H1Gcs3+TRaza7pkUxDu7js1kQaRKNfWODrpdeykm8Ex HZNOlKvGC5q1KA7jni31hvQe4YLVwmKiI+I3JBw8WjIPj+JVd0q6ZvQQlEx+YxYKa8VQ leKQ== 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:from:date :message-id:subject:to; bh=o542RSINtbLaiXZl6BiR9LPrGnCeYmPwpm4FVnppWeI=; b=HNRyT/6OWNUaCiY0fM+cIhoLf4+LknG73DM8iuo17z4OF0biH4h8IZIPoMJ3oOMLsa 4cNk6evXutx0aP1Uabv82FFQR1thvA6KnSC4LWf/Xthh/EsOrUshITqpFJKQBLES6MQf uwl7LrqOWi0Qzj4T0+V/FcNbPLePe2Kovc+NNELpLi3qx9okJgLoES1GpuNKkj/YwEPs 3NR/FcHppBzI2OzSzDX4HteMc58bcZs9iGee+H4xoiklagOK0ih+ZDk37oRVZ0uJXX3+ 8OJputCalyzUFKiyfYaMWXovkmk663yWsxOzK3Y32Yo2MTtv3rQKNlrejUV+HRPmcxnl 28iA== X-Gm-Message-State: AA6/9RkSawb17GA7JhsvN027H/yqaZAj+4AjHi4y5/raYeIuyrbdvWkxT0vfRMALGd5yyxvg6X9HYIPmg//E7A== X-Received: by 10.28.93.137 with SMTP id r131mr10501606wmb.2.1476779670328; Tue, 18 Oct 2016 01:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.153.219 with HTTP; Tue, 18 Oct 2016 01:34:29 -0700 (PDT) In-Reply-To: References: <147627212816.24170.6595320071556255667.idtracker@ietfa.amsl.com> From: Cigdem Sengul Date: Tue, 18 Oct 2016 09:34:29 +0100 Message-ID: To: "ace@ietf.org" Content-Type: multipart/alternative; boundary=001a11471ae4a95bfb053f1f8f52 Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 18 Oct 2016 08:34:34 -0000 --001a11471ae4a95bfb053f1f8f52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Ludwig, Thanks for adding the new sections on requirements on profiles and the examples in the appendix are quite useful too. I list minor typos and request for clarification/consistency below. Hope it helps. Minor typos: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect on the AS and receives information about the access token contain in the response=E2=80=9D. =3D=3D> Remove =E2=80=9Ccontain=E2=80=9D? Page 8/Section 3.2: "and also to support security for CoAP over different transport in a uniform way,=E2=80=9D =3D=3D> =E2=80=9Cover a different transport=E2=80=9D Page 8/Section 4: " RFC 7744 [RFC7744 ] describes many different IoT use cases but there two preferred grant types=E2=80=9D =3D=3D>"there are two" Page 9/Section 4: "the OAuth client itself is constraint. In such a =E2=80= =9C =3D=3D> =E2=80=9Cthe OAuth client itself is constrained.=E2=80=9D Page 9/Section 4: "which is often accomplished using an commissioning tool.=E2=80=9D =3D=3D> =E2=80=9Ca commissioning tool=E2=80=9D Page 10/Section 4/Access Token Response: "More information about these parameters can be found in in Section 6.4 = .=E2=80=9D =3D=3D> Remove the second =E2=80=9Cin=E2=80=9D Page 16/Section 6.2/AS-to-Client Response: "The content of the successful reply MUST be encoded as CBOR map, containing paramters as specified " =3D=3D> =E2=80=9Cparamters=E2=80=9D typo Page 20/Figure 8/caption: "Confirmation paramter=E2=80=9D =3D=3D> typo in =E2=80=9Cparameter=E2=80=9D Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object= =E2=80=9D =3D=3D> typo in =E2=80=9CCOSE_Encrytped=E2=80=9D Page 26/Section 8: "same way as specified for the "cnf" parameter in sectio= n Section 6.4.5 .= =E2=80=9D =3D=3D> Remove duplicate =E2=80=9Csection=E2=80=9D Page 29/10.1/cnf description: "Description: Key to use to prove the right to use an access token, as defined in [RFC7800 ].=E2=80= =9D =3D=3D> Drop the first =E2=80=9Cto use=E2=80=9D. =E2=80=9CKey to prove the = right to use an access token=E2=80=9D? Page 30/10.1/aud description: =E2=80=9CDescription: reference to" =3D=3D> =E2=80=9Cr=E2=80=9D capital in reference Page 30/10.1/profile description: =E2=80=9CThe communication and communicat= ion security profile=E2=80=9D =3D=3D> =E2=80=9Ccommunication=E2=80=9D duplicate. Page 30/10.2/cnf: "Description: Key to use to prove the right to use=E2=80= =9D =3D=3D> Drop the first =E2=80=9Cto use=E2=80=9D Page 32/10.6.1/Profile description: =E2=80=9Cover view=E2=80=9D =3D=3D> =E2=80=9Coverview" Requests for clarification: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 6/Access Token: "The access token is protected against modifications using a MAC or a digital signature, which is added by the AS=E2=80=9D Question: Are access tokens also confidentiality protected e.g., encrypted by the AS, to be consumed by RS? It seems to be the case according to Page 9: "Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the content is confidentiality protected.=E2=80=9D Page 11/Section 4/Token Introspection Response: "The AS can additionally return information that the RS needs to pass on to the client in the form of a client token. The latter is used to establish keys for mutual authentication between client and RS, when the client has no direct connectivity to the AS.=E2=80=9D Question: The client still should have had an initial connectivity to the A= S, and has acquired an initial access token, right? This seems to be what is described in Page 24. Page 15/Figure 4: Question: Is the grant_type in this example =E2=80=9Cclient_credentials=E2= =80=9D or =E2=80=9Cpassword=E2=80=9D? Page 17/Figure 5: Question: Shouldn=E2=80=99t the example contain the =E2=80=9Cprofile=E2=80= =9D parameter, which was =E2=80=9CREQUIRED=E2=80=9D in the response in the previous paragraphs. Page 19/20/CoSE_Encrypted: Question: Is this confirmation parameter used when passing the key to the client as a response to POST to /token? Or is it used when passing client token through RS? From Page 24, it seems to be former. Page 27/Section 8.1: "Profiles of this framework MAY define other methods for token transport. Implementations conforming to this framework MUST implement this method of token transportation.=E2=80=9D Question: Do you mean =E2=80=9Cthis framework=E2=80=9D or =E2=80=9Cthis dra= ft=E2=80=9D. Just want to be absolutely sure, that profiles MAY define other methods for token transport. Page 28/Section 9: "Using a single shared secret with multiple authorization server =E2=80=9C Question: There is a type here. =E2=80=9CServer=E2=80=9D should be =E2=80= =9Cservers=E2=80=9D but shouldn=E2=80=99t this be =E2=80=9CResource servers=E2=80=9D? Page 44/Appendix B: =E2=80=9CResource Server=E2=80=9D Question: Is introspection option excluded here deliberately? =E2=80=9C The sentence: "Optionally: Check that the matching tokens are still valid (if this is possible.)=E2=80=9D Is this the hint for the introspection? Hope this helps, --Cigdem Sengul Senior Researcher Nominet On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seitz wrote: > Hello ACE, > > we have uploaded a new version of our draft, addressing mainly the review > comments from Renzo and adding a number of clarifications about the /toke= n, > /introspect and /authz-info endpoints. > > Please review this version and send us comments, if we get enough feeback > we might be able to produce another version before the cut-off. > > > Regards, > > Ludwig > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.txt > Date: Wed, 12 Oct 2016 04:35:28 -0700 > From: internet-drafts@ietf.org > To: Ludwig Seitz , Erik Wahlstroem < > erik@wahlstromtekniska.se>, Goeran Selander = , > Samuel Erdtman , Hannes Tschofenig < > hannes.tschofenig@arm.com> > > > A new version of I-D, draft-ietf-ace-oauth-authz-03.txt > has been successfully submitted by Ludwig Seitz and posted to the > IETF repository. > > Name: draft-ietf-ace-oauth-authz > Revision: 03 > Title: Authentication and Authorization for Constrained > Environments (ACE) > Document date: 2016-10-12 > Group: ace > Pages: 56 > URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-au > thz-03.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-ace-oauth-authz/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-03 > > Abstract: > This specification defines a framework for authentication and > authorization in Internet of Things (IoT) environments. The > framework is based on a set of building blocks including OAuth 2.0 > and CoAP, thus making a well-known and widely used authorization > solution suitable for IoT devices. Existing specifications are used > where possible, but where the constraints of IoT devices require it, > extensions are added and profiles are defined. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a11471ae4a95bfb053f1f8f52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ludwi= g,=C2=A0

Thanks for adding the new section= s on requirements on profiles and the examples in the appendix are quite us= eful too.=C2=A0
I list m= inor typos and request for clarification/consistency below. Hope it helps.<= /div>

Minor typos:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page 5/Section 3.1/ OAuth2.0= : "The RS makes a POST request to /in= trospect on the AS and
      receives information about the acce=
ss token contain in the
      response=E2=80=9D.=C2=A0
      =3D=3D> Remove =E2=80=9Cco=
ntain=E2=80=9D?

Page 8/Section 3.2: "and=
 also to support security for CoAP over
   different transport in a unifo=
rm way,=E2=80=9D 
      =3D=3D> =E2=80=9Cover a different transport=E2=
=80=9D

Page 8/Section 4: " RFC 7744 [RFC7744] des=
cribes many different
   I=
oT use cases but there two preferred grant types=E2=80=9D
     =3D=3D>"there are two" =


Page 9/Sect=
ion 4: "the OAuth client itself is cons=
traint.  In such a =E2=80=9C 
        =3D=3D> =E2=80=9Cthe OAu=
th client itself is constrained.=E2=80=9D

Page 9/Section 4=
: "which is often accomplished=
 using
   an commis=
sioning tool.=E2=80=9D 
  =
  =3D=3D>  =E2=80=9Ca commissioning tool=E2=80=9D

Page 10/Section 4/Access Token Response: "More
      information about these parameters =
can be found in in Section 6.4.=E2=80=9D
=
    =3D=3D> Remove the secon=
d =E2=80=9Cin=E2=80=9D
Page 16/Section 6.2/AS-t=
o-Client Response: "The content of the successful reply MUST be encode=
d as CBOR map,
   containi=
ng paramters as specified "
    =3D=3D> =E2=80=9Cparamters=E2=80=9D typo

Page 20/Figure 8/caption: "Confirmation paramter=E2=80=9D
      =3D=3D> typo in =E2=80=9Cparameter=E2=80=9D=


Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object<=
/span>=E2=80=9D
    =3D=3D> typo in =E2=80=9CCOSE_Encrytped=E2=80=
=9D

Page 26/Section 8: "same way as specified for the "cnf"= parameter in section
   Section 6.4.5.=E2=80=9D 
=3D=3D> Remove du=
plicate =E2=80=9Csection=E2=80=9D

Page 29/10.1/cnf description: "Description: Key to use to prove = the right to use an access token,
      as defined in [RFC7800].=E2=80=9D
=3D=3D>=
; Drop the first =E2=80=9Cto use=E2=80=9D. =E2=80=9CKey to prove the right =
to use an access token=E2=80=9D?

Page 30/10.1/aud =
description: =E2=80=9CDescription: reference to"
=3D=3D> =
=E2=80=9Cr=E2=80=9D capital in reference

Page 30/10.1/= profile description: =E2=80=9CThe communication and communication security = profile=E2=80=9D
=3D=3D> =E2=80=9Ccommunication=E2=80=9D duplicate.
=

=
Page 30/10.2/=
cnf: "Description: Key to use to prove the right to use=E2=80=9D<=
/pre>
=3D=3D> D=
rop the first =E2=80=9Cto use=E2=80=9D

Page 32/10.6.1/Profile description: =E2=
=80=9Cover view=E2=80=9D
=3D=3D> =E2=80=9Coverview"



Requests for clarification: 
<=
font face=3D"arial, helvetica, sans-serif">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page 6/Access Token: "The acc=
ess token is protected against modifications using a MAC or
      a digit=
al signature, which is added by the AS=E2=80=9D

Question: Are acce=
ss tokens also confidentiality protected e.g., encrypted by the AS, to be c=
onsumed by RS?
It seems to be the case according to Page 9:
<=
pre class=3D"gmail-m_-5027769899048254041gmail-m_7881451645977060193gmail-m=
_-3770847762660526636gmail-m_-6736492023052015749gmail-newpage" style=3D"wh=
ite-space:pre-wrap;margin-top:0px;margin-bottom:0px;page-break-before:alway=
s;color:rgb(0,0,0)">"Estab=
lished keying material between the AS and the RS allows
   the AS to apply cryptographic protection t=
o the access token to
   ensure that its content cannot be modified, and if needed, that the
   content is confidentiality protected.=E2=80=9D

Page 11/Section 4/Token Introspection Response: "The AS can additio=
nally
      return informa=
tion that the RS needs to pass on to the client in
      the form of a client token.  The latter is used to establish keys
      for mutual authentication between client and RS, when the client
      has no direct connectivity to the AS.=E2=80=9D

Question: The client still should have had an initial connectivity to=
 the AS,=C2=A0
and has acq=
uired an initial access token, right? This seems to be what is described in=
 Page 24. 

Page 15/Figure 4: 
Question: Is the grant_type in this examp=
le =E2=80=9Cclient_credentials=E2=80=9D or =E2=80=9Cpassword=E2=80=9D?

Page 17/Figure 5: 
Question: Shouldn=E2=80=99t the example contain the =E2=80=
=9Cprofile=E2=80=9D parameter, which was =E2=80=9CREQUIRED=E2=80=9D in the =
response in the previous paragraphs. 

Page 19/2=
0/CoSE_Encrypted:
Question=
: Is this confirmation parameter used when passing the key to the client as=
 a response to POST to /token? Or is it used when passing client token thro=
ugh RS? From Page 24, it seems to be former.

Pa=
ge 27/Section 8.1:
"Profiles of this framework MAY define other
   methods for token transport.  Implementations conforming to this
   framework MUST implement this method of token transportation.=E2=80=9D
Question: Do you mean =E2=80=9Cthis framework=E2=80=9D =
or =E2=80=9Cthis draft=E2=80=9D. Just want to be absolutely sure, that prof=
iles MAY define other methods for token transport. 

Page 28/Section 9: "U=
sing a single
   shared secret with multiple authoriza=
tion server =E2=80=9C
<=
font face=3D"arial, helvetica, sans-serif">Question: There is a type here. =
=E2=80=9CServer=E2=80=9D should be =E2=80=9Cservers=E2=80=9D but shouldn=E2=
=80=99t this be =E2=80=9CResource servers=E2=80=9D?
<=
br>
Page 44/Appendix B: =E2=80=9CResource Serve=
rQuestion: Is introspection option e=
xcluded here deliberately? =E2=80=9C The sentence: "Op=
tionally: Check that the matching tokens are still valid (if this is possible.)=
=E2=80=9D Is this the hint for the introspection?
 
Hope this helps,
--Cigdem Sengul
Senior Researcher
Nominet=C2=A0

On Wed, Oct 12, 2016 at 12:= 37 PM, Ludwig Seitz <ludwig@sics.se> wrote:
Hello ACE,

we have uploaded a new version of our draft, addressing mainly the review c= omments from Renzo and adding a number of clarifications about the /token, = /introspect and /authz-info endpoints.

Please review this version and send us comments, if we get enough feeback w= e might be able to produce another version before the cut-off.


Regards,

Ludwig


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.tx= t
Date: Wed, 12 Oct 2016 04:35:28 -0700
From: interne= t-drafts@ietf.org
To: Ludwig Seitz <lu= dwig@sics.se>, Erik Wahlstroem <erik@wahlstromtekniska.se>, Goeran Sel= ander <= goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Hannes T= schofenig <hannes.tschofenig@arm.com>


A new version of I-D, draft-ietf-ace-oauth-authz-03.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ace-oauth-authz Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication and Authorization f= or Constrained Environments (ACE)
Document date:=C2=A0 2016-10-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ace
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56
URL: https://www.ietf.org/inte= rnet-drafts/draft-ietf-ace-oauth-authz-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-ietf-ace-oauth-authz-03
Diff: https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-ace-oauth-authz-03

Abstract:
=C2=A0 =C2=A0This specification defines a framework for authentication and<= br> =C2=A0 =C2=A0authorization in Internet of Things (IoT) environments.=C2=A0 = The
=C2=A0 =C2=A0framework is based on a set of building blocks including OAuth= 2.0
=C2=A0 =C2=A0and CoAP, thus making a well-known and widely used authorizati= on
=C2=A0 =C2=A0solution suitable for IoT devices.=C2=A0 Existing specificatio= ns are used
=C2=A0 =C2=A0where possible, but where the constraints of IoT devices requi= re it,
=C2=A0 =C2=A0extensions are added and profiles are defined.




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.

The IETF Secretariat



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


--001a11471ae4a95bfb053f1f8f52-- From nobody Tue Oct 18 22:18:43 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80812949B for ; Tue, 18 Oct 2016 22:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 j-aPAF8IOLhU for ; Tue, 18 Oct 2016 22:18:38 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 8763A12944B for ; Tue, 18 Oct 2016 22:18:37 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f193so35369434wmg.1 for ; Tue, 18 Oct 2016 22:18:37 -0700 (PDT) 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:from:date:message-id:subject:to :cc; bh=LMoFPsuLy10JY3PxwP3ZMy7kkN3bjL1hvv/kc9wmCN4=; b=ruS5yiGh0EHB9qZhQYp2D/XwbkdgXiLnDWQeP2eN4/sr1XdxLYc1vY4qvSIJnVLUIj WxjKYh3fH7fb2BWpxRoliOTeLySd8Fh9aCcrWkzTPAQcoaOzzLAxpj+SzSVt8rgqjy4G gqmDhhx2Cb7R1RDH1vqpiqM+Thvn2Um5zJbLmJLV/+zb6LWOqUO3qX0Renw7dVA6SDMV vLVdMTNqYKRVMAsuS546fOy2PsWMXyt+QPZHho5Yc78YCL6FSSPGLkIW/4b080SICmfS kKSGtw4dh/vsvJdth1UIbrK+2hkfStyeFUmTSOjygZ0iRvIHlD9zBlMiEnuixyqYzmDL gCvg== 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:from:date :message-id:subject:to:cc; bh=LMoFPsuLy10JY3PxwP3ZMy7kkN3bjL1hvv/kc9wmCN4=; b=mNKUDE3ZcZO+A8/F+CJTTB+sL5l7ON5Ho07vqPxb4VXAjal8kQV/LzpyD/INytTsJj A2aD+0QfmDKlWpKokV8TP3NVOWUjUjKw6FZVoo1HT5LaKqSZBK8cvv1ThDBcrIl5ohPH +Hy5so1Z7B/Ps7RvGoThsXx1h/Z9wWFdMfpJfUhkjAATFKZ7WyW4K/HoknEVF9EyGU4M DVZzRwemON1DruKNWjYCj3prYpBbNmGPRRfKWskbWxjf2AuZo28oKb1LsZxIz5aj1KkP B/epCf1+LlvB8AbxP3gjR+XfPAvvv68SGUWMLS7Y3UEUgHsCOC9KI880Npx0I6zWomE8 IpIA== X-Gm-Message-State: AA6/9RnR5EwMtvW85Uz+0LV9pYJbCf5prpEL1dMBxRVMS+sq8UnlrldakbOcjZigTPLsw5Pipsy4pmDPSZi5bw== X-Received: by 10.28.185.137 with SMTP id j131mr3238765wmf.73.1476854315933; Tue, 18 Oct 2016 22:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.172.232 with HTTP; Tue, 18 Oct 2016 22:18:35 -0700 (PDT) In-Reply-To: References: <147627212816.24170.6595320071556255667.idtracker@ietfa.amsl.com> From: Samuel Erdtman Date: Wed, 19 Oct 2016 07:18:35 +0200 Message-ID: To: Cigdem Sengul Content-Type: multipart/alternative; boundary=001a1148e560e2f9e0053f30f080 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 19 Oct 2016 05:18:41 -0000 --001a1148e560e2f9e0053f30f080 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for reading and commenting. I have looked at the minor typos for now, see inline Working draft can be found here https://github.com/LudwigSeitz/ace-oauth //Samuel On Tue, Oct 18, 2016 at 10:34 AM, Cigdem Sengul wrote: > Hello Ludwig, > > Thanks for adding the new sections on requirements on profiles and the > examples in the appendix are quite useful too. > I list minor typos and request for clarification/consistency below. Hope > it helps. > > Minor typos: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect > on the AS and > > receives information about the access token contain in the > response=E2=80=9D. > > =3D=3D> Remove =E2=80=9Ccontain=E2=80=9D? > > fixed > > Page 8/Section 3.2: "and also to support security for CoAP over > > different transport in a uniform way,=E2=80=9D > > =3D=3D> =E2=80=9Cover a different transport=E2=80=9D > > fixed > > Page 8/Section 4: " RFC 7744 [RFC77= 44 ] describes many different > > IoT use cases but there two preferred grant types=E2=80=9D > > =3D=3D>"there are two" > > fixed > > Page 9/Section 4: "the OAuth client itself is constraint. In such a =E2= =80=9C > > =3D=3D> =E2=80=9Cthe OAuth client itself is constrained.=E2=80=9D > > fixed > > Page 9/Section 4: "which is often accomplished using > > an commissioning tool.=E2=80=9D > > =3D=3D> =E2=80=9Ca commissioning tool=E2=80=9D > > fixed > > Page 10/Section 4/Access Token Response: "More > > information about these parameters can be found in in Section 6.4 <= https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#section-6.4>.=E2= =80=9D > > =3D=3D> Remove the second =E2=80=9Cin=E2=80=9D > > fixed > > Page 16/Section 6.2/AS-to-Client Response: "The content of the successful= reply MUST be encoded as CBOR map, > > containing paramters as specified " > > =3D=3D> =E2=80=9Cparamters=E2=80=9D typo > > fixed > > Page 20/Figure 8/caption: "Confirmation parameter=E2=80=9D > > =3D=3D> typo in =E2=80=9Cparameter=E2=80=9D > > fixed > > Page 24/Just below Figure 14: "The client token is a COSE_Encrytped objec= t=E2=80=9D > > =3D=3D> typo in =E2=80=9CCOSE_Encrytped=E2=80=9D > > fixed > > Page 26/Section 8: "same way as specified for the "cnf" parameter in sect= ion > > Section 6.4.5 .=E2=80=9D > > =3D=3D> Remove duplicate =E2=80=9Csection=E2=80=9D > > fixed > > Page 29/10.1/cnf description: "Description: Key to use to prove the right= to use an access token, > > as defined in [RFC7800 ].=E2= =80=9D > > =3D=3D> Drop the first =E2=80=9Cto use=E2=80=9D. =E2=80=9CKey to prove th= e right to use an access token=E2=80=9D? > > fixed > > Page 30/10.1/aud description: =E2=80=9CDescription: reference to" > > =3D=3D> =E2=80=9Cr=E2=80=9D capital in reference > > fixed > > Page 30/10.1/profile description: =E2=80=9CThe communication and communic= ation security profile=E2=80=9D > > =3D=3D> =E2=80=9Ccommunication=E2=80=9D duplicate. > > The profile will define both communication, e.g. COAP or HTTP, and communication security, e.g. DTLS or COSE. So it might be useful that this is called out > > Page 30/10.2/cnf: "Description: Key to use to prove the right to use=E2= =80=9D > > =3D=3D> Drop the first =E2=80=9Cto use=E2=80=9D > > fixed > > Page 32/10.6.1/Profile description: =E2=80=9Cover view=E2=80=9D > > =3D=3D> =E2=80=9Coverview" > > fixed > > > > Requests for clarification: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Page 6/Access Token: "The access token is protected against modifications= using a MAC or > > a digital signature, which is added by the AS=E2=80=9D > > > Question: Are access tokens also confidentiality protected e.g., encrypte= d by the AS, to be consumed by RS? > > It seems to be the case according to Page 9: > > "Established keying material between the AS and the RS allows > > the AS to apply cryptographic protection to the access token to > ensure that its content cannot be modified, and if needed, that the > content is confidentiality protected.=E2=80=9D > > > Page 11/Section 4/Token Introspection Response: "The AS can additionally > > return information that the RS needs to pass on to the client in > the form of a client token. The latter is used to establish keys > for mutual authentication between client and RS, when the client > has no direct connectivity to the AS.=E2=80=9D > > > Question: The client still should have had an initial connectivity to the= AS, > > and has acquired an initial access token, right? This seems to be what is= described in Page 24. > > > Page 15/Figure 4: > > Question: Is the grant_type in this example =E2=80=9Cclient_credentials= =E2=80=9D or =E2=80=9Cpassword=E2=80=9D? > > > Page 17/Figure 5: > > Question: Shouldn=E2=80=99t the example contain the =E2=80=9Cprofile=E2= =80=9D parameter, which was =E2=80=9CREQUIRED=E2=80=9D in the response in t= he previous paragraphs. > > > Page 19/20/CoSE_Encrypted: > > Question: Is this confirmation parameter used when passing the key to the= client as a response to POST to /token? Or is it used when passing client = token through RS? From Page 24, it seems to be former. > > > Page 27/Section 8.1: > > "Profiles of this framework MAY define other > methods for token transport. Implementations conforming to this > framework MUST implement this method of token transportation.=E2=80=9D > > Question: Do you mean =E2=80=9Cthis framework=E2=80=9D or =E2=80=9Cthis d= raft=E2=80=9D. Just want to be absolutely sure, that profiles MAY define ot= her methods for token transport. > > > Page 28/Section 9: "Using a single > > shared secret with multiple authorization server =E2=80=9C > > Question: There is a type here. =E2=80=9CServer=E2=80=9D should be =E2=80= =9Cservers=E2=80=9D but shouldn=E2=80=99t this be =E2=80=9CResource servers= =E2=80=9D? > > > Page 44/Appendix B: =E2=80=9CResource Server=E2=80=9D > > Question: Is introspection option excluded here deliberately? =E2=80=9C T= he sentence: "Optionally: Check that the matching tokens are still valid (i= f this is possible.)=E2=80=9D Is this the hint for the introspection? > > Hope this helps, > --Cigdem Sengul > Senior Researcher > Nominet > > On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seitz wrote: > >> Hello ACE, >> >> we have uploaded a new version of our draft, addressing mainly the revie= w >> comments from Renzo and adding a number of clarifications about the /tok= en, >> /introspect and /authz-info endpoints. >> >> Please review this version and send us comments, if we get enough feebac= k >> we might be able to produce another version before the cut-off. >> >> >> Regards, >> >> Ludwig >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.txt >> Date: Wed, 12 Oct 2016 04:35:28 -0700 >> From: internet-drafts@ietf.org >> To: Ludwig Seitz , Erik Wahlstroem < >> erik@wahlstromtekniska.se>, Goeran Selander , >> Samuel Erdtman , Hannes Tschofenig < >> hannes.tschofenig@arm.com> >> >> >> A new version of I-D, draft-ietf-ace-oauth-authz-03.txt >> has been successfully submitted by Ludwig Seitz and posted to the >> IETF repository. >> >> Name: draft-ietf-ace-oauth-authz >> Revision: 03 >> Title: Authentication and Authorization for Constrained >> Environments (ACE) >> Document date: 2016-10-12 >> Group: ace >> Pages: 56 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-au >> thz-03.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-ietf-ace-oauth-authz/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-0= 3 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-03 >> >> Abstract: >> This specification defines a framework for authentication and >> authorization in Internet of Things (IoT) environments. The >> framework is based on a set of building blocks including OAuth 2.0 >> and CoAP, thus making a well-known and widely used authorization >> solution suitable for IoT devices. Existing specifications are used >> where possible, but where the constraints of IoT devices require it, >> extensions are added and profiles are defined. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 > > --001a1148e560e2f9e0053f30f080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for reading and commenting.

I have look= ed at the minor typos for now, see inline

Working draft c= an be found here https= ://github.com/LudwigSeitz/ace-oauth

//Samuel

On Tue= , Oct 18, 2016 at 10:34 AM, Cigdem Sengul <cigdem.sengul@gmail.com> wrote:
<= div dir=3D"ltr">Hel= lo Ludwig,=C2=A0

Thanks for adding the new sections on requirements on= profiles and the examples in the appendix are quite useful too.=C2=A0
I list minor typos and request for = clarification/consistency below. Hope it helps.

Minor typos:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect on the AS= and
      receives information about t=
he access token contain in the
      response=E2=80=9D.=C2=A0
<=
font face=3D"arial, helvetica, sans-serif">      =
=3D=3D> Remove =E2=80=9Ccontain=E2=80=9D?

fixed
=C2=A0

Page 8/Section 3.2: "and also to su=
pport security for CoAP over
   different tran=
sport in a uniform way,=E2=80=9D 
      =3D=3D=
> =E2=80=9Cover a different transport=E2=80=9D
=

fixed
=C2=A0

Page 8/Section 4: " RFC 7744 [RFC7=
744] describes many different
   IoT use cases =
but there two preferred grant types=E2=80=9D
     =3D=3D>"there ar=
e two"

fixed
=C2=A0
Page 9/Section 4: "the OAuth client itself is constraint.  In such a =E2=80=
=9C 
        =3D=3D> =E2=80=9Cthe O=
Auth client itself is constrained.=E2=80=9D
=

fixed
=C2=A0

Page 9/Section 4: "which is often accomplished using
   an commissioning tool.=E2=
=80=9D 
    =3D=3D>  =E2=80=9Ca commissioning tool=E2=80=9D

fixed
= =C2=A0

Page 10/Section 4/Acc=
ess Token Response: "More
      information about these parame=
ters can be found in in Section 6.4.=E2=80=9D<=
/font>
    =3D=3D> Remove the second =E2=80=9Cin=E2=80=
=9D

fixed
=C2=A0
= 

Page 16/=
Section 6.2/AS-to-Client Response: "The content of the successful repl=
y MUST be encoded as CBOR map,
   containing paramters as specified &quo=
t;
    =3D=3D> =E2=80=9Cparamters=E2=80=9D typo

fixed
=C2=A0

Page 20/Figure 8/caption: &q=
uot;Confirmation parameter=E2=80=9D
      =3D=3D> typo in =E2=80=9Cparameter=E2=80=9D

fixed
=C2=A0
= 

Page 24/Just below Figure=
 14: "The client token is a CO=
SE_Encrytped object=E2=80=9D
    =
=3D=3D> typo in =E2=80=9CCOSE_Encrytped=E2=80=9D

fixed
=C2=A0

Page 26/Section 8: "same way as specified for the "c=
nf" parameter in section
   Section 6.4.5.=E2=80=9D =

=3D=
=3D> Remove duplicate =E2=80=9Csection=E2=80=9D

fixed
=C2=A0

Page 29/10.1/cnf=
 description: "Description: Key to use to prove the right to use an ac=
cess token,
      as defined in [RFC7800].=
=E2=80=9D
=3D=3D> Drop=
 the first =E2=80=9Cto use=E2=80=9D. =E2=80=9CKey to prove the right to use=
 an access token=E2=80=9D?

fixed
=C2=A0

Page 30/10.1/aud descriptio=
n: =E2=80=9CDescription: reference to"
=3D=3D> =E2=80=9Cr=E2=80=9D capital in reference

fixed
=C2=A0
= 

Page 30/10.1/prof=
ile description: =E2=80=9CThe communication and communication security prof=
ile=E2=80=9D
=3D=3D> =E2=80=9Ccommunication=E2=80=
=9D duplicate.
=
The profile will define both communication, e.g. COAP or HTT= P, and communication security, e.g. DTLS or COSE. So it might be useful tha= t this is called out
=C2=A0

=

Page 30/10.2/cnf: "Description: Key to use to prove the =
right to use=E2=80=9D
=3D=3D> Drop the first =E2=80=9Cto=
 use=E2=80=9D
<= br>
fixed
=C2=A0
= 

<=
pre class=3D"gmail-m_5821100162291734482gmail-m_-5027769899048254041gmail-n=
ewpage" style=3D"white-space:pre-wrap;margin-top:0px;margin-bottom:0px;page=
-break-before:always">Page 32/10.6.1/Profile description: =E2=80=9Cover view=E2=80=9D
=3D=3D> =E2=80=9Coverview"

fixed
= =C2=A0



Requests for clarification: 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

Page =
6/Access Token: "The access token is protected against modifications u=
sing a MAC or
<=
font face=3D"arial, helvetica, sans-serif">      a digital signature, which=
 is added by the AS=E2=80=9D

=

Question: Are access tokens also confidentiality protected=
 e.g., encrypted by the AS, to be consumed by RS?
It seems to be the case according to Page 9:
"Established keying material between the AS and the RS allows
   t=
he AS to apply cryptographic protection to the access token to
   ensure that its content cannot be modified, and if needed, that the
   content is confidentiality protected.=E2=80=9D

Page 11/Section 4/=
Token Introspection Response: "The AS can additionally
      return i=
nformation that the RS needs to pass on to the client in
      the form of a client token.  The latter is used to establish keys
      for mutual authentication between client and RS, when the client
      has no direct connectivity to the AS.=E2=80=9D

Question: The c=
lient still should have had an initial connectivity to the AS,=C2=A0=

and h=
as acquired an initial access token, right? This seems to be what is descri=
bed in Page 24. 

Page 15/Figure 4: 
=
Question: Is the grant_type in =
this example =E2=80=9Cclient_credentials=E2=80=9D or =E2=80=9Cpassword=E2=
=80=9D?

Page 17/Figure 5: 
Question: Shouldn=E2=80=99t the example =
contain the =E2=80=9Cprofile=E2=80=9D parameter, which was =E2=80=9CREQUIRE=
D=E2=80=9D in the response in the previous paragraphs.

<= pre class=3D"gmail-m_5821100162291734482gmail-m_-5027769899048254041gmail-m= _7881451645977060193gmail-m_-3770847762660526636gmail-newpage" style=3D"whi= te-space:pre-wrap;margin-top:0px;margin-bottom:0px;page-break-before:always= ;color:rgb(0,0,0)">Page 19/20/C= oSE_Encrypted:
Question: Is this confirmation parameter used when passing =
the key to the client as a response to POST to /token? Or is it used when p=
assing client token through RS? From Page 24, it seems to be former.=


<=
/font>
Page 27/Section 8.1:
&q=
uot;Profiles of this framework MAY define other
   methods for token transport.  Implementations conforming to this
   framework MUST implement this method of token transportation.=E2=80=9D
Question: Do you mean =E2=80=
=9Cthis framework=E2=80=9D or =E2=80=9Cthis draft=E2=80=9D. Just want to be=
 absolutely sure, that profiles MAY define other methods for token transpor=
t. 

Page 28/Section 9: &q=
uot;Using a single
   share=
d secret with multiple authorization server =E2=80=9C
Question: There is a type here. =E2=80=9CServer=
=E2=80=9D should be =E2=80=9Cservers=E2=80=9D but shouldn=E2=80=99t this be=
 =E2=80=9CResource servers=E2=80=9D?

Page =
44/Appendix B: =E2=80=9CResource Server=E2=80=9D
Question: Is introspection option excluded he=
re deliberately? =E2=80=9C The sentence: "Optionally: =
Check that the matching tokens are still valid (if this is possible.)=E2=80=9D Is=
 this the hint for the introspection?
Hope this helps,
--Cigdem Sengul
Senior Researcher
<= font face=3D"arial, helvetica, sans-serif">Nominet=C2=A0
=

On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seit= z <ludwig@sics.se> wrote:
Hello ACE,

we have uploaded a new version of our draft, addressing mainly the review c= omments from Renzo and adding a number of clarifications about the /token, = /introspect and /authz-info endpoints.

Please review this version and send us comments, if we get enough feeback w= e might be able to produce another version before the cut-off.


Regards,

Ludwig


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.tx= t
Date: Wed, 12 Oct 2016 04:35:28 -0700
From: interne= t-drafts@ietf.org
To: Ludwig Seitz <lu= dwig@sics.se>, Erik Wahlstroem <erik@wahlstromtekniska.se>, Goeran Sel= ander <= goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Hannes T= schofenig <hannes.tschofenig@arm.com>


A new version of I-D, draft-ietf-ace-oauth-authz-03.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ace-oauth-authz Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication and Authorization f= or Constrained Environments (ACE)
Document date:=C2=A0 2016-10-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ace
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56
URL: https://www.ietf.org/inte= rnet-drafts/draft-ietf-ace-oauth-authz-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-ietf-ace-oauth-authz-03
Diff: https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-ace-oauth-authz-03

Abstract:
=C2=A0 =C2=A0This specification defines a framework for authentication and<= br> =C2=A0 =C2=A0authorization in Internet of Things (IoT) environments.=C2=A0 = The
=C2=A0 =C2=A0framework is based on a set of building blocks including OAuth= 2.0
=C2=A0 =C2=A0and CoAP, thus making a well-known and widely used authorizati= on
=C2=A0 =C2=A0solution suitable for IoT devices.=C2=A0 Existing specificatio= ns are used
=C2=A0 =C2=A0where possible, but where the constraints of IoT devices requi= re it,
=C2=A0 =C2=A0extensions are added and profiles are defined.




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.

The IETF Secretariat



_______________________________= ________________
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


--001a1148e560e2f9e0053f30f080-- From nobody Fri Oct 21 16:27:35 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 BDF7F1298AA; Fri, 21 Oct 2016 16:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208177.28214.860366242598129343.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:21 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, ace@ietf.org Subject: [Ace] ace - Requested session has been scheduled for IETF 97 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:26 -0000 Dear Kepeng Li, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (2:30:00) Thursday, Afternoon Session II 1520-1750 Room Name: Studio 4 size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: core cose oauth saag lwig tokbind tls Special Requests: Avoid entire SEC areas. Please avoid a session on Friday! --------------------------------------------------------- From nobody Fri Oct 21 21:05:56 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DFB129404; Fri, 21 Oct 2016 21:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 A9CcVcgwebIW; Fri, 21 Oct 2016 21:05:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42E51293EB; Fri, 21 Oct 2016 21:05:50 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 21:22:00 -0700 From: Jim Schaad To: Date: Fri, 21 Oct 2016 21:05:43 -0700 Message-ID: <094701d22c19$90a85080$b1f8f180$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdIsGQ6xrMV4HlIeTVOu0qkLobOURg== X-Originating-IP: [24.21.96.37] Archived-At: Cc: ace@ietf.org Subject: [Ace] question about wrong types X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 22 Oct 2016 04:05:55 -0000 What is the correct behavior if the type of a value is incorrect? Is the CWT to be rejected or is it optional for the application if it is rejected. As an example, what happens if the "iat" claim name is associated with a CBOR Type 0 instead of using the Tag #6.1 in front of the type 0 value. Jim From nobody Sat Oct 22 01:45:59 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C58129440; Sat, 22 Oct 2016 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.699, RCVD_IN_DNSWL_MED=-2.3] autolearn=no autolearn_force=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 IkVMbQZK5nb9; Sat, 22 Oct 2016 01:45:30 -0700 (PDT) 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 C06D41293D6; Sat, 22 Oct 2016 01:45:29 -0700 (PDT) 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 u9M8jOf9021213; Sat, 22 Oct 2016 10:45:24 +0200 (CEST) Received: from client-0074.vpn.uni-bremen.de.mail (client-0074.vpn.uni-bremen.de [134.102.107.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3t1GMX3vQYz7xR8; Sat, 22 Oct 2016 10:45:11 +0200 (CEST) Date: Sat, 22 Oct 2016 10:42:20 +0200 From: Carsten Bormann To: cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org, ace@ietf.org, core@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Airmail (390) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="580b270a_37ba36b9_ff73" Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF97: FINAL AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 22 Oct 2016 08:45:33 -0000 --580b270a_37ba36b9_ff73 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is my usual eclectic condensed agenda based on the =22=46INAL=22 AGE= NDA for IET=4697. =C2=A0(=22=46INAL=22 historically has not always been =22fi= nal=22...) Not many changes; TOKBIND, OAUTH, CURDLE moved around, and the big clashing cluster on =46riday morning has become bigger with another TLS session. =C2=A0(I previously wrote: IoT is starting a bit late at IET=469= 7; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). =C2=A0CORE on HOMEN= ET and IPWAVE (Wed) and CORE on ICNRG (=46ri) are a bit painful but probably the unavoidable level of conflict.) All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, November 13, 2016 1300-1600 =C2=A0 =C2=A0 =C2=A0 IRT=46*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 ART dispatch Dispatch WG - 09:30-11:00 Studio 3 SEC oauth Web Authorization Protocol WG 1330-1530 =C2=A0Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRT=46 cfrg Crypto =46orum Grand BR 2 OPS v6ops IPv6 Operations WG 1550-1750 =C2=A0Afternoon Session II Grand BR 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG Studio 4 SEC tokbind Token Binding WG TUESDAY, November 15, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR 1 TSV quic QUIC WG 1330-1530 =C2=A0Afternoon Session I Park BR 2 ART httpbis Hypertext Transfer Protocol WG Grand BR 2 RTG rtgarea Routing Area Open Meeting Park BR 1 TSV tsvwg Transport Area Working Group WG 1550-1820 =C2=A0Afternoon Session II Grand BR 2 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes W= G Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 =C2=A0Morning Session I Grand BR 3 OPS anima Autonomic Networking Integrated Model and Approach W= G Grand BR 2 TSV taps Transport Services WG 1110-1210 =C2=A0Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR 1 TSV tsvwg Transport Area Working Group WG 1330-1500 =C2=A0Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 1 INT homenet Home Networking WG Grand BR 3 INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR 2 TSV tsvarea Transport Area Open Meeting 1520-1620 =C2=A0Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRT=46*** t2trg Thing-to-Thing Studio 3 SEC oauth Web Authorization Protocol WG THURSDAY, November 17, 2016 0930-1100 =C2=A0Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery =C2=A0WG= Grand BR 2 IRT=46 maprg Measurement and Analysis for Protocols Grand BR 1 SEC saag Security Area Open Meeting 1110-1210 =C2=A0Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR 3 INT *** lwig Light-Weight Implementation Guidance WG Grand BR 1 SEC saag Security Area Open Meeting 1520-1750 =C2=A0Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Env= ironments WG Studio 3 TSV rmcat RTP Media Congestion Avoidance Techniques WG =46RIDAY, November 18, 2016 0930-1130 =C2=A0Morning Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 3 IRT=46 icnrg Information-Centric Networking Park BR 2 OPS anima Autonomic Networking Integrated Model and Approach WG= Grand BR 2 SEC tls Transport Layer Security WG Studio 4 TSV tcpinc TCP Increased Security WG 1150-1320 =C2=A0Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Studio 4 ART webpush Web-Based Push Notifications WG Park BR 2 RTG babel Babel routing protocol WG Park BR 1 RTG babel Babel routing protocol WG Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG --580b270a_37ba36b9_ff73 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline