Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize

Göran Selander <goran.selander@ericsson.com> Fri, 08 March 2019 16:01 UTC

Return-Path: <goran.selander@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 873C5124B91 for <ace@ietfa.amsl.com>; Fri, 8 Mar 2019 08:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.322
X-Spam-Level:
X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GAd24hMt; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gSrXUh/V
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 s0zKROzDbcyA for <ace@ietfa.amsl.com>; Fri, 8 Mar 2019 08:01:31 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 CFCE212423B for <ace@ietf.org>; Fri, 8 Mar 2019 08:01:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552060888; x=1554652888; 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=u6ySlU6DTEYJTHNz8AEWmFG3lNgUR2SZddWJSYrar5o=; b=GAd24hMtGDoQLZ4+E9OVHkckQCOUtNKoxts8f6V6JGLkdRR7TfYOt3VESz9J/1xv aU+CLyw58jCOj1hSgItEACCgw8bX5Sa+JO283Yx7tOqkdBux07Pbp/oZkc/9U3mK jM+mBQl0F73TZdWGwsQd1UBFNx359MGAR/BvEsAS3ms=;
X-AuditID: c1b4fb25-da1ff70000005ff7-bd-5c8291d79932
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.1F.24567.7D1928C5; Fri, 8 Mar 2019 17:01:28 +0100 (CET)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 8 Mar 2019 17:01:27 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) 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, 8 Mar 2019 17:01:27 +0100
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=u6ySlU6DTEYJTHNz8AEWmFG3lNgUR2SZddWJSYrar5o=; b=gSrXUh/Vn1Byvzr+Pt7/Ppr4kVcSdWr6ki/G/Mjsk5+ikT5PneCJpvQfhxGgBFm2Xsw0enAdB1rz5U+kmyj7nRKpDBkitxlsI4Fl7wZCfb9iQ7ZmYEoJyXwfgE1DOdYoHRAE0J8EyPkPaxN7IIip4kHs7Tlrm1oDjJ4m3mpIwZg=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3097.eurprd07.prod.outlook.com (10.170.244.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Fri, 8 Mar 2019 16:01:26 +0000
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e%2]) with mapi id 15.20.1709.009; Fri, 8 Mar 2019 16:01:26 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-dtls-authorize@ietf.org" <draft-ietf-ace-dtls-authorize@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize
Thread-Index: AQHUaj69s1vBMayUuUmDRgxLJLKGBKVBbIM0gEa9DACAccctgIAI2+aA
Date: Fri, 8 Mar 2019 16:01:26 +0000
Message-ID: <250DA6EB-8B59-42D1-877E-ABA1149100EB@ericsson.com>
References: <029e01d46a3e$72bad330$58307990$@augustcellars.com> <87a7mnv7ls.fsf@tzi.org> <990DB036-3144-4729-8FB1-8E25E704E2DA@ericsson.com> <005401d4d162$9f0c9870$dd25c950$@augustcellars.com>
In-Reply-To: <005401d4d162$9f0c9870$dd25c950$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 462d555f-4d45-4576-3681-08d6a3df51cc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3097;
x-ms-traffictypediagnostic: HE1PR07MB3097:
x-microsoft-antispam-prvs: <HE1PR07MB3097242779A5BC7A98FCC9CFF44D0@HE1PR07MB3097.eurprd07.prod.outlook.com>
x-forefront-prvs: 0970508454
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(366004)(396003)(39860400002)(13464003)(189003)(199004)(3846002)(6246003)(53936002)(26005)(36756003)(102836004)(5660300002)(6506007)(97736004)(186003)(86362001)(478600001)(71200400001)(66066001)(71190400001)(2906002)(8676002)(110136005)(316002)(81166006)(58126008)(81156014)(85182001)(68736007)(14444005)(33656002)(82746002)(105586002)(83716004)(256004)(8936002)(85202003)(2501003)(486006)(106356001)(2616005)(476003)(14454004)(229853002)(6512007)(76176011)(6486002)(4326008)(446003)(99286004)(66574012)(6436002)(25786009)(11346002)(93886005)(6116002)(7736002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3097; H:HE1PR07MB4172.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Mh+nS3XTjTdrtB4tkElitDgwtTQ5MqIRwPno3LzW7B6FkLrnsIntnJfB0ki8MYCpeAdOa79xMwL//THvBHUU3nkHhZ1p+9NTPo5gMs4kPU6vqembPAdsduB9/eT65HT8uaN18AscXzl8tsdcqY/tgzmjTBdkOw/FZrACGqTC/jiZ+xZDb66eeuATD/5/9OcEiDUooPjczIuDANyxtU8OKLoTOEoSNUrkeyLHLXFhEYUWw5baBeGo99pJFsKOttcUgVvhPRh/mf+s3RCE+Lypy3Bw2xYGJ2Ln5sRwLANyShn1eZKU3pW6EJwRtfH3mtbY0rnJgGPS1c79d/cv+uIYumtxWvASbwHzvrvXmF6sSejxfY21r5kqU037dll92qr2KI6CTvkZt1QQJG9K1fwejg6U6caiIrTJ6aEMhyEai74=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0239D579D28F8E4DA2277EC9BDAEDE59@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 462d555f-4d45-4576-3681-08d6a3df51cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 16:01:26.2994 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OztKo9fl5pPNrFkfEtTUIiNvQZYQRZ8ihuhWHrxf2FFT P8Qc85I3LA1zCUqdKPJWoqRjU1sqKGlgdhMq5yUMNZTSJaW07Wj07fc8//9zeR9ehpTeEXkz KZk5rDZTk66k3amGK8/zAj7c0scdnSpBYfb1SjLMtNpKhLXU2+loMvZZYz0dy/MbxCVC5R6e yKan5LHaoEi1e7LZ4J/9Kjp/oK9UpEO/IsuRGwP4GNh6vxDlyJ2R4kEEzW0LIiFYQ6Bfr6OE 4AEB60UG2hlQuIaE3u+PkaDcJqCn44dYCGwIyi3zpLMzjc/AtG6GcLInvgGN+gEXk/ggtDdW u3gPjoGX9lpS8JyFlaE1eoe7df0uD4UPwczsWxdLcBSYh0fof9uW3TNRTsENR0OJ8ZPYyQjL wT7auj3MC6bmmgjhqRh482tSYBl8m90SOVmGg6CrepoSauNB365zDGAcngPAb+4V7D4w0VSB BL4A700218UAf0RQaZ8SC4I/lOimtzkNbMUGkdBHARuDCsFfRcOopcPlkWIWHrUVoxoUaPxv VaOjhMRHoMMUJKRjocUwIzZun66uwuZiCfaAkYY5qhmJniAZx3JXM5JCQgNZbco1jsvKDMxk czqR47O86Pp9uAe9WTptRZhByl0SntPHSUWaPK4gw4qAIZWeEmWRIyVJ1BQUstqsBG1uOstZ 0T6GUnpJ/kg94qQ4SZPDprFsNqvdUQnGzVuHrnepJcPxcvNifCG9qeYVGZO5Ctp3YsSYz9+N SAhUzZ5/uNx53FpzKqKi9UTDu2C/rT7xZH/o55+RYziq7GSqylKq8V2cF3nUBqio8d3nF+KU oUPqGPnX1PCNi3bLuRm53+Xs8acr0Z37ZctjkzeX+NXu0Q6f2ZD7VT0TdMyUkuKSNcH+pJbT /AXc4qKWKAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/FaFzTlPB0lzJ2rQOejP3nSOTKrc>
Subject: Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize
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, 08 Mar 2019 16:01:34 -0000

Hi Jim,

Thanks for comments. 

On 2019-03-03, 02:44, "Jim Schaad" <ietf@augustcellars.com> wrote:

    I am responding to the review below in regards to the most recent version -06.
    
    > -----Original Message-----
    >     > Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level?
    > 
    >     See next comment.
    > 
    > [GS]  alg parameter included
    > 
    >     > Section 3.3 - I am always bothered by the fact that PSK should really be
    > PSS
    >     > at this point.  The secret value is no longer a key and thus does not
    >     > necessarily have a length.  There is also a problem of trying to decide
    > what
    >     > the length of this value would be based on the algorithm.  If the client
    >     > offers TLS_PSK_WITH_AES_128_CCM_8 and
    > TLS_PSK_WITH_AES_256_CCM_8  (I may
    >     > have gotten these wrong but the intent should be understandable) then
    > what
    >     > length is the PSK supposed to be?
    > 
    >     I think what you are saying is that for the shared secret (k) in the
    >     COSE_Key structure in Fig. 4, the AS needs to tell C what to do with
    >     that shared secret? This was the intention of the alg parameter (which
    >     has a not-so-useful value in this example).
    
    Some of what is done here makes sense and some of it makes no sense at all.
    
    Happy with the removal of the "alg" parameter in the root map.  
    
    Happy with the addition of the kid parameter in the COSE_Key object since this is required for doing DTLS w/o sending the token as the identifier.
    
    I have no idea what the algorithm is doing here?  This is not currently a COSE algorithm, it is a TLS algorithm and thus would not make a great deal of sense.  

GS: I admit this does not make sense, neither here nor in Fig. 6.

The terms of what the PSK length should be would be better covered by a statement along the lines of "When offering and/or accepting a TLS cryptographic suite, the length of the PSK should be at least as long as the symmetric encryption algorithms that are offered." This may already be pointed to in the TLS documents and thus can be referenced to rather than stated explicitly.

GS: 
1. If the PSK is not uniformly random, the security level is not given by the length. I note in the ACE framework: "The AS generates a random symmetric PoP key." Perhaps we should add 'uniform' to this text?

2. About the proposed text, how about making it into a consideration: "Note that the security level depends both of the length of PSK and the security of the TLS cipher suite and key exchange algorithm." I didn't find any text in TLS that I could reference.

    When looking at the KDF option that you are providing.  I don't understand why you don't just make the KDF function and the length of the secret to be derived as pre-configured properties.  There is absolutely nothing that prevents this from being a 141 byte value.  
    
GS: I'm not sure exactly what is requested. 
* HKDF-SHA-256 is mentioned as an example of a KDF, indeed this entire part of the section is an example. Do you want to remove the example using COSE_KDF_Context entirely, or just assume that selected components are preconfigured.
* I agree that keyDataLength is restrictive, should we replace that with a consideration on security levels, like the text on PSK above?


    I am not seeing anything in the security considerations about protecting this secret and what all will be available to an attacker in the event that this secret is leaked.  Specifically, it allows for any previously recorded session to be decrypted if the KID is leaked, such as using the KID as the key identifier in the handshake protocol rather than sending across the CWT (assuming that it is encrypted).  
    It will allow for an impersonation attack to occur in the event that the KID for a client in the event that the KID is leaked as the attacker would be able to create the same token that is passed to the client.

GS: I agree that a security consideration about protecting the key derivation key is needed. But this is another key shared between AS and RS, wouldn't the security considerations be similar? I don't understand what is the meaning of "KID is leaked".


        
    > 
    >     > Section 3.3 - Figure 5 - Is this defining a new set of entries for cnf or is
    >     > there a missing layer someplace?
    > 
    >     This is indeed a new set of entries. An internal discussion between the
    >     draft authors led to the opinion that we cannot use a COSE_Key structure
    >     in the cnf structure as this would have different semantics as intended
    >     here. We came to the conclusion that for key derivation, listing the
    >     required fields directly in the cnf structure is the cleanest solution.
    > 
    > [GS] new layer added, called ACE_Salt.
    
    This does not seem to be what was implemented in the current draft.

GS: The example in section 3.3. of using the kid to derive a shared secret removes the need for this construct.
    
    >     > Section 4 - The requirement that the "kid" be in a previously issued token
    >     > would have problems with this if you were to use the "kid" of an RPK
    > which
    >     > can be constant rather than being changed on each newly created token.
    > 
    >     To solve this we could require that the COSE_Key structure for RS's RPK
    >     in the AS-to-Client response must also have a kid. Section 4 does not
    >     prevent the kid to be constant.
    > 
    
    >     > Section 5 - this seems to be a very strange place to define the new
    >     > parameter.
    > 
    >     True. How about moving this parameter to Section 4?
    > 
    > [GS] Change already done.
    
    This seems to have just vanished - is that want is desired?
    
GS: Yes, it was redundant since it is included in the framework
    
Göran