From nobody Wed Aug 8 03:55:28 2018 Return-Path: <172211004@nitdelhi.ac.in> 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 89E2E130DE9 for ; Wed, 8 Aug 2018 03:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nitdelhi-ac-in.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 KNkFEtQgPk29 for ; Wed, 8 Aug 2018 03:55:23 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 C46D6126CB6 for ; Wed, 8 Aug 2018 03:55:22 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id d10-v6so2855863itj.5 for ; Wed, 08 Aug 2018 03:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nitdelhi-ac-in.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=P04K06/8GxUxky3FfL6r272NI+ODuL25RSpfZCrY8Eo=; b=yOzpmg5IHttoWN13u7FiqXYOsQzIqZAv0B9ciZCi2Iga5myfWl94iIRkp6OsGU5x0t jeIGp9jHRBR+binCtZJYOo+R5GCYRrO2PnSTXCSsKdIuQnVxOTfrgl2yDSHMW8auQnr6 u+tXnIGCZGokprhDIZK6An+dI0YwMmCZgQkgY4ID8AC+6w2glZGcHrkAZWTmkrJMLiRn RncsJDP+CbYHVx0BfTy/dWzw6mgWl9NFhir+65F23lRk/ERbv3YHvb/e3r2tOu8M3XBt gpEI8EG9vQKCVRBmmNTnoWETvoSpyKxwkShMK5ZaMxBxodTalsoLWjkMcBb0RigQXx3R U/CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P04K06/8GxUxky3FfL6r272NI+ODuL25RSpfZCrY8Eo=; b=tzGrsGeL+n/sggGHJ3tp1FrNhvymdcqpM9royNoeShOfI+Wv/snLBlXwE8xstNC+aA FKajfSyCt7rvPzTCcr8CL1cx/e9x5d9jCAcHYMMJTQ5s0gcqMX73X1CDXAw9MYKX69pu jmiJhzrkOMEN0VY3kVF5DafkyZpof2+eLVquCeKg6IGRWsLp4BiacL/pgym1wH0DGwOU DofV5bFHmLf31zH8l5W0RBs2Y4g8okaIqKNj7t5EdH6fP4HjbnNcwEmm+rjCZl/TcgYA kHUBRbrZtAr0ZFw44elsbeJ0JT4h0WE/EGrpj4nAWQNiqJBkexVh54ZY/1jr8drcHl0r BMRw== X-Gm-Message-State: AOUpUlGASkHzLh01Kb5IBaKfgD/TjSnqIwY7KQXx7WacpCYCFvZc8eyi KDXouCrzINYVt9kLF5NamFztGoLJ5GEnZW/ZFiRIl2pG944= X-Google-Smtp-Source: AA+uWPz5kQ5jYTFBC9fdj2E8z1V4myrixIicZ9RW6RiWGJe9GuLJEFtjhSX+L1PDjgo0NtATawKk+t3Ku4Ruwwm6XfE= X-Received: by 2002:a24:f5c2:: with SMTP id k185-v6mr1834638ith.106.1533725721431; Wed, 08 Aug 2018 03:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:1d89:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 03:55:20 -0700 (PDT) From: FARAZ AHMAD NAQSHBANDI <172211004@nitdelhi.ac.in> Date: Wed, 8 Aug 2018 16:25:20 +0530 Message-ID: To: ace@ietf.org Content-Type: multipart/mixed; boundary="000000000000cf551e0572ea5877" Archived-At: Subject: [Ace] Regarding draft Status. X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 08 Aug 2018 10:55:27 -0000 --000000000000cf551e0572ea5877 Content-Type: multipart/alternative; boundary="000000000000cf55180572ea5875" --000000000000cf55180572ea5875 Content-Type: text/plain; charset="UTF-8" Respected Sir/Ma'am, I have submitted a draft on your portal on July 25, 2018. It has not been posted yet and the status is showing "Awaiting for manual posting". I would be very grateful if you can let me know the problem in the draft so that I can amend and upload it back. The details for the draft are: Draft Name: draft-ietf-aaa-naqshbandi-hafc-00.txt Author: Faraz Naqshbandi For further reference, I am attaching the draft. Regards, Faraz Naqshbandi M. Tech Scholar NIT Delhi --000000000000cf55180572ea5875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Respected Sir/Ma'am,

I have submitted a draft on your portal on July 25, 2018. It has not been= posted yet and the status is showing "Awaiting for manual posting&quo= t;. I would be very grateful if you can let me know the problem in the draf= t so that I can amend and upload it back.

The deta= ils for the draft are:

Draft Name: draft-ietf-aaa-= naqshbandi-hafc-00.txt
Author: Faraz Naqshbandi
For further reference, I am attaching the draft.

Regards,
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 883C5130DFA; Fri, 10 Aug 2018 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 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, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=dgiFJ0zp; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=hwagI1Ni 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 Fm7urdB3u93X; Fri, 10 Aug 2018 02:09:41 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 D49841271FF; Fri, 10 Aug 2018 02:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1533892180; x=1565428180; h=from:to:cc:subject:date:message-id:mime-version; bh=+7+WvCuI99hzfwQSeD2JO/hAanz+Eqa7cyM18T/HoHw=; b=dgiFJ0zpHXHBWVpcBtybVjzp+0g7aPEQsrzkS1hJYMG0562aR+kkZtZ2 tR4In3Dka5nMzm86UHmAjuJuWxsye6fq6N09qat7g7icLzJ40XHMOkD+V 7rSzVSjC2a1Y72ngAXe30cepLN2MlV96csrvfqz6IPmFrqB0rAxLP13Jv cY5ywtBBSWkxv83zs2EUCW7zmea+i95f0o2ciyGbPRQjVB25l6DHoRDZQ KE8P6FIgTXPLTLDoW2RIxNI6djWi53dqt66ITcXpJC/6kgl3VHCsoTXYW hW0YVjYNnsOjxwCrEfyHAyt9ux3XLWx4ZBaSjV/CCE+HUnf+l2kxMujOV Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2018 11:09:37 +0200 X-IronPort-AV: E=Sophos;i="5.53,218,1531778400"; d="scan'208,217";a="230450542" Received: from he106140.emea1.cds.t-internal.com ([10.169.119.73]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 10 Aug 2018 11:09:36 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE106140.emea1.cds.t-internal.com (10.169.119.73) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 Aug 2018 11:09:35 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105660.EMEA1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 10 Aug 2018 11:09:35 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Aug 2018 11:09:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+7+WvCuI99hzfwQSeD2JO/hAanz+Eqa7cyM18T/HoHw=; b=hwagI1NieAZctjXqamuM6odgVsfdV6LdUlRWVRCNvEWLkFWmQxzF3kptGlccKD6OZZEwvhxvjDvf0R0Q5JOEccgySjQV3d7hHuUHSLeCKzVR4srpSFlPRU6042iSSxwx1rxSolgsdiqPmxbU3B3sdBXZ6voZ7yB4A++ruUvSsz0= Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Fri, 10 Aug 2018 09:09:35 +0000 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::fcbe:870:6cd7:64a9]) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::fcbe:870:6cd7:64a9%6]) with mapi id 15.20.1017.021; Fri, 10 Aug 2018 09:09:35 +0000 From: To: , CC: Thread-Topic: RE: New Non-WG Mailing List: PidLoc Thread-Index: AdQwic7AoWE8f/KMTKCsEcfgKX56nw== Date: Fri, 10 Aug 2018 09:09:34 +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=Dirk.von-Hugo@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0801; 6:59sDywcQhLkKcMYiWO82/lcynx943mCiYuc2rgbjSw7To1I97oEhaXQWEF6VASiJ6hVQHHzO9gRK7aq7in8pm8beyfJHUjubBYkDVJ+8vnReO5bIZZ2sgANxs3uSKLh01+NU08lPFL4xznqZlyttYunBuXJDcIKb4op8T6AbqTIyJN6yiUi9+p9sFINLaUj6kPywPw0cWRD39U6qAtrzAWOKoCPyJYkjL+W7FEwdUHkc1rCPpfjXZld/y09192E3HaO14lTslJFScjkSfeRQDuukaF7cm5ag8mstcdOOW8wLRVeKOf/tsCDSFswsi2DZA9E3iZz4JhMEEecL2e24OpGmL6PBAQgT88k3QaZSAascK/WzG1yvOBzHGS4uYJfuW7m3fnq34FsHOorKcatxOnUYjmRCXvQMXYJiK/r5etaXz29swQSYHc+Yp4NqxZ979gC2waSY+rXeNpeLbjWH8g==; 5:w1E9jyMkgVNmCfFUD5vp+SaaUgWXlezjMPDlUlPs4R8uW8OagtbG3aHNY3UNwND9AUffugL/PBO8CXZwW2eMz3vWa4lbEGxmO6VjxfC9qee7+9/YKWtrgX7yisyEn//ll7bPMJbUrHQgHUSb2+VJw76VWwBK3bB+etCGh2JcIig=; 7:TdKALddClhBksTXUWjx5bc7Qw66RWEivSJGSLmlbtcbuX+aSMPGnIeFhcoLUEGE3KVtUveGDci2kieY0/uFcCFH2IjhmS2qeDPYNj8AXmLiCShp5VxBQjoIvEMBnZli/E5l3PeUgxSquqBVEBdvUCXAdhnTWAZydYJbVHI3c40jyh0/+0V4pOY2E3TsLu3xnvv0wpcJ6rdIjxLVYPZXWfTJzoGgHbyQBCCMCVyDV/3wxWdq6Ymjk2XIZYeB3HQrj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 24de74b7-ca9b-4b14-65dd-08d5fea0fde0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0801; x-ms-traffictypediagnostic: FRAPR01MB0801: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(85827821059158)(260130700054247)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0801; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0801; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39860400002)(346002)(376002)(199004)(189003)(22974007)(4326008)(256004)(14444005)(5660300001)(86362001)(66066001)(6246003)(55016002)(316002)(236005)(74482002)(53936002)(486006)(2900100001)(6116002)(790700001)(68736007)(3846002)(75402003)(26005)(102836004)(476003)(81166006)(81156014)(53546011)(8676002)(186003)(52396003)(33656002)(478600001)(7736002)(97736004)(106356001)(9686003)(105586002)(14454004)(606006)(8936002)(2501003)(7696005)(966005)(229853002)(110136005)(5250100002)(72206003)(6306002)(54896002)(2906002)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0801; H:FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: OeggtkwIthWLrA+6BqPihpSWLYJrn7PpL8QfwGnS5omt6LYEQMsG63E8PzFOxLphrMeEkpY+XbCMv5HEaPYvAnwa9Ww3zig5+f1CEgCd4SOkEuqY/Mqoh38GcD4zKLZuv/NjwAJZDsY77I0atwnLR23lKDGadEFWl9IJ+wzo8vCMxjebKIAtP8jqjebTeiA8Iuremy6j4KfRTnAujS1h2teLlMIzQJyXwnpFFj2lEDMIkAdupFBswHlVGYMEL8K/C7fiMvRU8zwbWuoiiyWILABrLzsA/JPbl6WfG/qitndbjbf/mXnecHAlQZehuocLRNUgYf8EAeIylVeoTpDo/aX4/fdnWvvEi8b3FLQbjHg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB08013E52744D77C83F5EB5ADD1240FRAPR01MB0801DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 24de74b7-ca9b-4b14-65dd-08d5fea0fde0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 09:09:34.9576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0801 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Ace] New Non-WG Mailing List: PidLoc X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 09:09:44 -0000 --_000_FRAPR01MB08013E52744D77C83F5EB5ADD1240FRAPR01MB0801DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ACE chairs: please approve this non-member post, thanks. Since in your WG you deal with standardized solution for authentication and= authorization to enable authorized access we think this new discussion lis= t on location and identifier privacy may be of interest to you! Thanks! Best regards - also on behalf of Behcet Dirk ---------- Forwarded message ---------- From: IETF Secretariat > Date: Fri, Jul 27, 2018 at 3:32 PM Subject: New Non-WG Mailing List: PidLoc To: IETF Announcement List > Cc: PIdLoc@ietf.org, Dirk.von-Hugo@telekom.de, sarikaya2012@gmail.com A new IETF non-working group email list has been created. List address: PIdLoc@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/pidloc/ To subscribe: https://www.ietf.org/mailman/listinfo/pidloc Purpose: In IdLoc protocols like LISP, ILA, etc. separation between (fixed) Identi= fier and (dynamic) Location is proposed to find optimum path for data packe= ts to/from moving devices The threats against privacy in IdLoc protocols include location privacy where if a third party can at any time determine the IP lo= cation of some identifier, then the device can at one point be IP geolocate= d and movement privacy where if a third party can determine that an identifier ha= s changed locator(s) at time T, then even without knowing the particular lo= cators before and after, it can correlate this movement event with other in= formation to create a binding between the identifier and a person. Privacy and security work is needed both in control and data plane There is an existing draft https://www.ietf.org/id/draft-nordmark-id-loc-pr= ivacy-00.txt that is expected to serve as a starting point. The work is expected to clear the way for a wider acceptance/deployment of = IdLoc protocol. This may open new application areas such as in future mobil= e networks. In future mobile networks more efficient differentiation of packet handling= according to specific service demands (QoS) are expected. Traditional tunn= eling and encapsulation between IP addresses (=3D Id and/or Loc) have disad= vantages --_000_FRAPR01MB08013E52744D77C83F5EB5ADD1240FRAPR01MB0801DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ACE chairs: please approve this= non-member post, thanks.

Since in your WG you deal with stand= ardized solution for authentication and authorization to enable authorized access we think this new discussion list on location = and identifier privacy may be of interest to you!

Thanks!

Best regards - also on behalf of Beh= cet

Dirk

---------- Forwarded message ----------
From: IETF Secretariat <ietf-secretariat@ietf.org= >
Date: Fri, Jul 27, 2018 at 3:32 PM
Subject: New Non-WG Mailing List: PidLoc
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: PIdLoc@ietf.org, Dirk.von-Hugo@telekom.de, sarikaya2012@gmail.com


A new IETF non-working group email list has been created.

List address: <= span lang=3D"EN-US">PIdLoc@ietf.org
Archive: https://mailarchive.ietf.org/arch/= browse/pidloc/
To subscribe: https://www.ietf.org/mailman/list= info/pidloc

Purpose:
 In IdLoc protocols like LISP, ILA, etc.  separation between (fix= ed) Identifier and (dynamic) Location is proposed to find optimum path f= or data packets to/from moving devices

The threats against privacy in IdLoc protocols include

location privacy where if a third party can at any time determine the IP location of some identifier, then the device can at one point be IP<= span style=3D"color:#1F497D"> geolocated and

movement privacy where if a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the particular locators before and = after, it can correlate this movement event with other information to create a binding between the identifier and a person.=

Privacy and security work is needed both in control and data plane

There is an existing draft https://www.ietf.org/i= d/draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a starting point.

The work is expected to clear the way for a wider acceptance/deployment of IdLoc protocol. This may open new application areas such as in fu= ture mobile networks.

In future mobile networks more efficient differentiation of packet handling according to specific service demands (QoS) are expected. T= raditional tunneling and encapsulation between IP addresses (=3D Id and/or Loc)= have disadvantages=

 

--_000_FRAPR01MB08013E52744D77C83F5EB5ADD1240FRAPR01MB0801DEUP_-- From nobody Tue Aug 14 21:59:00 2018 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 1ECE9130E66 for ; Tue, 14 Aug 2018 21:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 MOzMSxzuzD04 for ; Tue, 14 Aug 2018 21:58:56 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::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 4745B1271FF for ; Tue, 14 Aug 2018 21:58:55 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id j8-v6so33887pll.12 for ; Tue, 14 Aug 2018 21:58:55 -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=TpIovC9GU5UxPS7QEvzSRSu0kGIICavM/k+OWPfhC5A=; b=mnHP0gRm5gwMfO19LmdzG7m5CeuTO/0HCWk6zN2Sah9S249fa0ESxS+OhPEX/iXa03 bLDw4HAhqmmZpFLMXRZPGNJUeozbWWqJH8G5fLAvqv8YUIxMwSQgBN9rpRXuPWSnjW9q Q26cbg6DQVvyu4Sw4GU+6k6xWhanvRYLT+R/9rLh8auCut8gzhC7bs6TuxXJ2E/e1jWJ ry4qQZE3d3mdEE6f2Sdp8s52O2FnFqXuLuFFpb9v6sF1YzkMyKBN5pMXstrJ7Ydh8wfu pJ5Zl2if1M5c5ocOmXJocgHQRH+1gio1ZuN6iSkZYuD4VOJuxDAFN7gtG1U0wxwqllga uRQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TpIovC9GU5UxPS7QEvzSRSu0kGIICavM/k+OWPfhC5A=; b=Bh8qHKmEkgUJWzeC24vuvji7TtpUY3L3DxzncV/wV3v3U+T5KihLKR333nsoTMJ7Lh R8AtQAM0RbbVM80U+k4rE8zDtGPP5Ccv5ZVLvISUmzgpcEyMdA1khNwUtuG4NSLbXW4u OQPjmoCT5MmrKDqeZ2CDtTTAz7cbawKtkPDyWXMZDwSljjjHQMoVle01Zl/Y6ReATHJs 1IBl8MgmmyVSFhMd0IU1jLZntr4Fe8SgD9zng2kXR6ZuM2FauVIJ9O1e6jcDwh6mxida oJ9YtBHV1HpR2AtzDoq9lhHzcglwmmikAaBMSaOrVc73bjnj0g7xtg8h3NEFL9wXRpGt vIQA== X-Gm-Message-State: AOUpUlEPxUDTJs2ikK4pTK4BC7lNR/rtP/gp464PF8i03DgI4yky7X5z d0j+M4sA5Un4rgUk8RhK+RBTK9nXE80iAzFy5Wb+UOLJXElI8g== X-Google-Smtp-Source: AA+uWPzzBMiYEn2mtBeAROjxNWvSKOXZWaQF7KKVH54Rvy3V1Kq6SOQn0aPOLfqi6/Bs5P3vig1JEV3Fi717uNh6btQ= X-Received: by 2002:a17:902:7845:: with SMTP id e5-v6mr22449306pln.197.1534309135399; Tue, 14 Aug 2018 21:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:a109:0:0:0:0 with HTTP; Tue, 14 Aug 2018 21:58:54 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Wed, 15 Aug 2018 06:58:54 +0200 Message-ID: To: Hannes Tschofenig Cc: oauth , "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fdd4570573722e4f" Archived-At: Subject: Re: [Ace] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 15 Aug 2018 04:58:59 -0000 --000000000000fdd4570573722e4f Content-Type: text/plain; charset="UTF-8" Hi Hannes, Has there been any updates to draft-ietf-oauth-pop-key-distribution? I could not find any updated document. Best regards //Samuel On Fri, Jul 20, 2018 at 7:46 PM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > after several discussions we believe that we now have a proposal for > moving forward on this topic. > > We plan to update the expired draft > and > > (1) remove the audience parameter and replace it with a > separately-specified resource parameter, > > (2) remove the alg parameter, > > (3) update the procedures for requesting and obtaining keying material, > > (4) Synchronize with the ACE and WebRTC work to make sure that their use > cases are appropriately covered. > > > > Regarding (1): The meeting participants have decided to standardize an > audience-alike parameter (in the form of a requested resource identifier) > at this weeks IETF OAuth meeting. For that purpose, working group adoption > of draft-campbell-oauth-resource-indicators is under way. Only a > reference to that document will be needed. > > > > Regarding (2): Removal of the alg parameter will simplify the document and > does not appear to be necessary for the currently investigated use cases. > This assumption will have to be verified. > > > > Regarding (3): Currently, the ACE-OAuth document and the > use different parameter names. > Furthermore, those parameter names may be in conflict with other, already > standardized parameter names. Hence, some parameters may need to be > renamed. The plan is to focus on the following, minimal functionality only: > server-side symmetric key generation and client-side public key > registration to the AS. Furthermore, the encoding of the key transport will > have to take the different token formats and protocols into account. > > > > This approach will allow the ACE and WebRTC work to reference the generic > PoP key distribution document without having to specify their own duplicate > functionality. > > > > We are planning to update next > week to have something to review. > > > > Ciao > > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --000000000000fdd4570573722e4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

Has there been an= y updates to draft-ietf-oauth-pop-key-distribution? I could not find a= ny updated document.

Best regards
//Samu= el

On Fri, Jul 20, 2018 at 7:46 PM, Hannes Tschofenig <<= a href=3D"mailto:Hannes.Tschofenig@arm.com" target=3D"_blank">Hannes.Tschof= enig@arm.com> wrote:

Hi all,

=C2=A0

after several discussions we believe that we now hav= e a proposal for moving forward on this topic.

We plan to update the expired draft <draft-ietf-o= auth-pop-key-distribution-03> and

(1) remove the audience parameter and replace it wit= h a separately-specified resource parameter,

(2) remove the alg parameter,

(3) update the procedures for requesting and obtaini= ng keying material,

(4) Synchronize with the ACE and WebRTC work to make= sure that their use cases are appropriately covered.

=C2=A0

Regarding (1): The meeting participants have decided= to standardize an audience-alike parameter (in the form of a requested res= ource identifier) at this weeks IETF OAuth meeting. For that purpose, worki= ng group adoption of draft-campbell-oauth-resource-indicators is under way.=C2=A0 Only a reference to that document will be needed.=C2= =A0

=C2=A0

Regarding (2): Removal of the alg parameter will sim= plify the document and does not appear to be necessary for the currently in= vestigated use cases. This assumption will have to be verified.

=C2=A0

Regarding (3): Currently, the ACE-OAuth document and= the <draft-ietf-oauth-pop-key-distribution-03> use different pa= rameter names. Furthermore, those parameter names may be in conflict with o= ther, already standardized parameter names. Hence, some parameters may need to be renamed. The plan is to focus on the follow= ing, minimal functionality only: server-side symmetric key generation and c= lient-side public key registration to the AS. Furthermore, the encoding of = the key transport will have to take the different token formats and protocols into account.

=C2=A0

This approach will allow the ACE and WebRTC work to = reference the generic PoP key distribution document without having to speci= fy their own duplicate functionality.

=C2=A0

We are planning to update <draft-ietf-oauth-pop-k= ey-distribution-03> next week to have something to review.

=C2=A0

Ciao

Hannes & Rifaat

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

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


--000000000000fdd4570573722e4f-- From nobody Mon Aug 27 00:52:11 2018 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 0E2A4130DF3 for ; Mon, 27 Aug 2018 00:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 GT6IRtN_1B2i for ; Mon, 27 Aug 2018 00:52:06 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.41]) (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 763D1129C6B for ; Mon, 27 Aug 2018 00:52:06 -0700 (PDT) Received: from 1fuCJg-000jGz-T7 by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fuCJg-000jIU-Tj for ace@ietf.org; Mon, 27 Aug 2018 00:52:04 -0700 Received: by emcmailer; Mon, 27 Aug 2018 00:52:04 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fuCJg-000jGz-T7 for ace@ietf.org; Mon, 27 Aug 2018 00:52:04 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 27 Aug 2018 09:52:03 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Mon, 27 Aug 2018 09:52:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 07:52:10 -0000 Hello group, at IETF 102 there was a discussion about the numerical abbreviations we introduced for both OAuth parameter names and access token claim names. I have generated a proposal that makes better use of the number space, but I'd like the OAuth specialists to have a look at it and see if I pushed any important (= frequently used) OAuth parameter into the two byte number range. Background: CBOR integers have a very compact representation (1 byte) for numbers from 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes. Thus we'd like to use abbreviations in the first number range for parameters/claims that are frequently used. My proposal follow below, please feel free to comment. /Ludwig ================================================================================ Existing claim name abbreviations from RFC 8392 (CWT) : iss 1 sub 2 aud 3 exp 4 nbf 5 iat 6 cti 7 New claim name abbreviation introduced by draft-ietf-ace-cwt-proof-of-possession: cnf 8 New claims introduced by draft-ietf-ace-oauth-authz (with proposed abbreviations): scope 9 profile 10 rs_cnf 11 Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed abbreviations): scope 9 error 12 grant_type 13 access_token 14 token_type 15 client_id 24 client_secret 25 response_type 26 state 27 redirect_uri 28 error_description 29 error_uri 30 code 31 expires_in 32 username 33 password 34 refresh_token 35 New token endpoint parameters introduced by draft-ietf-ace-oauth-authz (with proposed abbreviations): req_aud 16 req_cnf 17 used_cnf 18 rs_cnf 19 (Note that req_* and used_cnf are not yet in the draft, but we came to the conclusion we will need them after the OAuth session at IETF 102. They will be in the next update) Introspection endpoint paramenters from RFC (OAuth 2.0 introspection) (with proposed abbreviations): iss 1 sub 2 aud 3 exp 4 iat 6 nbf 5 scope 9 token_type 15 active 20 client_id 24 username 33 jti (no abbreviation, we have cti) New introspection endpoint parameters introduced by draft-ietf-ace-oauth-authz: cnf 8 rs_cnf 19 profile 10 -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Aug 27 09:20:03 2018 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 86634130E07 for ; Mon, 27 Aug 2018 09:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 tM9eFyw5DFYl for ; Mon, 27 Aug 2018 09:20:00 -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 5723C130E06 for ; Mon, 27 Aug 2018 09:20:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 27 Aug 2018 09:16:06 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: In-Reply-To: Date: Mon, 27 Aug 2018 09:19:51 -0700 Message-ID: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGmsbrlMYcGK1pU4ekVFpBcUUSxNqUu33Rw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 16:20:03 -0000 > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, August 27, 2018 12:52 AM > To: ace@ietf.org > Subject: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth- > authz > > Hello group, > > at IETF 102 there was a discussion about the numerical abbreviations we > introduced for both OAuth parameter names and access token claim names. > > I have generated a proposal that makes better use of the number space, but I'd > like the OAuth specialists to have a look at it and see if I pushed any important > (= frequently used) OAuth parameter into the two byte number range. > > > Background: > > CBOR integers have a very compact representation (1 byte) for numbers from > 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes. Thus > we'd like to use abbreviations in the first number range for parameters/claims > that are frequently used. > > My proposal follow below, please feel free to comment. > > > /Ludwig > ================================================================ > ================ > > > Existing claim name abbreviations from RFC 8392 (CWT) : > iss 1 > sub 2 > aud 3 > exp 4 > nbf 5 > iat 6 > cti 7 > > New claim name abbreviation introduced by > draft-ietf-ace-cwt-proof-of-possession: > > cnf 8 > > New claims introduced by draft-ietf-ace-oauth-authz (with proposed > abbreviations): > > scope 9 > profile 10 > rs_cnf 11 > > Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed > abbreviations): > > scope 9 > error 12 > grant_type 13 > access_token 14 > token_type 15 > > client_id 24 > client_secret 25 > response_type 26 > state 27 > redirect_uri 28 > error_description 29 > error_uri 30 > code 31 > expires_in 32 > username 33 > password 34 > refresh_token 35 [JLS] I would be willing to push error_description and error_uri up into the two byte range I don't think they fall into the frequently used category in a working system. I don't know that we need to keep client_id, client_secret, username and password in the low range at this time. Do we really think that we are going to be using this on small devices? > > New token endpoint parameters introduced by draft-ietf-ace-oauth-authz (with > proposed abbreviations): > > req_aud 16 > req_cnf 17 > used_cnf 18 > rs_cnf 19 > > (Note that req_* and used_cnf are not yet in the draft, but we came to the > conclusion we will need them after the OAuth session at IETF 102. > They will be in the next update) > > Introspection endpoint paramenters from RFC (OAuth 2.0 introspection) (with > proposed abbreviations): > > iss 1 > sub 2 > aud 3 > exp 4 > iat 6 > nbf 5 > scope 9 > token_type 15 > active 20 > client_id 24 > username 33 > jti (no abbreviation, we have cti) > > > > New introspection endpoint parameters introduced by > draft-ietf-ace-oauth-authz: > > cnf 8 > rs_cnf 19 > profile 10 > > > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Aug 27 09:39:18 2018 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 A9852130E1B for ; Mon, 27 Aug 2018 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 ArYomR3bevY3 for ; Mon, 27 Aug 2018 09:39:13 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 BAD79130E14 for ; Mon, 27 Aug 2018 09:39:13 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id v66-v6so7671647pgb.10 for ; Mon, 27 Aug 2018 09:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jyZsbKWmC+Bzgak0427Uvv001fgq+0NpCSFjJ6w299U=; b=CSXSbAX33YBirudUbF2t4qE1QuNF290bhbcTbTVckAyHC2qCuyTdL8/98V7GGebwH+ 8tOXK4LKMHmhtlOZZMGof5oBCkj2y1aGrnXe3M/Kb67cj7SYP0M4Ji/CtT4xI3LF94Dj q3s+qoYXPS9cNFi+JYk3K3bL+k8wRUPQry3q2db8snzgHsVxx4Iu4EqXRKh3lbEpC4gF gdpXEsvT7TAGhCT+2qu8o7vXvFEhCCZl9sSzXcWPhCBBgnu/CfdT+p40jw0SDezuapw7 QR5ngn13113Ly/u0CpTxtWFR7eSycJbUaGFC90Sp7b+/PYzG7+GqhPdTgZCH1kUi7gBP nbJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jyZsbKWmC+Bzgak0427Uvv001fgq+0NpCSFjJ6w299U=; b=BWuRTAcAIVXLOhIajzUKTgUS/CU2AZfyIzuReX2wtUDnohHvdOiKqf1lguMDK2nnB/ Wsy52MflDn1lm+wWcw02UQMqs4O4QXItDfKL74AHDSQD3ZbaoMi0NthygRPPHZGMSSZc adWzCE1U6+OHJsYAuiU3W+TVQoX3x0+pylu5WUq3cH3jybwD586zUZ1pG903ZX4mtSq6 SaG8MDyPgH/dS6TeYXF2bWKfEREjPlRA4hF8LJ9yHAjIvyVjgnpqqwr4IB8m4rVCWUmu CN+1RJJGnWLsqVVLmNAbQtQR07oquWEUlBxEmABh/gmmK84VcY4oCplbiRLus8fbm2Dv Eq/w== X-Gm-Message-State: APzg51Dw/u7csZx6J5fWR8eYFJyiyCDjbJvZM00aPrMe5ZtiG1xB3C6i 9ht+jaZTVu1j/H5W99QFw2HZ9ZpnakNzWOw9G2oTrGst X-Google-Smtp-Source: ANB0VdY+c+ir3NXRv0pKMoUhduNv14TweNMiHAcWsXxEAnGvimpDqDxXw9FGu3XeP/1/2vC48UHHBpCjtmwXv8MZN/A= X-Received: by 2002:a63:1a61:: with SMTP id a33-v6mr13127068pgm.9.1535387953106; Mon, 27 Aug 2018 09:39:13 -0700 (PDT) MIME-Version: 1.0 References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> In-Reply-To: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> From: Samuel Erdtman Date: Mon, 27 Aug 2018 18:39:02 +0200 Message-ID: To: Jim Schaad Cc: Ludwig Seitz , ace@ietf.org Content-Type: multipart/alternative; boundary="00000000000089a63905746d5daa" Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 16:39:17 -0000 --00000000000089a63905746d5daa Content-Type: text/plain; charset="UTF-8" +1 on pushing up error_description and error_uri I think client_id might be worth keeping low since it is often used even when in combination with client_secret. See OAuth Mtls as an example. On Mon, 27 Aug 2018 at 18:20, Jim Schaad wrote: > > > > -----Original Message----- > > From: Ace On Behalf Of Ludwig Seitz > > Sent: Monday, August 27, 2018 12:52 AM > > To: ace@ietf.org > > Subject: [Ace] Parameter abbreviation number ranges for > draft-ietf-ace-oauth- > > authz > > > > Hello group, > > > > at IETF 102 there was a discussion about the numerical abbreviations we > > introduced for both OAuth parameter names and access token claim names. > > > > I have generated a proposal that makes better use of the number space, > but > I'd > > like the OAuth specialists to have a look at it and see if I pushed any > important > > (= frequently used) OAuth parameter into the two byte number range. > > > > > > Background: > > > > CBOR integers have a very compact representation (1 byte) for numbers > from > > 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes. > Thus > > we'd like to use abbreviations in the first number range for > parameters/claims > > that are frequently used. > > > > My proposal follow below, please feel free to comment. > > > > > > /Ludwig > > ================================================================ > > ================ > > > > > > Existing claim name abbreviations from RFC 8392 (CWT) : > > iss 1 > > sub 2 > > aud 3 > > exp 4 > > nbf 5 > > iat 6 > > cti 7 > > > > New claim name abbreviation introduced by > > draft-ietf-ace-cwt-proof-of-possession: > > > > cnf 8 > > > > New claims introduced by draft-ietf-ace-oauth-authz (with proposed > > abbreviations): > > > > scope 9 > > profile 10 > > rs_cnf 11 > > > > Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed > > abbreviations): > > > > scope 9 > > error 12 > > grant_type 13 > > access_token 14 > > token_type 15 > > > > client_id 24 > > client_secret 25 > > response_type 26 > > state 27 > > redirect_uri 28 > > error_description 29 > > error_uri 30 > > code 31 > > expires_in 32 > > username 33 > > password 34 > > refresh_token 35 > > [JLS] I would be willing to push error_description and error_uri up into > the > two byte range I don't think they fall into the frequently used category in > a working system. I don't know that we need to keep client_id, > client_secret, username and password in the low range at this time. Do we > really think that we are going to be using this on small devices? > > > > > New token endpoint parameters introduced by draft-ietf-ace-oauth-authz > (with > > proposed abbreviations): > > > > req_aud 16 > > req_cnf 17 > > used_cnf 18 > > rs_cnf 19 > > > > (Note that req_* and used_cnf are not yet in the draft, but we came to > the > > conclusion we will need them after the OAuth session at IETF 102. > > They will be in the next update) > > > > Introspection endpoint paramenters from RFC (OAuth 2.0 introspection) > (with > > proposed abbreviations): > > > > iss 1 > > sub 2 > > aud 3 > > exp 4 > > iat 6 > > nbf 5 > > scope 9 > > token_type 15 > > active 20 > > client_id 24 > > username 33 > > jti (no abbreviation, we have cti) > > > > > > > > New introspection endpoint parameters introduced by > > draft-ietf-ace-oauth-authz: > > > > cnf 8 > > rs_cnf 19 > > profile 10 > > > > > > > > > > -- > > Ludwig Seitz, PhD > > Security Lab, RISE SICS > > Phone +46(0)70-349 92 51 > > > > _______________________________________________ > > 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 > --00000000000089a63905746d5daa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 on pushing up error_description and error_uri

I think client_id m= ight be worth keeping low since it is often used even when in combination w= ith client_secret. See OAuth Mtls as an example.
On Mon, 27 Aug 2018 at 18:20, Jim Schaad <ietf@augustcellars.com> wrote:


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 12:52 AM
> To: ace@ietf.org=
> Subject: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-oauth-
> authz
>
> Hello group,
>
> at IETF 102 there was a discussion about the numerical abbreviations w= e
> introduced for both OAuth parameter names and access token claim names= .
>
> I have generated a proposal that makes better use of the number space,= but
I'd
> like the OAuth specialists to have a look at it and see if I pushed an= y
important
> (=3D frequently used) OAuth parameter into the two byte number range.<= br> >
>
> Background:
>
> CBOR integers have a very compact representation (1 byte) for numbers = from
> 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 byt= es.
Thus
> we'd like to use abbreviations in the first number range for
parameters/claims
> that are frequently used.
>
> My proposal follow below, please feel free to comment.
>
>
> /Ludwig
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> Existing claim name abbreviations from RFC 8392 (CWT) :
>=C2=A0 =C2=A0iss=C2=A0 1
>=C2=A0 =C2=A0sub=C2=A0 2
>=C2=A0 =C2=A0aud=C2=A0 3
>=C2=A0 =C2=A0exp=C2=A0 4
>=C2=A0 =C2=A0nbf=C2=A0 5
>=C2=A0 =C2=A0iat=C2=A0 6
>=C2=A0 =C2=A0cti=C2=A0 7
>
> New claim name abbreviation introduced by
> draft-ietf-ace-cwt-proof-of-possession:
>
>=C2=A0 =C2=A0cnf=C2=A0 8
>
> New claims introduced by draft-ietf-ace-oauth-authz (with proposed
> abbreviations):
>
>=C2=A0 =C2=A0scope 9
>=C2=A0 =C2=A0profile 10
>=C2=A0 =C2=A0rs_cnf 11
>
> Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed
> abbreviations):
>
> scope 9
> error 12
> grant_type 13
> access_token 14
> token_type 15
>
> client_id=C2=A0 =C2=A0 =C2=A0 24
> client_secret=C2=A0 25
> response_type=C2=A0 26
> state 27
> redirect_uri 28
> error_description 29
> error_uri 30
> code 31
> expires_in 32
> username 33
> password 34
> refresh_token 35

[JLS] I would be willing to push error_description and error_uri up into th= e
two byte range I don't think they fall into the frequently used categor= y in
a working system.=C2=A0 I don't know that we need to keep client_id, client_secret, username and password in the low range at this time.=C2=A0 = =C2=A0Do we
really think that we are going to be using this on small devices?

>
> New token endpoint parameters introduced by draft-ietf-ace-oauth-authz=
(with
> proposed abbreviations):
>
> req_aud 16
> req_cnf 17
> used_cnf 18
> rs_cnf 19
>
> (Note that req_* and used_cnf are not yet in the draft, but we came to= the
> conclusion we will need them after the OAuth session at IETF 102.
> They will be in the next update)
>
> Introspection endpoint paramenters from RFC=C2=A0 (OAuth 2.0 introspec= tion)
(with
> proposed abbreviations):
>
> iss 1
> sub 2
> aud 3
> exp 4
> iat 6
> nbf 5
> scope=C2=A0 9
> token_type 15
> active 20
> client_id 24
> username 33
> jti (no abbreviation, we have cti)
>
>
>
> New introspection endpoint parameters introduced by
> draft-ietf-ace-oauth-authz:
>
> cnf 8
> rs_cnf=C2=A0 =C2=A019
> profile=C2=A0 10
>
>
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
>
> _______________________________________________
> 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
--00000000000089a63905746d5daa-- From nobody Mon Aug 27 23:40:17 2018 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 E45E2130F1F for ; Mon, 27 Aug 2018 23:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 I6c8LxZFikf8 for ; Mon, 27 Aug 2018 23:40:01 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.41]) (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 1D417130F03 for ; Mon, 27 Aug 2018 23:40:00 -0700 (PDT) Received: from 1fuXfR-0001pk-W1 by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fuXfS-0001rK-Tm; Mon, 27 Aug 2018 23:39:58 -0700 Received: by emcmailer; Mon, 27 Aug 2018 23:39:58 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fuXfR-0001pk-W1; Mon, 27 Aug 2018 23:39:57 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 28 Aug 2018 08:39:57 +0200 To: Jim Schaad , References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 28 Aug 2018 08:39:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 06:40:13 -0000 On 2018-08-27 18:19, Jim Schaad wrote: > > >> -----Original Message----- >> Background: >> >> CBOR integers have a very compact representation (1 byte) for numbers from >> 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes. >~snip~ >> >> client_id 24 >> client_secret 25 >> response_type 26 >> state 27 >> redirect_uri 28 >> error_description 29 >> error_uri 30 >> code 31 >> expires_in 32 >> username 33 >> password 34 >> refresh_token 35 > > [JLS] I would be willing to push error_description and error_uri up into the > two byte range I don't think they fall into the frequently used category in > a working system. I don't know that we need to keep client_id, > client_secret, username and password in the low range at this time. Do we > really think that we are going to be using this on small devices? > Good we agree an that then. Actually according to my understanding of CBOR integers they already are in the two byte category (see quoted part above the ~snip~). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Aug 27 23:44:37 2018 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 BED1C130DE9 for ; Mon, 27 Aug 2018 23:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 9SLCYRXgqM2Y for ; Mon, 27 Aug 2018 23:44:34 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.36]) (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 AF867130DDB for ; Mon, 27 Aug 2018 23:44:33 -0700 (PDT) Received: from 1fuXjp-000JNY-UX by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fuXjp-000JSP-W6; Mon, 27 Aug 2018 23:44:29 -0700 Received: by emcmailer; Mon, 27 Aug 2018 23:44:29 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fuXjp-000JNY-UX; Mon, 27 Aug 2018 23:44:29 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 28 Aug 2018 08:44:29 +0200 To: Samuel Erdtman , Jim Schaad CC: References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 28 Aug 2018 08:44:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 06:44:36 -0000 On 2018-08-27 18:39, Samuel Erdtman wrote: > +1 on pushing up error_description and error_uri > > I think client_id might be worth keeping low since it is often used even > when in combination with client_secret. See OAuth Mtls as an example. > On Mon, 27 Aug 2018 at 18:20, Jim Schaad > wrote: > Note that the 1 byte range is 0-23 Currently in the 1 byte uint range we have 20-23 left unused We could start assigning negative integer values in the 1 byte range if needed. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Aug 28 09:44:41 2018 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 68D30130DF9 for ; Tue, 28 Aug 2018 09:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 9MTggIVNKIK2 for ; Tue, 28 Aug 2018 09:44:38 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0106.outbound.protection.outlook.com [104.47.53.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619C9126DBF for ; Tue, 28 Aug 2018 09:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=90g9Z/EnQgfQe+HwEvMqtp4mbd//LWaTCjq6iRFcb4M=; b=dErAyGS+dNI8MGAHOa2XcuOgOrMhWrUq5PmLdl9P0uMgWx7SXuHErurB3CKnrh/rfjabwz1wR32e1gnS0R0YLAL17n3sBWND7PSm01Tg7jyXzN+vEc+kInqg/O+aTvDC7k/J7FyEc/GmYLFITQ2krY1yX5zqE+rwXj4bbr7+/LY= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0359.namprd00.prod.outlook.com (52.132.128.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1134.0; Tue, 28 Aug 2018 16:44:36 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::84d7:33c9:8e07:9c2]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::84d7:33c9:8e07:9c2%5]) with mapi id 15.20.1137.000; Tue, 28 Aug 2018 16:44:36 +0000 From: Mike Jones To: Ludwig Seitz , Samuel Erdtman , Jim Schaad CC: "ace@ietf.org" Thread-Topic: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz Thread-Index: AQHUPdrlmc0IOguLt0Sx/VCKZU5cwaTTx9qAgAAFXACAAOwwgIAApq3w Date: Tue, 28 Aug 2018 16:44:36 +0000 Message-ID: References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.70.130.226] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0359; 6:IjE6N8RxKHZ5upgUrBDDGZBn6XiFp8lAUTCxBILDlYiMChgDoI4SPRS1SicZU+6V3UWdisyD4sZ6/6J3PWy0XrwUZPCO6hpek7JNO7uCRRVvYJ1uvIxJVS1DjEEts3r0cmiSQtt63LRtGf2RCmBbhivWoKm8jBFpjankfO7aIay3RW5r87qodlXWRxseDT5IbFnhdWwGJkoVz9yGEpkPXyxxvz6aqc5MiSVXSYgDtBxluOj6G4DZLoRgwdEK/b/KqnqRagoIpQCeyuJbB3z9suzujGOBIqj976FHqfuTFL8FItqBPoPj8vOVYVTpNmR55FkpKUr1Jfv1bVlsHaf2OBc1V3ncuetpUbccdyy4noL0oogIJUuifySNfw+/JU5t2d/8CGIzxpYCLUi9Kj+Ok1ZPl/YxAh2Fivp9bNutbdRvxtt7u1cWk0ApWrwCfnvomkjpnRGpOqItq22jLjESMQ==; 5:CvSREnG8a5f+0nJkM5dTc7Cq00M9D0sEl/jedGT1j7sF5Ic5wLJ+Ps1E/Zpqnsb1916aDLAlXLxc9iunFVdRJzG4+1LrYho5iGjy9MR+8+lGaOKKa5oOEtKp7qaob9ztS7lFJd+TEixtOvjbaMoE7MHSU/q/4wlVNrXVl02IPPE=; 7:5ns/FwYOmvBM+6pOV42Jj/mtfado4Hc8CV7QKlZuS2i0WOPCR8qeu9ltL3oPaHYl+3jePhKUlBXzBQ/olAD/b/FRaGzwBuiBMMdJzC+gLdGj4vtVBkS2m1ECmj4ZaxCTj5npNi+m1PxfQrCEpzqEGHkS1UySImHG4a8pvzeUrR4FrZrAFiUmUazkYjIX3Y1HxWVYn2z3DRYFUMdzmsjjHWWFmN/x/cArSRwc0EF+O62tW6YjP+chV67VhiNeRkNU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: af3b1a1d-c766-457f-3fda-08d60d058a1f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR00MB0359; x-ms-traffictypediagnostic: DM5PR00MB0359: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231336)(944501410)(52105095)(2018427008)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699049)(76991033); SRVR:DM5PR00MB0359; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0359; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(136003)(396003)(376002)(13464003)(189003)(199004)(10290500003)(9686003)(74316002)(5660300001)(55016002)(6506007)(4326008)(10090500001)(102836004)(446003)(53546011)(66066001)(8990500004)(81156014)(76176011)(53936002)(966005)(81166006)(8676002)(7736002)(97736004)(8936002)(305945005)(6306002)(2906002)(478600001)(72206003)(7696005)(14454004)(86362001)(476003)(86612001)(68736007)(99286004)(93886005)(110136005)(106356001)(11346002)(6116002)(186003)(14444005)(3846002)(105586002)(316002)(5250100002)(2900100001)(33656002)(26005)(25786009)(6246003)(486006)(22452003)(6436002)(229853002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0359; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UehzqehAVfSCUb2f+iDtJrBCWJ8OeBi6b5FpI9rMaqtYrH+eSyKCS7+AZ6a79BCyIqUd76G9vdsvhsFVWct3u8i/miZTFsRuuzLsYoBQylJH22l1yaahJEtmRSqzJqaYboOQYvLnwTMK1rNeNlX0o56OilYS9mhr2233BOLSDjv0sPbqgeFYwYOfzjYPT8Qb/TBkZtxpkq4SfNkpocv+z9mj8DBW+gqZWbOUCVriDeZymbpKowZGXA1EoETzwmGp0pEVjqXRuoJgE14JLOaccFH+Z6wFLeXfJyXwhqOZowcYTc7JhWljUaMbZgWbuz+dQjY3F/0/h7HlcetOQEfYwmVQ8Q24rFR01kpNoduNokY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: af3b1a1d-c766-457f-3fda-08d60d058a1f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2018 16:44:36.1844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0359 Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 16:44:41 -0000 Especially in light of the possibility of signed requests along the lines o= f https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I believe that al= l the ACE OAuth parameters should be registered as CWT claims. I'll repeat= my request, wearing my designated expert hat, that application-specific va= lues not be requested for registration in the one-byte ranges. The one-byt= e values should be saved for claims that are likely to span multiple kinds = of applications. -- Mike -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Monday, August 27, 2018 11:44 PM To: Samuel Erdtman ; Jim Schaad Cc: ace@ietf.org Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-= oauth-authz On 2018-08-27 18:39, Samuel Erdtman wrote: > +1 on pushing up error_description and error_uri >=20 > I think client_id might be worth keeping low since it is often used=20 > even when in combination with client_secret. See OAuth Mtls as an example= . > On Mon, 27 Aug 2018 at 18:20, Jim Schaad > wrote: >=20 Note that the 1 byte range is 0-23 Currently in the 1 byte uint range we have 20-23 left unused We could start assigning negative integer values in the 1 byte range if nee= ded. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Aug 29 00:04:52 2018 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 3CA06126F72 for ; Wed, 29 Aug 2018 00:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 oEGZinOuUBAs for ; Wed, 29 Aug 2018 00:04:47 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (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 9AB3812008A for ; Wed, 29 Aug 2018 00:04:47 -0700 (PDT) Received: from 1fuuWy-000HXH-VS by out11b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fuuWz-000HZx-Tv; Wed, 29 Aug 2018 00:04:45 -0700 Received: by emcmailer; Wed, 29 Aug 2018 00:04:45 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fuuWy-000HXH-VS; Wed, 29 Aug 2018 00:04:44 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 29 Aug 2018 09:04:44 +0200 To: Mike Jones , Samuel Erdtman , Jim Schaad CC: "ace@ietf.org" References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Wed, 29 Aug 2018 09:04:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 29 Aug 2018 07:04:51 -0000 On 2018-08-28 18:44, Mike Jones wrote: > Especially in light of the possibility of signed requests along the > lines of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I > believe that all the ACE OAuth parameters should be registered as CWT > claims. Ok. > I'll repeat my request, wearing my designated expert hat, > that application-specific values not be requested for registration in > the one-byte ranges. The one-byte values should be saved for claims > that are likely to span multiple kinds of applications. > So what is not generic OAuth 2.0 (+ OAuth introspection) is the following: cnf scope profile rs_cnf req_aud req_cnf used_cnf I am aware of your point-of-view on the 'profile' parameter and I disagree with it (I feel it is sufficient to make it OPTIONAL). What are your thoughts about the other parameters (keeping in mind that 'req_aud', 'req_cnf' and 'used_cnf' are going to replace the use of 'aud' and 'cnf' in the ACE request/response interactions)?. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Aug 29 09:32:31 2018 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 EEC92130DD9 for ; Wed, 29 Aug 2018 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 abgQClozCMzQ for ; Wed, 29 Aug 2018 09:32:27 -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 146EF130DDE for ; Wed, 29 Aug 2018 09:32:27 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Aug 2018 09:28:29 -0700 From: Jim Schaad To: 'Mike Jones' , 'Ludwig Seitz' , 'Samuel Erdtman' CC: References: <02f901d43e21$ca195e10$5e4c1a30$@augustcellars.com> In-Reply-To: Date: Wed, 29 Aug 2018 09:32:17 -0700 Message-ID: <047701d43fb5$db4a0a00$91de1e00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGmsbrlMYcGK1pU4ekVFpBcUUSxNgGsZkUSAV897IMBSxSURgJQpbW3pPzNIyA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 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, 29 Aug 2018 16:32:30 -0000 We are doing all of this in response to a draft? Why can you not fix the draft and put the OAuth parameters in a sub map so there is no collisions? Jim > -----Original Message----- > From: Mike Jones > Sent: Tuesday, August 28, 2018 9:45 AM > To: Ludwig Seitz ; Samuel Erdtman ; > Jim Schaad > Cc: ace@ietf.org > Subject: RE: [Ace] Parameter abbreviation number ranges for draft-ietf-ace- > oauth-authz > > Especially in light of the possibility of signed requests along the lines of > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I believe that all the ACE > OAuth parameters should be registered as CWT claims. I'll repeat my request, > wearing my designated expert hat, that application-specific values not be > requested for registration in the one-byte ranges. The one-byte values should > be saved for claims that are likely to span multiple kinds of applications. > > -- Mike > > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, August 27, 2018 11:44 PM > To: Samuel Erdtman ; Jim Schaad > > Cc: ace@ietf.org > Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace- > oauth-authz > > On 2018-08-27 18:39, Samuel Erdtman wrote: > > +1 on pushing up error_description and error_uri > > > > I think client_id might be worth keeping low since it is often used > > even when in combination with client_secret. See OAuth Mtls as an example. > > On Mon, 27 Aug 2018 at 18:20, Jim Schaad > > wrote: > > > > Note that the 1 byte range is 0-23 > > Currently in the 1 byte uint range we have 20-23 left unused > > We could start assigning negative integer values in the 1 byte range if needed. > > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace