From nobody Tue May 2 22:11:14 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE81A1316E8 for ; Tue, 2 May 2017 06:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 84G1bxGzdVVC for ; Tue, 2 May 2017 06:44:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D071314DE for ; Tue, 2 May 2017 06:40:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2A74EB80E97; Tue, 2 May 2017 06:40:27 -0700 (PDT) To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, bclaise@cisco.com, warren@kumari.net, lionel.morand@orange.com, stefan.winter@restena.lu X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: andrew.feren@plixer.com, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170502134027.2A74EB80E97@rfc-editor.org> Date: Tue, 2 May 2017 06:40:27 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Tue, 02 May 2017 22:11:13 -0700 Subject: [radext] [Technical Errata Reported] RFC8045 (5009) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:44:33 -0000 The following errata report has been submitted for RFC8045, "RADIUS Extensions for IP Port Configuration and Reporting". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/rfc8045/eid5009 -------------------------------------- Type: Technical Reported by: Andrew Feren Section: 7.1 Original Text ------------- o sourceTransportPortsLimit: * Name: sourceTransportPortsLimit * Element ID: 458 * Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This Information Element is particularly useful in address-sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address-sharing device in order to grab more ports. * Data type: unsigned16 * Data type semantics: totalCounter Corrected Text -------------- o sourceTransportPortsLimit: * Name: sourceTransportPortsLimit * Element ID: 458 * Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This Information Element is particularly useful in address-sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address-sharing device in order to grab more ports. * Data type: unsigned16 * Data type semantics: quantity Notes ----- Only change is * Data type semantics: totalCounter to * Data type semantics: quantity The description is pretty clear that this IE is a maximum value and not a counter. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8045 (draft-ietf-radext-ip-port-radius-ext-17) -------------------------------------- Title : RADIUS Extensions for IP Port Configuration and Reporting Publication Date : January 2017 Author(s) : D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue May 2 22:11:20 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DCA12EC45; Tue, 2 May 2017 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 NLF1eNAd1QGV; Tue, 2 May 2017 07:05:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD8312EC9C; Tue, 2 May 2017 07:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3737; q=dns/txt; s=iport; t=1493733659; x=1494943259; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WkAGZWInA5n8zwB+bY5CoMEVhDkOaU3TXxoIK2JJMdk=; b=Qtfp53DQe+NhCI3RPvjkZrjE4xuDqze0ukcY+R9SMeY+Xr3cQXLFzRel tvcq4cO8cQIrP2BmTVcCZrq+BZl4xO068FspI6JLCxaW1FY0Xd1IV1koS LfqAmu30WuK0tK8Iqx51YeljrLzWsDWyDQZ0QwjMue/f0d7zysczG+Pux I=; X-IronPort-AV: E=Sophos;i="5.37,405,1488844800"; d="scan'208";a="651563098" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 14:00:57 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v42E0u9Z025508; Tue, 2 May 2017 14:00:56 GMT To: "ie-doctors@ietf.org" , dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, warren@kumari.net, lionel.morand@orange.com, stefan.winter@restena.lu References: <20170502134027.2A74EB80E97@rfc-editor.org> Cc: andrew.feren@plixer.com, radext@ietf.org, Benoit Claise From: Benoit Claise Message-ID: <53aed9b5-6e8c-3891-1561-e1fcd2a60ba8@cisco.com> Date: Tue, 2 May 2017 16:00:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502134027.2A74EB80E97@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 02 May 2017 22:11:13 -0700 Subject: Re: [radext] [Technical Errata Reported] RFC8045 (5009) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:05:07 -0000 Hi, [removing the rfc-editor and copying the IPFIX IE doctors] If this errata is accepted by the IPFIX IE doctors, we would have to change the IANA registry https://www.iana.org/assignments/ipfix/ipfix.xhtml So we would have to go for a new IPFIX IE revision, according to the procedure in https://tools.ietf.org/html/rfc7013#section-5.2 Regards, B. > The following errata report has been submitted for RFC8045, > "RADIUS Extensions for IP Port Configuration and Reporting". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/rfc8045/eid5009 > > -------------------------------------- > Type: Technical > Reported by: Andrew Feren > > Section: 7.1 > > Original Text > ------------- > o sourceTransportPortsLimit: > > * Name: sourceTransportPortsLimit > > * Element ID: 458 > > * Description: This Information Element contains the maximum > number of IP source transport ports that can be used by an end > user when sending IP packets; each user is associated with one > or more (source) IPv4 or IPv6 addresses. This Information > Element is particularly useful in address-sharing deployments > that adhere to REQ-4 of [RFC6888]. Limiting the number of > ports assigned to each user ensures fairness among users and > mitigates the denial-of-service attack that a user could launch > against other users through the address-sharing device in order > to grab more ports. > > * Data type: unsigned16 > > * Data type semantics: totalCounter > > Corrected Text > -------------- > o sourceTransportPortsLimit: > > * Name: sourceTransportPortsLimit > > * Element ID: 458 > > * Description: This Information Element contains the maximum > number of IP source transport ports that can be used by an end > user when sending IP packets; each user is associated with one > or more (source) IPv4 or IPv6 addresses. This Information > Element is particularly useful in address-sharing deployments > that adhere to REQ-4 of [RFC6888]. Limiting the number of > ports assigned to each user ensures fairness among users and > mitigates the denial-of-service attack that a user could launch > against other users through the address-sharing device in order > to grab more ports. > > * Data type: unsigned16 > > * Data type semantics: quantity > > Notes > ----- > Only change is > > * Data type semantics: totalCounter > to > * Data type semantics: quantity > > The description is pretty clear that this IE is a maximum value and not a counter. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8045 (draft-ietf-radext-ip-port-radius-ext-17) > -------------------------------------- > Title : RADIUS Extensions for IP Port Configuration and Reporting > Publication Date : January 2017 > Author(s) : D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar > Category : PROPOSED STANDARD > Source : RADIUS EXTensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > From nobody Tue May 9 08:59:41 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C8512E059 for ; Tue, 9 May 2017 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RDsmw1lhtpzT for ; Tue, 9 May 2017 08:59:38 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8E97B126C22 for ; Tue, 9 May 2017 08:59:38 -0700 (PDT) Received: from [192.168.20.197] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 6685637F for ; Tue, 9 May 2017 15:59:37 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 9 May 2017 11:59:35 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Question about CoA-Request and Tunnel-Password X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:59:40 -0000 I think there's an issue with CoA-Request and Tunnel-Password RFC 5176 Section 2.3 says: Request Authenticator In Request packets, the Authenticator value is a 16-octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting-Request, specified in [RFC2866]. Where RFC 2866 Section 3 says: The NAS and RADIUS accounting server share a secret. The Request Authenticator field in Accounting-Request packets contains a one- way MD5 hash calculated over a stream of octets consisting of the Code + Identifier + Length + 16 zero octets + request attributes + shared secret (where + indicates concatenation). The 16 octet MD5 hash value is stored in the Authenticator field of the Accounting-Request packet. This means that for CoA-Request packets, all attribute obfuscation = is calculated with the Reply Authenticator being all zeroes. RFC 5176 Section 3.6 allows for Tunnel-Password in CoA-Request = packets: ... Change-of-Authorization Messages Request ACK NAK # Attribute ... 0+ 0 0 69 Tunnel-Password (Note 5) ... (Note 5) When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attributes are included within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s). However, RFC 2868 Section 3.5 says that Tunnel-Password is encrypted = with the Request Authenticator: ... Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, ... The assumption that the Request Authenticator is random data is true = for Access-Request packets. It's not true for CoA-Request packets i.e. when the Tunnel-Password attribute is used in CoA-Request = packets, the *only* randomness in the encryption is the salt. Again, = RFC 2868 Section 3.5 says: Salt The Salt field is two octets in length and is used to ensure the uniqueness of the encryption key used to encrypt each instance of the Tunnel-Password attribute occurring in a given Access-Accept packet. The most significant bit (leftmost) of the Salt field MUST be set (1). The contents of each Salt field in a given Access-Accept packet MUST be unique. =20 Which means that there's only 15 bits of entropy in the = Tunnel-Password obfuscation (plus the secret). I don't think this is a serious issue, given that the secret is used = to obfuscate the Tunnel-Password. But it can't be a good thing. Since this hasn't been brought up before in RADEXT, I thought I'd make = a note. Alan DeKok. From nobody Tue May 9 17:35:26 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4212EAC3 for ; Tue, 9 May 2017 17:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nfbIfxRZfwhe for ; Tue, 9 May 2017 17:35:23 -0700 (PDT) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D18B124217 for ; Tue, 9 May 2017 17:35:23 -0700 (PDT) Received: by mail-yb0-x241.google.com with SMTP id 19so606029ybl.2 for ; Tue, 09 May 2017 17:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=QZFYxRSgxh83jq08RXfI9rTzUhJLkUngPk6auoCzd4Y=; b=Ku5P+E1kelk0Sh9wZ7A7Nm4ZOfIOh3coOYaItMiUGmVOlXJ+rVtoXbHw8IcJ7hhp5A GkIMI6/+yzNIDPFVPYd5qnhp3x+8oeCHG9JuPHAR0xyDmn8zBY+OLUV6+UC0G4lEDHvD TI+YVip9ffS648vidUPT4q9n4kicAk0KRbUNjThvyC/RmUeMQYEDYlW9da39Kq8N95OQ elfe2q0xO3aMK26q/mxC9tVcie+V6B+t1Vv/mPguO3h5WzJjlw/j5puSBDLX2ZJ/+NKb cWXrs23ZS/TvA9YM/2UOXL/CaL5j7cS+tYZwHw1BWTw7pSrxe5Zfg6xuhwq6mFVX074f PARA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=QZFYxRSgxh83jq08RXfI9rTzUhJLkUngPk6auoCzd4Y=; b=EPX71yvutYl24imb8HG7DC1yzl7AlzEsU9+2XxcBAlUt23mcOU6+n1uIE+lwED8fM4 EFSjZYcpnFTaVzHoEvR8SBu/y2SjlurlDeAoUkFBzfVOWrrNgd8XCgbhzZ+2k1UxC03D 6WoFuFDdqv9Qi0trgA3FP6ACEgrlH3bVgFUC8Sg5GIj8tJXt5pwZfcsMI0pvHr6szqTv Q3rc20S55LTA6C3UyhOQ42iVZQN+I5QPmKtAvISJcYb4qGjgxWLHCwy3+Jqf4K0Voi1r K7r9nhSe6WPLfUrQ8vsuEQOsAfuH3HYb9cUL1admZ0TOGXTVaOGvzWrQcvZW0PlOx5OL al2w== X-Gm-Message-State: AODbwcCSAhhJJK1FV0etaQNQWyKkAEUnxvdUjIhgzpyWY3Vq/Jgs8c/6 rEJGN5LulAWuPMZ5Oi4= X-Received: by 10.37.248.37 with SMTP id u37mr2724236ybd.168.1494376522200; Tue, 09 May 2017 17:35:22 -0700 (PDT) Received: from [10.108.163.113] (mobile-166-172-186-229.mycingular.net. [166.172.186.229]) by smtp.gmail.com with ESMTPSA id d6sm726934ywc.22.2017.05.09.17.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 17:35:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Tue, 9 May 2017 20:30:00 -0400 Message-Id: <9F6FAC17-FEBE-4864-8D50-BE62C40C1D61@gmail.com> References: Cc: radext@ietf.org In-Reply-To: To: Alan DeKok X-Mailer: iPhone Mail (14E304) Archived-At: Subject: Re: [radext] Question about CoA-Request and Tunnel-Password X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 00:35:25 -0000 Yeah, this is an instance where RADIUS's lame security is even "lamerer". Do= es anyone still use Tunnel-Password? Makes me wonder if enough evidence has accrued to justify declaring RADIUS s= ecurity deprecated and recommend a replacement. =20 > On May 9, 2017, at 11:59 AM, Alan DeKok wrote:= >=20 > I think there's an issue with CoA-Request and Tunnel-Password >=20 > RFC 5176 Section 2.3 says: >=20 > Request Authenticator >=20 > In Request packets, the Authenticator value is a 16-octet MD5 > [RFC1321] checksum, called the Request Authenticator. The > Request Authenticator is calculated the same way as for an > Accounting-Request, specified in [RFC2866]. >=20 > Where RFC 2866 Section 3 says: >=20 > The NAS and RADIUS accounting server share a secret. The Request > Authenticator field in Accounting-Request packets contains a one- > way MD5 hash calculated over a stream of octets consisting of the > Code + Identifier + Length + 16 zero octets + request attributes + > shared secret (where + indicates concatenation). The 16 octet MD5 > hash value is stored in the Authenticator field of the > Accounting-Request packet. >=20 > This means that for CoA-Request packets, all attribute obfuscation is c= alculated with the Reply Authenticator being all zeroes. >=20 > RFC 5176 Section 3.6 allows for Tunnel-Password in CoA-Request packets: >=20 > ... > Change-of-Authorization Messages >=20 > Request ACK NAK # Attribute > ... > 0+ 0 0 69 Tunnel-Password (Note 5) > ... > (Note 5) When included within a CoA-Request, these attributes > represent an authorization change request. Where tunnel attributes > are included within a successful CoA-Request, all existing tunnel > attributes are removed and replaced by the new attribute(s). >=20 >=20 > However, RFC 2868 Section 3.5 says that Tunnel-Password is encrypted with= the Request Authenticator: >=20 > ... > Call the shared secret S, the pseudo-random 128-bit Request > Authenticator (from the corresponding Access-Request packet) R, > ... >=20 > The assumption that the Request Authenticator is random data is true for A= ccess-Request packets. It's not true for CoA-Request packets >=20 > i.e. when the Tunnel-Password attribute is used in CoA-Request packets, t= he *only* randomness in the encryption is the salt. Again, RFC 2868 Section= 3.5 says: >=20 > Salt > The Salt field is two octets in length and is used to ensure the > uniqueness of the encryption key used to encrypt each instance of > the Tunnel-Password attribute occurring in a given Access-Accept > packet. The most significant bit (leftmost) of the Salt field > MUST be set (1). The contents of each Salt field in a given > Access-Accept packet MUST be unique. >=20 >=20 > Which means that there's only 15 bits of entropy in the Tunnel-Password o= bfuscation (plus the secret). >=20 > I don't think this is a serious issue, given that the secret is used to o= bfuscate the Tunnel-Password. But it can't be a good thing. >=20 > Since this hasn't been brought up before in RADEXT, I thought I'd make a n= ote. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue May 9 18:36:55 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5112EBA9 for ; Tue, 9 May 2017 18:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5858PqbQj5Op for ; Tue, 9 May 2017 18:36:52 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 70B9112EBAA for ; Tue, 9 May 2017 18:36:52 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 5E6B8CD5; Wed, 10 May 2017 01:36:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <9F6FAC17-FEBE-4864-8D50-BE62C40C1D61@gmail.com> Date: Tue, 9 May 2017 21:36:50 -0400 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23BFFA8D-0B95-4EE7-B977-75BD902BBBEB@deployingradius.com> References: <9F6FAC17-FEBE-4864-8D50-BE62C40C1D61@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Question about CoA-Request and Tunnel-Password X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:36:54 -0000 > On May 9, 2017, at 8:30 PM, Bernard Aboba = wrote: >=20 > Yeah, this is an instance where RADIUS's lame security is even = "lamerer". Does anyone still use Tunnel-Password? Not a lot. And I've never seen it used in CoA-Request packets, which = makes this issue less of a problem. Any attack based on the limited randomness available is mitigated by = the fact that even if you had a 100% attack against Tunnel-Password, you = still couldn't forge request packets. So the main vulnerability appears to be that it's easier to = brute-force crack Tunnel-Password, as there are only 15 bits of = randomness available. Which means pre-computation of hashes becomes = that much easier... > Makes me wonder if enough evidence has accrued to justify declaring = RADIUS security deprecated and recommend a replacement. =20 I'd suggest requiring DTLS, except the most widely used TLS = implementation has had security issue after issue with their DTLS = replacement. Deprecating UDP-only RADIUS would be a procedural step. It wouldn't = really affect existing (or most future) deployments. My $0.02 is to just move to RADIUS over TLS, and call it done... What other deprecation / replacement would you suggest? Alan DeKok. From nobody Tue May 9 18:47:49 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23F2128AFE for ; Tue, 9 May 2017 18:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 hKL84oXMBi5Y for ; Tue, 9 May 2017 18:47:45 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 4EF52126DED for ; Tue, 9 May 2017 18:47:45 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with SMTP id 8GiZdMVpQDKCQ8GjAdiXg8; Wed, 10 May 2017 01:47:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1494380864; bh=JNMeSB4V/IsCOaSeZbVYb3NNuALiV3rLoStFhTXMfqk=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=FqaA8gI3fHuirBVL8xXIybWWwEPmefWoTAsF5OQ5+L2GeHndvqUl31uLYEYGoBUl+ KDD1YTUfml6R1dnrHDeSp9u7Os/a/kdWP7KkMUvK3t4+JYx/25fgAECKYI6+9dmrzB EqbAHV/+adz45u9iJ48kKQD9Pfukl+BhUsmhiFARrKLbBrQVTLiCnKJRZhgVjrWAB/ KSuHYQtgO8bOvf4qRl40uYy13B+8d/SLLAPzJ1LojAhFbYllV/d7DtvAs6rbjS8Shq XNFwrFWb2SfKJ7xR+BgsAF3yenZ+xtNpUhcQ+V2XSsY/MdsZsV9C3OVlNQox+t0CCK P+MF6Pu5M8MXQ== Received: from [192.168.40.67] ([173.162.255.2]) by resomta-po-02v.sys.comcast.net with SMTP id 8Gj6dkjBQlZOx8Gj8d8JGl; Wed, 10 May 2017 01:47:44 +0000 References: <9F6FAC17-FEBE-4864-8D50-BE62C40C1D61@gmail.com> <23BFFA8D-0B95-4EE7-B977-75BD902BBBEB@deployingradius.com> In-Reply-To: <23BFFA8D-0B95-4EE7-B977-75BD902BBBEB@deployingradius.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: Cc: Bernard Aboba , "radext@ietf.org" X-Mailer: iPhone Mail (11D257) From: "David B. Nelson" Date: Tue, 9 May 2017 21:47:38 -0400 To: Alan DeKok X-CMAE-Envelope: MS4wfGtics6e3D6MM+eOCYNzs4OtKrsVTxpC01fk9+A6MdmLYKmGsKJtHZkjU9jUijPUEenIk7cQuxHM5axHM5eYxXpxXkoy47Hu2B5JOxlZCAo3OVoAWdFv A9lIlydcf6BO/LVzhg/i8CjFrXfOsP7JZqxBG2J2xY859CSAh2nXAAB/C+7myl5UO/Yj2sJ0JBRg2LSi8v04Xjx5sj37p0TGg0NPniTpRpb3MUBsZDSRbHvd S5GFZ/hwUJLoPrzgH4BRRTUjbhbFVADrKdyb26Xm00Q= Archived-At: Subject: Re: [radext] Question about CoA-Request and Tunnel-Password X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:47:47 -0000 Out of curiosity, do you have any notion of the relative prevalence of RADIU= S over TLS in deployments today?=20 Sent from my iPhone - Not proofread. > On May 9, 2017, at 9:36 PM, Alan DeKok wrote: >=20 >=20 >> On May 9, 2017, at 8:30 PM, Bernard Aboba wrote= : >>=20 >> Yeah, this is an instance where RADIUS's lame security is even "lamerer".= Does anyone still use Tunnel-Password? >=20 > Not a lot. And I've never seen it used in CoA-Request packets, which mak= es this issue less of a problem. >=20 > Any attack based on the limited randomness available is mitigated by the f= act that even if you had a 100% attack against Tunnel-Password, you still co= uldn't forge request packets. >=20 > So the main vulnerability appears to be that it's easier to brute-force c= rack Tunnel-Password, as there are only 15 bits of randomness available. Wh= ich means pre-computation of hashes becomes that much easier... >=20 >> Makes me wonder if enough evidence has accrued to justify declaring RADIU= S security deprecated and recommend a replacement. =20 >=20 > I'd suggest requiring DTLS, except the most widely used TLS implementatio= n has had security issue after issue with their DTLS replacement. >=20 > Deprecating UDP-only RADIUS would be a procedural step. It wouldn't real= ly affect existing (or most future) deployments. >=20 > My $0.02 is to just move to RADIUS over TLS, and call it done... >=20 > What other deprecation / replacement would you suggest? >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue May 9 18:53:44 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347B12EAD4 for ; Tue, 9 May 2017 18:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QJ7RK0m2Pqud for ; Tue, 9 May 2017 18:53:42 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E07931286AB for ; Tue, 9 May 2017 18:53:41 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id D2FC491F; Wed, 10 May 2017 01:53:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 9 May 2017 21:53:39 -0400 Cc: "radext@ietf.org" , Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F6FAC17-FEBE-4864-8D50-BE62C40C1D61@gmail.com> <23BFFA8D-0B95-4EE7-B977-75BD902BBBEB@deployingradius.com> To: "David B. Nelson" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] Question about CoA-Request and Tunnel-Password X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:53:43 -0000 On May 9, 2017, at 9:47 PM, David B. Nelson = wrote: >=20 > Out of curiosity, do you have any notion of the relative prevalence of = RADIUS over TLS in deployments today?=20 Eduroam is largely RADIUS over TLS for inter-site proxying. Most commercial WiFi roaming is still RADIUS over IPSec the last I = heard. I don't think any switch / NAS vendors have implemented RADIUS over = TLS. Overall, RADIUS over TLS is a small percentage of the total. Alan DeKok.