Re: [Ace] WGLC for draft-ietf-ace-oscore-profile

Francesca Palombini <francesca.palombini@ericsson.com> Fri, 26 October 2018 12:46 UTC

Return-Path: <francesca.palombini@ericsson.com>
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 B8E29130DCB for <ace@ietfa.amsl.com>; Fri, 26 Oct 2018 05:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level:
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=K+hm0nZk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=S1GJkFrw
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 bEWsiyf7N3nz for <ace@ietfa.amsl.com>; Fri, 26 Oct 2018 05:46:07 -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 1B1A71286D9 for <ace@ietf.org>; Fri, 26 Oct 2018 05:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540557965; x=1543149965; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0dd9XsY1JB0aOS9o9ZcLCJ9bTAwdqUo2HMsU1jrFiQw=; b=K+hm0nZkjGNSWKzXS+w/oEn3WP/HmawNINLgv46antSU4LmVYDT/ctD2Zx5Scl/B feY2Hu/FFyQ029XADFNBe4A/CxZKfsYSB2rW6BDFBPD4rGSeqLZ5LvTMbz4AuxPS xI7XIdlksz+kzJEkkCANvB3TkG+4o3on1flzYkIgMSU=;
X-AuditID: c1b4fb30-671b09e000007d19-40-5bd30c8da760
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.6D.32025.D8C03DB5; Fri, 26 Oct 2018 14:46:05 +0200 (CEST)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 26 Oct 2018 14:46:02 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 26 Oct 2018 14:46:02 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0dd9XsY1JB0aOS9o9ZcLCJ9bTAwdqUo2HMsU1jrFiQw=; b=S1GJkFrw/wHkyVgqn9xwJ2EKRgMP9usq/xx8EBzOjX/lS6VxO+kqbkYKj9MgJ4xvxZ5/jRv/h6usGHy6aYqLx0LM1fm05DV/icXn5tfHXXU/Vfl33LqtWRIl3GYWNJx4pisV2+6cmNiNU9EWeL+1mVmlh18D+Jz6XCbHz2hXukg=
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2076.eurprd07.prod.outlook.com (10.167.190.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Fri, 26 Oct 2018 12:46:01 +0000
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.019; Fri, 26 Oct 2018 12:46:01 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] WGLC for draft-ietf-ace-oscore-profile
Thread-Index: AdRfTqcrNFwepW1pRaiIJNs5VwRdUAK7AUGAAIueqwAAEAH4gAAkW2oA
Date: Fri, 26 Oct 2018 12:46:01 +0000
Message-ID: <B9A7AB02-2591-45B4-8828-B76B60A4E9E9@ericsson.com>
References: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> <028c01d46a3a$ae1b9e40$0a52dac0$@augustcellars.com> <45F876B9-6BF8-448B-9EFF-28609FC8A805@ericsson.com> <018c01d46ca9$30c0c6c0$92425440$@augustcellars.com>
In-Reply-To: <018c01d46ca9$30c0c6c0$92425440$@augustcellars.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com;
x-originating-ip: [217.31.165.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2076; 6:lW811Y8DtW8I8rdVcujb/04DQjFyVCXk+y6LUuFFBrIC3H95Zxx3O+cL+/iCjfHZLTyHwrxDMNmS+i3Lxyd/BcBbOawMpSNJFGl3RcXeiA5jRgmoYr9mlH0WkCzPYOvC/cOvPS0OmgBUEuzddcEWrMQQR5kM4w0EneJAuKO6JrWxrlDx3whhH5WlLHFn7/Na7ZBQG6KHU+kugKLTnU85N4U1CAvRpkduBJLsc6W210cdbI6UEwLmMDVYVGSBr+Tqit0z37iXceUUIResFxmtUFwhXEVbJknY6eFvS3mbyZ1ehUy3TDB+BoZvh5bIP+PVFK7+RdESwXb7CoHDXN+A6vELCk3GsWXHvZTsC8EWGFRo7WdIAwbe4Fie4TSO+spAr1MHl9yh8y8vF/CrPgavTtDjlwi87+igevhTPnTuUA/Iowdo9D9cYdi12yjiSqmVJYxo9HTLeykJ821w40AcgA==; 5:XEQfbUd0N0gerccqiSHhJ5MVEj72MZng7lQGVACMMQPpjOMU0eYsvpJA+7ct3v+J7ZmGM4tA1g0oPbyjHmUsnjjAKFo/LLnlGBWqssllkFRnf4Fda81dhLzrXaoSRZBZmn5TuSaN3FTkw2Axln4ko9/ymBz6nCIuAdp+2kaV0uQ=; 7:OZK5Blo1zPC9hu47flBIIaw0p0TmyJUlAy6r5dxhzuqjGpuWks50ZZKfhW3+usP3shytdQ3jliFBZCwwEMJP0yfhXWuAZzA3vxdcOJtuuyrrWk3sUATetsJp3SLMxtrRj7QPlWiF7rm4+yMz5w80mA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1c989ab7-f8de-40a7-0310-08d63b40fc16
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2076;
x-ms-traffictypediagnostic: HE1PR0701MB2076:
x-microsoft-antispam-prvs: <HE1PR0701MB2076030C13A0313046C5F08798F00@HE1PR0701MB2076.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(166708455590820)(158342451672863)(788757137089)(248295561703944)(37575265505322);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2076; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2076;
x-forefront-prvs: 083751FCA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(346002)(39860400002)(366004)(376002)(136003)(189003)(199004)(51444003)(13464003)(446003)(53546011)(6486002)(6436002)(6512007)(3846002)(6116002)(256004)(14444005)(14454004)(229853002)(966005)(97736004)(6306002)(93886005)(316002)(33656002)(478600001)(2501003)(6246003)(83716004)(5660300001)(36756003)(53936002)(5250100002)(4326008)(25786009)(2900100001)(71200400001)(71190400001)(486006)(86362001)(345774005)(99286004)(66066001)(2616005)(476003)(6506007)(186003)(8676002)(102836004)(26005)(82746002)(2906002)(81156014)(81166006)(110136005)(8936002)(7736002)(11346002)(68736007)(106356001)(44832011)(305945005)(76176011)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2076; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: +8g3z9HDREjHHxs2fRG7S7wjGVPP0ilU0A58AUaPflo/no2lE2TWTu2y/geLqhsJ7+8RgZ8KGIhppgzdrZI4ovNiOH95TlZ9V71i41fmgvIdTz5esCk8IcqaTQQbR/g9QWudJ928lVloIS5VYnYogjJwi8oLrDSD3Na/t7bv9eyTljOlu1zTdMPCl5Q/CwG18qlmIzIyZkfoFORBA/KvAuRT6ezFXul3DdeZkgZgfSaP9s/W3BZYF+cz/vXv4Wj36BLf2Fg2viCXC9KSSnRR0PyW++UN93RfLpkBytJ0bBaZFx+pXe1qJMRyLcPkz1dakPpd0MllkYhBy51Eu5r7HOrARZpk2cRnMWtHKQiM6Y0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <F63EA7FFB69F7F4E8030654AC06B946E@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c989ab7-f8de-40a7-0310-08d63b40fc16
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 12:46:01.1029 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2076
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObv3zqs4Oi6nPwxLBwmJr6RgiaSBhGJJRYEo5JZeHzSn7Zql f8QSwpi6JDOdDzRfoILhIzXt5cDyESg+Mk2NMdMG1YJEs3S16zHov8/3cc7v8OOwlLSM8WIz NDmcVqNSy8UutDG+Ly+wxHU6MaTW4KrY3CimFJ9671KK9opNcSQV3VlTIY5uatoSnRMluISn cOqMXE4bfFLpkr5smKWyDfE3rbpBpENfLukRywI+Bj1dF/XIhZXiYQRL+hGGiA0E69MbYiKa RDD5qpASBI1LKZh5V41IUimCX2VLjsTZIVYRrG3KBBbjcJg02xiB3fEt+GjrpgWmsC901BhE Au/HJ2B+zoJIJwwaiitpwqeh988PJ4FpfBiaW14zwlslOAIK7mSTUWYEIwtYYGccCabV2t0r EfaG9dvtFBnlCQsrdbs+YAxNzyYowjKwWuwM6SfDzAeDE/HlMLX9aK/jDVN1RYjwezHMPPUj HAjfy8v3OmfB0vBzd0OARxH0WfoR2WkAFE4mkE4WLJbMO5FOMYLlxR2GBAehrcRMl6LQqv/e WuU4TuEj8HggmNjR0DlnRFV7m3tQZHYSWILdYNS4Qtcjpg3JeI6/kpkWGhrEaTOSeT5LE6Th crqQ46sM9fwO6UfWtVMmhFkkd5WMfZ5KlDKqXD4v04SApeTukjjBkqSo8vI5bVaS9rqa403o AEvLPSWKuO4EKU5T5XBXOS6b0/5LRayzlw49GbjxJtkQM3Rt1q3V1vZibDwgpd52zz+mWaTn wzyl21aN387DVLusekv5Va7bZhvfJmXFuBdfAI9QdaW1/3lUTeH5cQ+1DKeuTsTofV4eb22Z OpRWcMYX79gv+yjL12P9DPvsypDR2PyyyI6F+7XD3Ep+49Bg1Le1OqN7RIec5tNVR/0pLa/6 C7Sewe4mAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/X9nHN7agJxuTpou-6j_M7NZg2dM>
Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 12:46:11 -0000

Hi Jim,

It sounds like you are assuming that the Client would have to remember only one security context, but it is possible that the client has several (old) security contexts associated with one access token, for example if the RS has rebooted several times. It would be unreasonable to require the client to store and check all of those when deriving a new one (even if it is just the nonces). 

Also, it is not required that the AS provides a new access token to the Client, as it may be pre-generated and not expired. So in that case, if the client does not keep track of access tokens and security contexts it has used, it might end up with reused keys and nonces.

For both these reasons, we think that the client generated nonce is needed. If you agree with that, we can discuss where to transport these nonces, for example we can avoid echoing N1 if we use it as salt. Also, as you suggested, it seems like a good idea to make this mechanism optional. We prepare for discussion about this in Bangkok.

Thanks,
Francesca

On 25/10/2018, 23:25, "Jim Schaad" <ietf@augustcellars.com> wrote:

    
    
    > -----Original Message-----
    > From: Francesca Palombini <francesca.palombini@ericsson.com>
    > Sent: Thursday, October 25, 2018 4:47 AM
    > To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-oscore-
    > profile@ietf.org
    > Cc: ace@ietf.org
    > Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile
    > 
    > Hi Jim,
    > 
    > Thank you for your review comments. We agree with all your points, and
    > have opened issues: https://github.com/ace-wg/ace-oscore-profile/issues to
    > get this fixed.
    > 
    > Inline some detailed answer.
    > 
    > Thanks,
    > Francesca
    > 
    > On 22/10/2018, 21:09, "Jim Schaad" <ietf@augustcellars.com> wrote:
    > 
    >     * Section 1 - I understand the reasoning behind having the server send back
    >     a nonce, although it would be good to have a description someplace about
    > why
    >     this is being done.  (I would also make it optional as not all RS need to do
    >     this.)  I do not understand the reasoning behind having the client send a
    >     nonce to the server.
    > 
    > FP: The motivation for the nonce construction was in the security
    > considerations, but I agree that having it in the Protocol Overview makes
    > sense, so I opened an issue to fix that. The reason behind having the client
    > create a nonce is that we are protecting against an attacker replaying an old
    > RS message (containing an old nonce), which would provoke the creation of
    > an old security context on the Client, and reuse of keys and nonces for a
    > different (new) message.
    
    So what you are looking at is a client which is going to "forget" the current security context that it possesses for an RS but not the token, re-posting the token to the RS because it apparently thinks that the RS has forgotten the token and context without and then accepting the replay as being valid.  
    
    I think that a client which has forgotten the security context is also going to forget the token and thus need a new one.
    I think that a client which is going to remember the security context is also going to remember the nonce from the server and thus not rebuild the context if the same nonce comes back.
    
    If this needs to be explicit - then it should be made so.
    
    > 
    >     * Section 3.1 - This is more general than the section, but you should not
    >     use the URI path in the text, instead you should be using the name that is
    >     in the authz document.
    > 
    > FP: Agreed, issue opened to fix this.
    > 
    >     * Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the
    >     key data?  Would a different field name be better?
    > 
    > FP: This was brought up several times, so we will make this change now.
    > 
    >     * Section 3.2 - Please provide a justification for the requirement that the
    >     ids must be unique over the set of all clients and RS.   I can see that the
    >     client ids need to be unique on a single RS and RS ids need to be unique for
    >     any given client but not the broader statement.
    > 
    > FP: You are right, this requirement is too wide. We will replace with your
    > suggestion.
    > 
    >     * Please add an explicit section on when a RS and a client should discard
    >     the security context.
    > 
    > FP: Ok we will add this. As mentioned in the issue, I have now only this 3
    > cases in mind: Partial IV space ends (either C or RS); the kid context on the RS
    > side does not match with N1 (RS); C receives a number of Unauthorized (C),
    > although that is a consideration/recommendations, details would be
    > application specific. Do you see any other case relevant for this section?
    
    Well - there are thing like expiration of the token which would make sense as well.    If you re-register the token because of an unauthorized and get back a different nonce value.
    
    > 
    >     * Section 6 - Ok I'll bite  - how does not echoing the nonce allow for a
    >     man-in-the-middle attack given that the salt and shared secret are still
    >     going to be known only to the C and RS and not to the MITM.  I can see a
    > DOS
    >     attack being made, but that can be done even without this just by causing
    >     the response to never be delivered.
    > 
    > FP: Ok so our mistake here is to use the term MitM, so to solve this we will
    > replace with "on-path attacker". The following sentence should be correct
    > with that fix "Moreover, the client echoes the nonce created by the RS,
    > which verifies it before deriving the Security Context, and this protects
    > against an adversary acting as an on path attacker and substituting the nonce
    > in transit from client to RS to provoke the creation of different Security
    > Contexts in the client and RS." Yes this is a DOS, but could also lead to reuse
    > of keys and nonces, as mentioned before.
    
    See my above comment.  But there are no problems here with the server doing anything interesting as it would presumably not have generated the same nonce value as the last time.  This means that the client would generate new keys only if the previous comment was wrong.
    
    I just don't see this as being a problem.  Merits discussion in Bangkok
    
    Jim
    
    
    > 
    >     * Appendix - I am not sure that I think that the EDHOC profile should be in
    >     this document as oppose to being in it's own document.  The fact that we
    >     have not even tried to get this to work in any of the interop tests means
    >     that I am less sure that it is well baked.
    > 
    > FP: Agreed, we will remove this from this document and move it to its own
    > document
    > 
    >     Jim
    > 
    > 
    >     > -----Original Message-----
    >     > From: Ace <ace-bounces@ietf.org> On Behalf Of Jim Schaad
    >     > Sent: Monday, October 8, 2018 2:35 PM
    >     > To: ace@ietf.org
    >     > Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile
    >     >
    >     > The chairs believe that the set of documents dealing with the OAuth
    >     > framework for constrained environments is nearing the point that we
    > should
    >     > be able to advance it to the IESG for publication.   We therefore want to
    >     > have a full list of issues that need to be dealt with at the Bangkok
    >     > meeting.
    >     >
    >     > This starts a 2 week WGLC for draft-ietf-ace-oscore-profile
    >     >
    >     > We know that the following issues are outstanding:
    >     >
    >     > draft-ietf-ace-oscore-profile:
    >     > *  No current known issues
    >     >
    >     >
    >     > Jim & Roman
    >     >
    >     >
    >     > _______________________________________________
    >     > Ace mailing list
    >     > Ace@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/ace
    > 
    >