Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
"STARK, BARBARA H" <bs7652@att.com> Wed, 04 November 2020 23:36 UTC
Return-Path: <bs7652@att.com>
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 ECEB73A117D; Wed, 4 Nov 2020 15:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 SjKecHcyArqo; Wed, 4 Nov 2020 15:36:08 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D00E83A1166; Wed, 4 Nov 2020 15:36:08 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0A4NXffC018933; Wed, 4 Nov 2020 18:36:06 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 34m2dx4g8c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 18:36:05 -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 0A4Na4qX025469; Wed, 4 Nov 2020 18:36:04 -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 0A4Na1GU025454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 18:36:01 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 6198240145B2; Wed, 4 Nov 2020 23:36:01 +0000 (GMT)
Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (unknown [135.50.89.96]) by zlp30483.vci.att.com (Service) with ESMTPS id 35A0940145AF; Wed, 4 Nov 2020 23:36:01 +0000 (GMT)
Received: from GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 18:36:00 -0500
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 18:36:00 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) 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.2044.4; Wed, 4 Nov 2020 18:35:52 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=auB17KR7dMZpQITq8p3Krs2UM6Dqfgrr79lGg+Q27nOl5eB3/PAxpngL1yZRPyzI1mOgGIUQAci+tCSNv1T7NP0szOoDwBQya9zjw2UnhFT9gxy3avLdmtQfnbSC22JEOdDwRUqX5K+yR48qgITwordpL2HdpQ0+APplx8OpNnGtsxWow2p5k9uYRhtKWsK6j5OReXw7WicZRWgoQIh5K1WALJDCmxc2YqGlElAhTAdvIMtepp6JEjKo2EIQ5a8PalEhQ5EwfKEJuqsM/RD1FBG6SlEdd36rJESbreeqhqrcgingFdc1QPjC7p8snmqU8zoGKv3DpIy9xIkTsLOmLA==
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=AqK/GZgD5fpct+xudWySwwXuJ0FtVmRbDw+f9l4ru44=; b=Z5W7tumX0eky1x+iGbTMoOVgmeWH+Pd5ZM6LnRjGVU1NrL7dsVXnw/vn8fAU7MLDe7MJOmRiwq0g+oa8xUCJi3tAXKcj89n30gUPFF359PuJYg/96XZkZS8WcEdCfu6hJHvdjtGeMwDEH3z/RQno4hIndmP3PXE+xA40n7YEkTLGmhrblT/HZPS774MoQ32sE3xnvP+cItBVIM+B09Yw9JmLjJfxPQXnz9wB/NRMA1KpTLfvpYXK+qbrZGF1IKviyLuxnjh8rqwmlssYdiPMlTcg3IXNqIheI7trH9+AjoSOCVNuD54mcMvRQZ2IdxaNCykNCB1slQnqOfQrPN9YHw==
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=AqK/GZgD5fpct+xudWySwwXuJ0FtVmRbDw+f9l4ru44=; b=p4B07HvV+ko6YZ0qCPl8w7Vn5H7G9PyE2tW9uE/n2AILSozI7vRGFTS1lTEQ+jxHP8ZMq5qlKR2D+vasRNBqLQ4Sm3t6Rodh/EE/96xmvbdM0gI12sJRsrMXHEbK7s1iZjtlvmwEkuxzGsOpTzF/iWpwMIGGp3PiOB6/o578Sc8=
Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5471.namprd02.prod.outlook.com (2603:10b6:805:df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 23:35:50 +0000
Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:35:50 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Roman Danyliw' <rdd@cert.org>, 'The IESG' <iesg@ietf.org>
CC: "'draft-ietf-babel-information-model@ietf.org'" <draft-ietf-babel-information-model@ietf.org>, "'babel-chairs@ietf.org'" <babel-chairs@ietf.org>, "'babel@ietf.org'" <babel@ietf.org>, 'Donald Eastlake' <d3e3e3@gmail.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
Thread-Index: AQHWsUZg7R3CwOamn0mBtMrHTAE5sKm3CtQA
Date: Wed, 04 Nov 2020 23:35:50 +0000
Message-ID: <SN6PR02MB45126F102108D52A0C1FE6B3C3EF0@SN6PR02MB4512.namprd02.prod.outlook.com>
References: <160434187993.1575.17754543317504078999@ietfa.amsl.com>
In-Reply-To: <160434187993.1575.17754543317504078999@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=att.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [144.160.96.109]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ba234ce5-4b03-40f0-e16b-08d8811a5d37
x-ms-traffictypediagnostic: SN6PR02MB5471:
x-microsoft-antispam-prvs: <SN6PR02MB5471F7886BA0B320574AC7B6C3EF0@SN6PR02MB5471.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RZF84/Te3TZF3eEWzoUBAT675Ng64g6hj7fuyyxUFn8l9dhzJuMSB3fPevM9lrE22/vONhuTtTGIIH0PX3ue00BdYdI98GSVBsWS7utE7AOahYQSFO76BU4FXjwchFaHtzz+FeFrjTJAwelfUq1A4CLaoxZjwZTUJZC9+ZJyTRpfS1dB0ThtKsReNnlFeaLBYktyrYNloREa9mYfVjCZ90cPD5uuBrCM8BbIXfK5BQalfzNL9sCU1h3Of/2K86akgjPZQaGvBzgqyq+y73XOjlCoiJ7frXono+pGpmbR5kB7zAL19qlGMo+cbHYsTRPZG3wmaseelK8aE8sNCFa9GA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(136003)(376002)(26005)(186003)(54906003)(478600001)(66574015)(7696005)(110136005)(83380400001)(8936002)(6506007)(55016002)(64756008)(66446008)(33656002)(82202003)(4326008)(2906002)(8676002)(66556008)(66476007)(71200400001)(76116006)(9686003)(86362001)(5660300002)(52536014)(316002)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: fTz4nQlkV0RAo+TKosifv0+/r2GPDxdch/zPHVlRbChifGBk+yjhXosvtstRkplowL+QTJbdS9pv/RwlyMXihBUq2Fd9ok2NJSBtgSAYbaSdOZBuEql0cf/pg/JNjuUjNEv4DeOhl4sWD7H5KzVOKySXstA1pwoeBeVhsYRmSkpJvohfGeinGZEIIDPMdWip7vfb/rwos5CHrWwvWtOyPKb35dqGzaOIwFwyVd3u8ldT+oHES2Kh8LmzOYdWd0rT6OBSz/LIunjF/RN8XrCFeBFpasBOPcy0CZT7gt+GGYRhPW6YKBRtBzv6XHjHK3gEANIu1ILU4KFK8Og/R70/AX8S069n+tPQ7r11BzEXRLc+eMON9KtrTP/jSBPaenR2Bw3m7S2yvnyLcXNyEa4OwuImOqdiuQXYRjZFBdLNxPq9Dm9Fcgx6KG/AtKaWtO5JzO4tmYUCyd01Be+fXoXRcoGHPo4H2tJwAsSgQZ2Z/NCOMjf51QqPsQs/v+TGYru3olPFSIKVBYux54U/BUPvrYI32MZi4ov9lUmu2QhvFcjcgWV/rZoixRn9FzXgrX3n0qY7sqNk4dqMdJ4KFn15UzpebqysFNa7QhbiUFD+NK9v/K1+gABZgDxlV6+zjHIBeHykT2QTcA4AEnPQj6oi4Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba234ce5-4b03-40f0-e16b-08d8811a5d37
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:35:50.5201 (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: 8U7hfLGCLa5P0jUqbAGf/6nzY7oJBKxpw6OH8hM3vMSqSV0dlBYfNum/xxznC3+T
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5471
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 9D0E6CC031A78EEEE2E2E0D45F5CDE7D750A479CAC4CB6EDAD7244233326595A2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_17:2020-11-04, 2020-11-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 spamscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040168
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/EB2Ae0ri9MV_Cer9tlU6XY_24sk>
Subject: Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2020 23:36:11 -0000
Hi Roman, Thanks for your review (and Valery's, which I've just sent a reply to). In my reply to Valery, I indicated that I didn't quite agree with the proposed parameter name changes (which you said you did agree with). So that may need further discussion. Thanks again, Barbara > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the SECDIR review from Valery Smyslov. Please review and > respond > to the remaining items. In particular, I concur with the recommendations > about > precise language around the names of the parameters. > > Section 3.1. babel-implementation-version. Is there any guidance on the > format of this string (or is it free form like a Server: in HTTP)? It is free-form. Each implementation may choose its own version naming convention. > Section 3.1. babel-metric-comp-algorithms, babel-mac-algorithms, > babel-dtls-cert-types. Is there any guidance to provide on the delimiter > between a list of values, or is that explicitly a data model issue? That is explicitly a data model issue. BBF TR-181 does it differently from YANG. > Section 3.1. babel-security-supported, babel-mac-algorithms, > babel-dtls-cert-types. Consider providing citations on “MAC” and “DTLS”; > and > “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like > was done > for babel-metric-comp-algorithms). For MAC, HMAC-SHA256, and BLAKE2s I will include reference to ID.draft-ietf-babel-hmac For DTLS, X.509, and RawPublicKey I will include reference to ID.draft-ietf-babel-dtls These are the drafts that define these terms in the context of Babel and provide further references to the specifications that more completely define them. > Section 3.8. babel-mac-key-value. > > If the algorithm is based on the HMAC construction > [RFC2104], the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 > bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", > the length MUST be between 0 and 32 bytes inclusive, as described > in [RFC7693]. > > I was under the impression that this was an information model to encode > generic > Babel protocol parameter and that the underlying protocol documents fully > specified the normative behavior. However, this guidance appears to be > introducing more restrictive configuration guidance not found in > draft-ietf-babel-hmac making this document an information model + profile. > Was > this intentional? Per RFC2104 Section 2, "The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC." When comparing implementations of babel-hmac with HMAC-SHA256, the WG discovered variability in the "actual key" that resulted from using keys longer than B bytes. The cause of the variability was in the user interface accepting the input string, and not in the actual babel-hmac implementation. Standard library functions were being used for HMAC algorithm and for the UI allowing key entry. Since the user interface is effectively an instantiation of the information model, the group agreed that the information model should impose a restriction on the input string that guaranteed interoperability by ensuring the provided string did not have to be hashed to calculate the "actual key". Per section 2.1 in RFC 7693, Key Bytes for BLAKE2s are "0 <= kk <= 32". Since this is the key length specified by the BLAKE2s RFC, the information model is imposing exactly this length restriction on the key input parameter. RFC 7693 is normative to draft-ietf-babel-hmac. > Section 3.8 and 3.9. babel-mac-key-test and babel-cert-test. It would be > useful to explain the use case for this testing API. One of the most common problems in configuring security mechanisms is in the format of the input key (hex, ASCII, base64, etc.). When a security mechanism fails to work, it is important for users to be able to trouble-shoot this specific point of failure. This test allows the user to see if what this device think the hash should be is the same as what another device thinks the hash should be or is the same as the hash being sent on the wire. Many ISPs have built a test like this into their ISP-supplied CE routers (invoked using the TR-069 protocol and TR-181 data model). > Section 5. Note that operations are also exposed in the information model. > > OLD > This document defines a set of information model objects and > parameters that may be exposed to be visible from other devices > > NEW > This document defines a set of information model objects, parameters, and > operations that may be exposed to be visible from other devices I'll make this change. > Section 5. Per: > > MAC keys are allowed to be as short as zero-length. This is useful > for testing. Network operators are advised to follow current best > practices for key length and generation of keys related to the MAC > algorithm associated with the key. Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. > > Add clarifying text that the information model explicitly enables this brute > force attack where most of the workload is pushed onto the server (since it > computes the hash). Also add a mitigation. Perhaps something like “This > information model provides an oracle via the babel-mac-key-test operation > that > would enable such a brute force attack. Operators SHOULD rate limit access > to > this operation.” I'm struggling with this comment in several ways. - In most expected instantiations of the information model (a user interface, BBF TR-181, YANG), and in the context of the protocols that transport and interpret these data models (HTTPS, TR-069/TR-369, NETCONF/RESTCONF), "operators" have little to no ability to rate limit specific operations -- unless they are the actual implementers of the management protocols. In the context of, for example, a person configuring their own home network, the only way the "operator" rate limits this is by deciding how frequently they push the button. If an ISP is managing the home network router via TR-069/TR-369, it's unlikely the ISP can rate limit through any means other than code implementation. If rate limiting is to be done via the implementation, then the advice should target implementers. It's common for managed devices to rate limit execution of various operations. - Having access to this operation implies the person has permission to manage the router. If someone has permission to manage the router (and permission to invoke this operation) and really wants to see what happens if they repeatedly push the button, I'm not sure I agree that IETF should be suggesting this person should do things to rate limit their personal access to this function. - I don't completely understand "the workload is pushed onto the server (since it computes the hash)". Babel has no servers. In NETCONF/RESTCONF model, I think the managed device is referred to as the server? I'm not a NETCONF/RESTCONF expert. But is that the server you're thinking of? In BBF protocols, there's not a strong client/server concept, and more just "managed device" and "management system" or "Agent" and "Controller". But if I assume "server" is referring to the "managed router", then I think your point is that this test requires the managed router to compute a MAC every time the test is run (which can impact router performance, especially if the test is repeatedly invoked). ? If the goal is to determine the key by brute force, I would think they would primarily need a powerful system that could compute MACs for a known input string using iterative key value guesses. It should only require a single computation of the MAC for that input string from the router. Once the powerful system has a match, perhaps the attacker would want to try a different input string with to see if the MAC for that also matches, using its guessed key. But I don't see using this test to be an efficient brute force mechanism, since the attacker would still have to compute a MAC on their end (for comparison) with each test. It would be always be slower than just using the output of a single test to iterate against. Of course, if the attacker can capture Babel packets on the wire with MACs, this would provide them with equally usable samples to iterate against. So I don't really see the potential threat from repeated execution of tests as being a brute force attack, but rather a denial of service attack. But I'm no security expert, so maybe I'm just not understanding how these things work. Are multiple MAC samples needed (computed from different input strings) for a successful brute force attack? If so, how many are needed? I agree that there could be a statement about impacts of MAC computation to device performance that could seriously impact the ability of the router to route, and that Babel information model implementations should rate limit the execution of this test. But I think the normative statement targeting implementers would be better placed in the parameter description. I propose, in the Security Considerations section, add (after paragraph on key exposure): "The babel-mac-key-test operation requires the device to compute the MAC every time it is executed. If this operation is executed frequently, it could degrade the device performance and effectively act as a Denial of Service attack. This is the reason this parameter's description recommends rate limiting execution of the operation." In the babel-mac-key-test description add "The implementation SHOULD rate limit execution of this operation to avoid degrading router performance." -
- [babel] Roman Danyliw's No Objection on draft-iet… Roman Danyliw via Datatracker
- Re: [babel] Roman Danyliw's No Objection on draft… STARK, BARBARA H