Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)
Adam Roach <adam@nostrum.com> Tue, 14 August 2018 15:51 UTC
Return-Path: <adam@nostrum.com>
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 37335130E22; Tue, 14 Aug 2018 08:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6VVg_q1VIPnL; Tue, 14 Aug 2018 08:51:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ADE16130E0A; Tue, 14 Aug 2018 08:51:32 -0700 (PDT)
Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EFpKRq052077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 10:51:21 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local
To: Alan DeKok <aland@deployingradius.com>
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org
References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <DCBC0F8A-E486-4844-8C7A-CCDEBD41A0E4@deployingradius.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <B33A4595-EDBE-41C5-9FD6-5EEACB6EEDE4@deployingradius.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <b6c70613-40b1-9c78-ec63-927ffdffa094@nostrum.com>
Date: Tue, 14 Aug 2018 10:51:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <B33A4595-EDBE-41C5-9FD6-5EEACB6EEDE4@deployingradius.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/RaVFgiaInE4-rWZC4XOq1b9mAt8>
Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 15:51:35 -0000
On 8/14/18 10:01, Alan DeKok wrote: > On Aug 14, 2018, at 9:43 AM, Adam Roach <adam@nostrum.com> wrote: >> Generally, when integrity is important, so is anti-replay. If you care that remote parties can't create their own novel values, it would be surprising not to care about them squirreling away values they've seen before and using them later. Conversely, if you don't care about replay, you probably need to think really hard about why you care about integrity. >> >> Of course, it's completely possible that I'm misunderstanding what you mean by "verifiable" in the original text (which gets to the heart of my original comment: there are terms of art for the properties that cryptography provides, and you really want to use them for the purpose of clarity.) > In this situation, all we really care about is that the opaque token is known. And it really should be opaque. It's just bits, and not necessarily containing anything in particular. I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set. The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it? The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it? /a
- [radext] Adam Roach's Discuss on draft-ietf-radex… Adam Roach
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Alan DeKok
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Alan DeKok
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Adam Roach
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Alan DeKok
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Adam Roach
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Alan DeKok
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Adam Roach
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Alan DeKok
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Benjamin Kaduk
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Adam Roach
- Re: [radext] Adam Roach's Discuss on draft-ietf-r… Benjamin Kaduk