Re: [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
"Douglas Gash (dcmgash)" <dcmgash@cisco.com> Mon, 27 January 2020 20:28 UTC
Return-Path: <dcmgash@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE383A0BDE; Mon, 27 Jan 2020 12:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g+4RPQOC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=b+nGcapw
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 HnchMTpBCInY; Mon, 27 Jan 2020 12:28:36 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FC43A0BDD; Mon, 27 Jan 2020 12:28:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19612; q=dns/txt; s=iport; t=1580156916; x=1581366516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XJxdX6boZZaLe+6YJYog0u0EBQBkMeuv46Wa3W8h1v0=; b=g+4RPQOCNJFCAxn5FAuryP8QZ04+nA4TiT2e9bojSKDUOCFMQ3oliP5O EuF+9GQncZtTHKTUjOPU6qsrieR4NnuHI8kvbPqzdNRSHlUGPmg9lKBSp ZnvC86FL30AtHpwjspQL93WeDQSfxHBV8qihdgRbnwK7Oa4e3dW4Fu+y6 A=;
IronPort-PHdr: 9a23:ur0Q9RTnw6wEVYewQHTGeVjtCdpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiAxGctLT19N9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CQBQDtRi9e/4QNJK1dCRwBAQEBAQcBAREBBAQBAYF7gVRQBYFEIAQLKoQUg0YDixOaboFCgRADVAkBAQEMAQEtAgEBhEACF4INJDgTAgMNAQEEAQEBAgEFBG2FCwgkDIVfAgEDDgQRBA0MAQEjFAEPAgEIDgwCJgICAjAVEAIEAQ0ngwSCSwMuAQKiBAKBOYhhdX8zgn8BAQWFExiCDAmBDiqJVYJJGoIAgREnIIFOfj6EHxICFoMQMoIsjU4IBgEDgnWGAoIhlW52CoI5jQaJMRuCSIgKBYRAi2WOYIFKmUMCBAIEBQIOAQEFgWkigVhwFTsqAYJBUBgNj06EHgcCGhWDO4pSAXSBKYxjAQE
X-IronPort-AV: E=Sophos;i="5.70,371,1574121600"; d="scan'208";a="713402411"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jan 2020 20:28:34 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 00RKSY4q013900 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jan 2020 20:28:34 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 14:28:34 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 15:28:33 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 Jan 2020 14:28:32 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EYbFugjKhzqIgu6nhzRQjfNGWNygN8+MEx9SE5C+7te4+367nSN47N+QiYNFIKmgOPEdbnYv99ZouUhoKE72bwseFVSrs6rWwCVcbBlBeKvi5IxvKRkBBUDyrpA/A0F/9edWVTwBC+kL4VaFTW89CisMP+bg5t2dYsqxgCC6MLxJvjjsSkVQyYnEykngNQa/iNDtoj5g/wFxPF9hz+rWGrHWRT9QYiGVEEVSrESqDVIKt3u6nGHm+y/RPQ4PKKfK87X1MyTbj/puWxaeyOL1+bBmZzpuztfcL7xB7KuRLVBY31cj7rUSZPeDjfMgCfd4gFGnGWPEZTdJj+r/Vm2pIw==
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=XJxdX6boZZaLe+6YJYog0u0EBQBkMeuv46Wa3W8h1v0=; b=mfvKWjDg0WQEWKuWci1uC1WFVEC57iatjljfcq2QcinKyAPueZC5cf/DGgnp5ziTvyN2vHSdLCE98CL5N0kiQRFgrwh0LOPMNc3QpDAUmo5M92nMCdS308WTtqGyr14z1/QIDOKpsHg2xNFE0blvNj+1U8anA3YlJxJ7JRFCtW0Z1kRgF5SlxJHR5h0bUJnt/Sds3wL58N6uUoSqOEi5HonVQou3vSqnCCFmvcl7T8+rRdkQGYPPYCLDSRnGxFYeHtTtbPaDrkhm6cqUbslltekJb6r5iyE8xdNSV2RrMSEIq6a6IlYsPjyU57iRVOKoQK6DjogB6f8FTNEcbwNEXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XJxdX6boZZaLe+6YJYog0u0EBQBkMeuv46Wa3W8h1v0=; b=b+nGcapwWvQqm5PsZB9DRMV9t88VMBycHlDryVMOUvWRDOG7xt4LSz2KCxlOp5/pdXWqB/x9CQGJy4mGfs4CWMkbCec4u1pTnFL25cR9q0pymoBZVtEe3b/e7FpShEHIwSPl5uYEOBNL4vYhTPsgXR/QMoXv/7RSG9z3vqOz3VY=
Received: from MN2PR11MB4190.namprd11.prod.outlook.com (20.179.151.223) by MN2PR11MB3902.namprd11.prod.outlook.com (10.255.180.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Mon, 27 Jan 2020 20:28:31 +0000
Received: from MN2PR11MB4190.namprd11.prod.outlook.com ([fe80::d03a:678e:544a:d253]) by MN2PR11MB4190.namprd11.prod.outlook.com ([fe80::d03a:678e:544a:d253%7]) with mapi id 15.20.2665.017; Mon, 27 Jan 2020 20:28:31 +0000
From: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-opsawg-tacacs@ietf.org" <draft-ietf-opsawg-tacacs@ietf.org>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Thread-Index: AQHV1VBWMs0jEhQykkWaGlNOLqM3Rw==
Date: Mon, 27 Jan 2020 20:28:31 +0000
Message-ID: <93780B8A-40AB-43DF-899E-34DA47E0807C@cisco.com>
References: <155798766808.30465.13613903853679159439.idtracker@ietfa.amsl.com>
In-Reply-To: <155798766808.30465.13613903853679159439.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dcmgash@cisco.com;
x-originating-ip: [2001:420:c0c0:1008::27a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 25d889ea-bb00-4cc9-8ff0-08d7a36779da
x-ms-traffictypediagnostic: MN2PR11MB3902:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB3902508A8DCC1DF5D31D105EB70B0@MN2PR11MB3902.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02951C14DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(136003)(366004)(346002)(189003)(199004)(186003)(8676002)(316002)(110136005)(54906003)(2616005)(4326008)(6512007)(6486002)(2906002)(66946007)(8936002)(6506007)(64756008)(66556008)(66446008)(66476007)(33656002)(76116006)(478600001)(91956017)(81166006)(81156014)(86362001)(36756003)(5660300002)(71200400001)(30864003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3902; H:MN2PR11MB4190.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: smKZmPH5w+5P8R+MqPNlKKsJ6XYMyLUFyiLdEsPEWTjSWYyTWXhFXVsPk39weUoVhWB35egE2pXxtRAL/1kgXFzmUv7gnJWdGmooVh5eAMw8auwf9yzY5ez830qqok342NDrPsT4P+QhLJqltvnMRuI0eQoc/Mn2tq8G6Lpm9B2FGs3+cr7pjBaakACCeSZAGH5Z2h3KL1dremBJa5SVmxqR2sUMhlWbtaZ2V/QJuDxuzfPgkkAWVfVXkpXKbKgkYxwZCCXwvjWUMnPiHE7T5gCBl7HyZUKQ5457vcUEe6BwelebP6l8kN2ciAGnyuMcHLVtZTGRiWKaRZm8O2HmRMYtnSu9YUyRxohOnpIECQICiWzbP8Bz28NwmU5MSVNUSGsVJ5MWcrz46vscyr9IZUJx+H/vU3x6BeimAThwk6qkFQeIc7TESQZPXmDF3UJw
x-ms-exchange-antispam-messagedata: vx7oHTJyWQPqzwatU6+K9EBwVaCqp5UE278JbT0LDmhPA0j/T0Io1n5nmr/A3wjgdZHaa67hKbW1v0wONCfsH/NrkPa23DT2xot/+wH1Y3rFpOBCMiwJ9D9BXylFOS7PHLiaFE2JhBaYJSTAG60QmtJTnm26/iLwajFfy5hfZ40=
Content-Type: text/plain; charset="utf-8"
Content-ID: <AD94F48173AA2E44A417558F643713BA@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 25d889ea-bb00-4cc9-8ff0-08d7a36779da
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 20:28:31.6271 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L8uWLaKSNLho4aq90Z/zaQl7tRrW5BDi490y703+hiZmwmDb47vQYVjuBdy2EQT9rtuz2H55N/Wgxi1nsB1XlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3902
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/6cI8sGvnRPCp65i-FAdXmbvYCXA>
Subject: Re: [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2020 20:28:39 -0000
Hi, I hope that in the last few versions we have updated the document to sufficiently answer the concerns raised, please let me know if any concerns remain, many thanks. The majority of the issues were responded to initially last summer, but the balance should be by the latest version recently uploaded. Please see the point-by point descriptions of changes or responses. Many thanks, 1) 4.6. Text Encoding All text fields in TACACS+ MUST be printable US-ASCII, excepting Please add a reference to RFC 20 (for US-ASCII) here. Without out it "printable" has no meaning. TA> Agreed, will update as advised [AI=TA] Specifically: "3.7. Treatment of Text Strings The TACACS+ protocol makes extensive use of text strings. The original draft intended that these strings would be treated as byte arrays where each byte would represent a US-ASCII character. More recently, server implementations have been extended to interwork with external identity services, and so a more nuanced approach is needed. Usernames MUST be encoded and handled using the UsernameCasePreserved Profile specified in RFC 8265 [RFC8265]. The security considerations in Section 8 of that RFC apply. Where specifically mentioned, data fields contain arrays of arbitrary bytes as required for protocol processing. These are not intended to be made visible through user interface to users. All other text fields in TACACS+ MUST be treated as printable byte arrays of US-ASCII as defined by RFC 20 [RFC0020]. The term "printable" used here means the fields MUST exclude the "Control Characters" defined in section 5.2 of RFC 20 [RFC0020]." special consideration given to user field and data fields used for passwords. To ensure interoperability of current deployments, the TACACS+ client and server MUST handle user fields and those data fields used for passwords as 8-bit octet strings. The deployment operator MUST ensure that consistent character encoding is applied from the end client to the server. The encoding SHOULD be UTF-8, and other Please add Normative RFC 3629 reference here for UTF-8. TA> Agreed, will update as advised [AI=TA] Specifically: Have removed all references to UTF-8. encodings outside printable US-ASCII SHOULD be deprecated. I am not sure what this mean. You didn't define allowed encoding (really you mean charsets). TA> Agreed, will update as advised [AI=TA] Specifically: removed UTF-8, pleasee see ref to sectipn 3.7 above. 2) In 5.1: The printable US-ASCII name of the client port on which the authentication is taking place, This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this. Is it a fixed list? TA> Please see new sectin 3.7 above. and its length in bytes. The value of this field is client specific. (For example, Cisco uses "tty10" to denote the tenth tty line and "Async10" to denote the tenth async interface). The port_len indicates the length of the port field, in bytes. 3) Later in 5.1: A printable US-ASCII string indicating the remote location from which the user has connected to the client. It is intended to hold a network address What are the allowed formats for IPv4 and IPv6? Or is this just human readable? TA> Current practice the field is normally MAC address or IP. Will recommend that if IP is used, it SHOULD conform to RFC5952 [AI=TA] Specifcially, added text: " For IPv6 address text representation defined please see RFC 5952 [RFC5952]." if the user is connected via a network, a caller ID is the user is connected via ISDN or a POTS, or any other remote location information that is available. 4) In 5.4: If the information being requested by the server form the client is sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO flag. When the client queries the user for the information, the response MUST NOT be echoed as it is entered. What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing? TA> Agreed, this requires clarification in document to indicate that the data entered should not be reflected in the user interface. [AI=TA] Specifically: Section 5.4., paragraph 5: OLD: If the information being requested by the server form the client is sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO flag. When the client queries the user for the information, the response MUST NOT be echoed as it is entered. NEW: If the information being requested by the server form the client is sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO flag. When the client queries the user for the information, the response MUST NOT be reflected in the user interface as it is entered. 5) KRB5 and KRB4 need normative references. TA> The KRB5 and KRB4 are not specifically used in this document, rather, there is one field with an option that the client uses to indicate how it authenticated, and these are option. This is not verifiable, so it is recomended in the documen tnot to use this field for policy.For this reason, it is not really useful to provide a normative reference, but it is required for the document to explai this. So have added:[AI+TA] 6) Does this document need to obsolete RFC 1492? TA> That could well be sensible, would follow WG consensus here. After review, the differences between TACACS and TACACS+indicated that the protocols were sufficiently different that TACACS+ does not directly obsoltere plain TACACS, ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 4.8: 4.8. The TACACS+ Packet Header The total length of the packet body (not including the header). In network byte order? There is some text about that in 4.9, but readers don't know that yet. TA> Agreed, will clarify [AI=TA] Specifcially in 4.1: " The following general rules apply to all TACACS+ packet types: - To signal that any variable length data fields are unused, their length value is set to zero. Such fields MUST be ignored, and treated as if not present. - the lengths of data and message fields in a packet are specified by their corresponding length fields, (and are not null terminated.) - All length values are unsigned and in network byte order." In 6.1: The arguments are the primary elements of the authorization interaction. In the request packet they describe the specifics of the authorization that is being requested. Each argument is encoded in the packet as a single arg filed (arg_1... arg_N) with a Typo: filed --> field. TA> Thanks, will correct. [AI=TA] "Section 6.1., paragraph 29: OLD: The arguments are the primary elements of the authorization interaction. In the request packet they describe the specifics of the authorization that is being requested. Each argument is encoded in the packet as a single arg filed (arg_1... arg_N) with a corresponding length fields (which indicates the length of each argument in bytes). NEW: The arguments are the primary elements of the authorization interaction. In the request packet, they describe the specifics of the authorization that is being requested. Each argument is encoded in the packet as a single arg field (arg_1... arg_N) with a corresponding length fields (which indicates the length of each argument in bytes)." corresponding length fields (which indicates the length of each argument in bytes). Later in the same section: Optional arguments are ones that may be disregarded by either client or server. Mandatory arguments require that the receiving side can handle the attribute, that is: its implementation and configuration includes the details of how to act on it. If the client receives a mandatory argument that it cannot handle, it MUST consider the authorization to have failed. It is legal to send an attribute-value pair with a zero length value. Last sentence: do you just mean that the value can be empty? TA> Yes, this definition evolved, also had query about the use of the word “legal” in this round of review. Will change to “The value part of an attribute-value pair may be empty, that is, the length of the value may be zero.” [AI=TA] Specifically: Section 6.1., paragraph 32: OLD: Optional arguments are ones that may be disregarded by either client or server. Mandatory arguments require that the receiving side can handle the attribute, that is: its implementation and configuration includes the details of how to act on it. If the client receives a mandatory argument that it cannot handle, it MUST consider the authorization to have failed. It is legal to send an attribute-value pair with a zero length value. NEW: Optional arguments are ones that may be disregarded by either client or server. Mandatory arguments require that the receiving side can handle the argument, that is: its implementation and configuration includes the details of how to act on it. If the client receives a mandatory argument that it cannot handle, it MUST consider the authorization to have failed. The value part of an argument-value pair may be empty, that is: the length of the value may be zero. In 8.1: Date Time Absolute date/times are specified in seconds since the epoch, 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is specified. Stardate is canonically inconsistent and so SHOULD NOT be used. I am not sure what the last sentence means. TA> Agree, will be removed [AI=TA] In 8.2: 8.2. Authorization Attributes For example: "shell", "tty-server", "connection", "system" and "firewall". This attribute MUST always be included. Is this a full list or is there a registry? TA> This is not a full list, it is just for example. In order to prevent interpretation that it is a full list, will change to [AI=TA]: “The primary service. Specifying a service attribute indicates that this is a request for authorization or accounting of that service. For example: "shell". This attribute MUST always be included.” Specifically: Section 8.1., paragraph 15: OLD: The primary service. Specifying a service attribute indicates that this is a request for authorization or accounting of that service. For example: "shell", "tty-server", "connection", "system" and "firewall". This attribute MUST always be included. NEW: The primary service. Specifying a service argument indicates that this is a request for authorization or accounting of that service. For example: "shell", "tty-server", "connection", "system" and "firewall", others may be chosen for the required application. This argument MUST always be included. Later in the same section: remote_host (String) What is the syntax of this field? TA> Will remove this definition. [AI=TA] 10.4. Security of Accounting Sessions Replace accounting data with new valid or garbage which prevents to provide distraction "prevents to provide distraction" doesn't read well. TA> Agreed, will attempt to translate into readable language! [AI=TA] Specifcially: "Section 10.4., paragraph 2: OLD: Replace accounting data with new valid or garbage which prevents to provide distraction or hide information related to their authentication and/or authorization attack attempts. NEW: Replace accounting data with new valid or garbage which can confuse auditors or hide information related to their authentication and/or authorization attack attempts. " or hide information related to their authentication and/or authorization attack attempts. In 10.5.1: TACACS+ server administrators SHOULD change secret keys at regular intervals. Humans are very bad at this. So I think it would be better if this is changed to add a requirement on management UIs. TA> That is sensible. Will discuss options with WG. [AI=TA] Generlised the advise for the section, i.e. added: "Vendors SHOULD provide mechanisms to assist the administrator to achieve these best practices." 10.5.3. Authentication To help TACACS+ administraots select the stronger authentication Typo: administrators. TA> Thanks, will correct. [AI=TA] Specifically: "Section 10.5.3., paragraph 1: OLD: To help TACACS+ administraots select the stronger authentication options, TACACS+ servers MUST allow the administrator to configure the server to only accept challenge/response options for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). NEW: To help TACACS+ administrators select less weak authentication options, TACACS+ servers MUST allow the administrator to configure the server to only accept challenge/response options for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type)."
- [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-… Alexey Melnikov via Datatracker
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Douglas Gash (dcmgash)
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Douglas Gash (dcmgash)
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Warren Kumari
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Alexey Melnikov
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Joe Clarke (jclarke)
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Warren Kumari
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Warren Kumari
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Alexey Melnikov
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Warren Kumari
- Re: [OPSAWG] Alexey Melnikov's Discuss on draft-i… Douglas Gash (dcmgash)