From nobody Wed Mar 10 12:59:15 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22D73A1810 for ; Wed, 10 Mar 2021 12:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk6s0REqYgmP for ; Wed, 10 Mar 2021 12:59:12 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4BB193A180F for ; Wed, 10 Mar 2021 12:59:12 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 12AKrgqL048206; Wed, 10 Mar 2021 15:59:11 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 376kkvrha2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 15:59:10 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 12AKxAn2006320; Wed, 10 Mar 2021 15:59:10 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 12AKx5XB006225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 15:59:05 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id EAE50400B579; Wed, 10 Mar 2021 20:59:05 +0000 (GMT) Received: from GAALPA1MSGED2CC.ITServices.sbc.com (unknown [135.50.89.134]) by zlp30483.vci.att.com (Service) with ESMTP id CC8B7400B574; Wed, 10 Mar 2021 20:59:05 +0000 (GMT) Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGED2CC.ITServices.sbc.com (135.50.89.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 10 Mar 2021 15:59:05 -0500 Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Wed, 10 Mar 2021 15:59:05 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.100) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Wed, 10 Mar 2021 15:58:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZXEWucLT0mP1txcPcdNthlxZDT0iP4RbnhLbMMXR5adWdufBlN+OWEVlmKq8gcCOVHFfG/vmj0hAXqmX+/C6Y4P+uZanHgoTB/bgpjEH5pMNxosuQL4AHevzrFgRFGIA4FD8v6XAB5mZxrwFQdLCM8rkiX+CnI1Xyo/ZBPEba94gtISN6F71K4k6kGNi57kWmW7i3jeyppyyu+j4VfsO8nQvUK/nW/LtIiBMHkLPdKHb6YFeSFyRe03otV4j6HiMl80LqpSl96SJX3vFTWzcZtgPiXbYQ4TAYleb+fO8OUakSM8EZGtCv0dWWaq4Y5l2EkgGhFQxBlj3Jv3Xu7dILg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R93/5fMfJ1+gtpdww+vzBiztKm9bWEAgxE5JZ60ndGU=; b=Rb7frFbO+MX6K8N6bR1ljgjuGEipWR2bJWhub9lcPQWpm6RozAw75ci5++8QhhMXwtvk/QLno0Bo9ex5f6uPeg3QLLzW0klV0iLoLIOaqmFoOUeNK2U6kkc2gWqgq8IFSQrNljPz3Om9X1r/dgVAWmZq0Uzx/Lm2SlrQDVGBF5/r8gUHf8QthWZsZjKuPmLxg261jay/wHdCf8PTEYTFjL2IV+fE/nEcld+FTd0svjVRlrzSqBHmS4UHXOCNP+HeFzcHeCRAyQ+BM296o/ug+cXSo8pz9tb/66UJhl5jpOlJeF3HPrDMny5x1H6Ax+M3xthlOqDtnprTiMe0B11lKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R93/5fMfJ1+gtpdww+vzBiztKm9bWEAgxE5JZ60ndGU=; b=xBzk/Ox5XyN5ojz7yg3aA1GQvI3izct7vo8Q+QdEJo755evVLRNTozz6ImeDmQvS3f6eDujo+BABuDM4/113l0TZpyIjRHw2jTVQ97zXWtDrlhJPFL1zgUIb+qDqRuUGMPk9Z2Rfs6jmndUsK3YdmAMXfWqzdOd7I6M7qtAp1CQ= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6923.namprd02.prod.outlook.com (2603:10b6:5:25e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Wed, 10 Mar 2021 20:58:45 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925%7]) with mapi id 15.20.3890.038; Wed, 10 Mar 2021 20:58:45 +0000 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Antonin_D=E9cimo=27?= , "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] MAC and key size Thread-Index: AQHXFPuHKjWHBF01eUWdOzHnKGzsoap77YyAgAAzLwCAAZT1MA== Date: Wed, 10 Mar 2021 20:58:45 +0000 Message-ID: References: <875z20tjmj.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82a08d35-8470-4865-9b1c-08d8e4074b9c x-ms-traffictypediagnostic: DM6PR02MB6923: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Zgx1RRA2w7Sl2WpGRNjGqUJuFojDww5HvNTeUkI2sU4wCd9QbeLRdwI07wIqD7PoFJyOAd6jXosFwg84e7icRiz/Vnxuej8O6Y7fWx7h+fPao99WDkO6bGVumeDoTepC4XwQbqM+H6FKmGWju3Q4Ye0LiAuJ5OGYbyxUF3K+eOBwPvfAgZnphhDpHmmDI8BOGJsTVmduS1/4Q8a0bAUEaSRS9yaYAK9ejWp0+EOJ63KI+D4S1zdkb6J30jvFNqyDZUAaFFj2Iw0VqDRSpQjX2WVXU6xV+5VXLjQ7+GvnUMxWlY/mZm7g3OKnG28ugBWa2Zb2KTclzciVOhO/56reQGgxuyi0R5POjcNQNSezr0z1DRmqJ/PITCdmCptUIWxtvgX2R+Rz6yX2At2wgi5HIystJhzamb5KqvrLbuPLlXpeBXwb5P98+EoH04JjHAaaOz7CCB2q4XWjDPN8nLedCAvzDopmx2bcBVqo3w/DRS1SBb23WW5liyyUxX5FHSSv9KeF7hxnyYFHjEaLcIahg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(66556008)(26005)(33656002)(86362001)(76116006)(186003)(66476007)(6506007)(8936002)(110136005)(55016002)(52536014)(4326008)(82202003)(7696005)(71200400001)(5660300002)(8676002)(2906002)(83380400001)(66574015)(478600001)(9686003)(66446008)(64756008)(316002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?LwxqG4pQ/DP1G0gMIS7CFvoTNLSru6nN0pw6E3YK5mfKaCItE15t8um61g?= =?iso-8859-1?Q?F4+4d/MGEKyebD6KQeT9E3VX20A8pVZjItYrgoIfuIMMfjztwF7miAFHO/?= =?iso-8859-1?Q?FYsEr50JIWIh08tqvIVPBI7Y4S9ZN4Z8UGmjSmjgb0ZJcB18ncbSp+ZQfD?= =?iso-8859-1?Q?QeEaqOCNoWJ0Pj9lYtaxzar3ggCzmMpFs7I5SVaBfzax9QFdRlWIEhnIPu?= =?iso-8859-1?Q?nknxh/NR6A2aPRa3SfMftx6Sc8P1IDo1Uv3bexdpySaD1YrDuISB+fNL+X?= =?iso-8859-1?Q?blK81ZgRQH9eDMfHITkRY3LkZGNkiRWIcx5nKxPjQbfzCh63g8ItLuURVF?= =?iso-8859-1?Q?OhaVj5Kr8o1hPVxpy5d95sTgohJChIBsMZ6TWYJyR3i9PrfJOmR6BjxuWa?= =?iso-8859-1?Q?1OaMOt7KWzlUF6VrdB1TgUzW4ysJx3j+bOEOMBycVf9H/qf5u84XAiSp6r?= =?iso-8859-1?Q?VOwJvmjYkqJ0ZaI02s+fM4Od+q4Xw6xydbZCpsQG+RaXpxinWnd2DQ6oc+?= =?iso-8859-1?Q?JMRSkDIaHIJBfIUPP3KdRIcfOW04444m24LiyUFyfdL+hLmsRUUHEZKmhH?= =?iso-8859-1?Q?cwYB/1yCf589RhHLKYhn2xNtrIJvNFGWO4EhCG87d/QCbgmKbDXD3JgN1F?= =?iso-8859-1?Q?yqDDNWE2zls3/6k2ZA94XVDola/7kZT26845eoFfLdqaIFW/ayyUZxM/XL?= =?iso-8859-1?Q?GwOihXw1bbBoKbb2EBRk8abOw45pQ+H8zSVz0hNuYa+fOd9G01aY5M+JLw?= =?iso-8859-1?Q?H3Un44lSgHzpFUFjMInK0lmKF4YiFGNR8RM6pUcqiz89N3POY8ZVI+Vhpt?= =?iso-8859-1?Q?Ms5Ytzb6oQcNCS/M4w/tu9/hSvhKLsoLHpNoNcby0bROh5i4HQ9vUDXohB?= =?iso-8859-1?Q?6SX6ILbd6KE46Mh1bL8EQACt2kOH+cAmYvxNt5N5qs1k5CCEfuKREdmO0z?= =?iso-8859-1?Q?AMAI6jKfcpOKTIXocl+8arWFlES7LuPBHAw70tyl5pVwf+x6CtpX0fMvoN?= =?iso-8859-1?Q?CJzAGcL7WtFEGBlu3gC7K0rqZasMMreGibgeT3WeqSwGaPDcYHDK7x9DIy?= =?iso-8859-1?Q?1waN/wQwOylbiS/BaR1OY2cEo8K3v9NDLVF149UX13sGwLND1AENGtLEf4?= =?iso-8859-1?Q?syYQmYBw3bd1hDeno6IvROl0RhP3JhpzqxSuH+4T/U3jPfIbe/rXAIa3nH?= =?iso-8859-1?Q?2+qtmIfbLPtADjbdec4bNY7gqOHQRqhlESkBxvxegGJ5222gXTtas9bLkY?= =?iso-8859-1?Q?ZY3abQOm29h7kY5+W6PFrfANBH1q3LFazxgFWCq6H2Y9OsO2SZ+rYx5ghY?= =?iso-8859-1?Q?Js5v1e8NAsH/z64cNmLx5dFLrjM1pl6ZSpfwuPdG+6gFEDfVTh3oTiAkvV?= =?iso-8859-1?Q?nlsg7ps5fm?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82a08d35-8470-4865-9b1c-08d8e4074b9c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 20:58:45.6666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fc8N8RG0r/tQjvhCuuAIC7yUrlQkhjIPwyx7KxNSp2wSbRLaRGJpptpkGjWvhUmR X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6923 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 8A7B81254F34D83244118AA3E908BCF1BE78C2F79BD541692CF7704ACD11ED1C2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-10_12:2021-03-10, 2021-03-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 phishscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103100100 Archived-At: Subject: Re: [babel] MAC and key size X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 20:59:14 -0000 I've been pondering and have a new suggestion. Here's what I'm thinking as a proposal for the parameter description: This value is of a length suitable for the associated babel-mac-key-algorit= hm. If the algorithm is based on the HMAC construction [RFC2104], the lengt= h MUST be between 0 and an upper limit that is at least the size of the out= put length (where "HMAC-SHA256" output length is 32 octets as described in = [RFC4868]). Longer lengths MAY be supported but are not necessary if the ma= nagement system has the ability to generate a suitably random value (e.g., = by randomly generating a value or by using a key derivation technique as re= commended in [RFC8967] Security Considerations). If the algorithm is "BLAKE= 2s-128", the length MUST be between 0 and 32 bytes inclusive as specified b= y [RFC7693]. In the Security Considerations I propose adding, after the sentence "See th= e Security Considerations section of [RFC8967] for additional consideration= s related to MAC keys.":=20 The fifth paragraph of that security Considerations section makes some spec= ific key value recommendations that should be noted. It says that if it is = necessary to derive keys from a human-readable passphrase, "only the derive= d keys should be communicated to the routers" and "the original passphrase = itself should be kept on the host used to perform the key generation" (whic= h would be the management system in the case of a remote management protoco= l). It also recommends that keys "should have a length of 32 octets (both f= or HMAC-SHA256 and BLAKE2s), and be chosen randomly". I need to get an email sent to Ben today. If I hear nothing, I'll propose t= his to him later today. Barbara > > There is indeed confusion in OSPF RFCs about the upper bound for the > > key in HMAC after which to start hashing. RFC 4634, 6234, Wikipedia, > > Bird (quoting Toke), and babeld use the block size. Babel-MAC links to > > RFC 6234. We are safe from that issue. > > > > > HMAC is defined using two keys: > > > - K' =3D H(K) if |K| > block size > > > > HMAC and blake2s are slightly different, in particular blake2s > > *limits* the maximum size of the key and doesn't pre-hash it. > > > > > Ben wants it to be K, while I would prefer it to be K', and any > > > hashing should be done before the key is inserted into the > > > management interface. > > > > Note that reference implementations of hash algorithms take K as > > parameter. But there's not much to worry about: for hmac-sha256 it > > doesn't matter whether they are pre-hashed or not because of the HMAC > > construct, and for blake2s it doesn't matter because the key isn't > > hashed (and a pad is trivial). > > > > I expect the user to be a bit confused to see the hashed key. If the > > management delivers the hashed key, it also means that the key > > derivation function is in the management interface. That would > > simplify a bit a Babel implementation. > > > > > the key SHOULD be no larger than the underlying hash's block size, > > > > For blake2s the key cannot be larger than half the hash's block size. > > > > I'd be in favor of using the limits enforced by the hashing algorithm > > if they exist (the case of blake2s). If they don't, then use this > > SHOULD, although for hmac-sha256 we've already accepted that keys > > longer than 32 bytes (half the hash's block size) give no additional > > security. But does it really matter, as HMAC already handles > > arbitrary-sized keys? > > > > > it SHOULD be at least the digest size > > > > Seems like a good recommendation, but I think we're just guessing here. > > > > > > What matters most and where we had troubles was the digest size to > > use: it can be configured with blake2s, or generally the output can be > > truncated. Implementations using the same hashing algorithm must agree > > on a digest size beforehand, or verifying the signature of a packet > > simply will fail (and you don't want to check if digests are prefixes > > of each other). We are safe from that issue in Babel-MAC. > > > > > > Regarding the input format of a key, I've seen a mail exchange that > > flew a bit over my head, but remember that a key is just a big number, > > and we're looking for a practical symbolic representation of that > > number. An hexadecimal string seems to me the easiest human and > > machine wise. I don't see babeld accepting a raw binary sequence as a > > key (but I could be wrong). > > > > Currently in babeld I enforce 32 bytes keys for both hmac-sha256 and > > blake2s, but that could be relaxed. Babeld only understands > > hexadecimal strings. >=20 > I think I'll stick with the binary datatype. That's what Juliusz had prev= iously > suggested (and we did discuss that). It's pretty trivial to go between he= x and > binary and to provide a UI for entering hex that then converts immediatel= y to > binary, if there were to be a UI. Or for the remote management code (on t= he > router) to convert binary to hex before providing to a Babel implementati= on (if > that were necessary). All bits are fully supported and represented in bot= h > datatypes. >=20 > Here's what I'm thinking as a proposal for the description: >=20 > This value is of a length suitable for the associated babel-mac-key-algor= ithm. If > the algorithm is based on the HMAC construction [RFC2104], the length SHO= ULD > be between 0 and the block size of the underlying hash inclusive (where "= HMAC- > SHA256" block size is 64 bytes as described in [RFC4868]) for cases where= the > management system has the ability to generate a suitably random value (e.= g., by > randomly generating a value or by using a key derivation technique as > recommended in [RFC8967] Security Considerations). While longer values co= uld > be provided, they do not increase security if the value is sufficiently r= andom. If > the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes > inclusive, as described in [RFC7693]. >=20 > Barbara