Re: [HOKEY] AD review of draft-ietf-hokey-arch-design

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 29 October 2011 15:41 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15421F8573 for <hokey@ietfa.amsl.com>; Sat, 29 Oct 2011 08:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.324
X-Spam-Level:
X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRAnAXf1s3ab for <hokey@ietfa.amsl.com>; Sat, 29 Oct 2011 08:41:56 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1EA21F84FD for <hokey@ietf.org>; Sat, 29 Oct 2011 08:41:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EE67B15358F; Sat, 29 Oct 2011 16:41:55 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319902915; bh=aBerUnTL4geR51 bSKiFvubO8SLzWcS6X5zH+d2Nayi4=; b=ZLWVH0iWs6Fh8fpP1wzLvNvWOlRr6b KSi+EqDkESlfiaUk9XyDfSEgRdSfDvj6dA4tkCH/z8FOaFJYgWIM9qHjWwzga8Ol /z2fF6c7sZsH6ek7uyQQq3iG7ppko0LClov2q6M1NP/SWs3eXw2KLHN+LiG8t/Vl 0dUM2LLAGXHAGYS9UI1pXF9QIGYDs2nejvRKnmN1yBVGPB8G8VbkX38rBNC6AWbm Pg7P6mZVKAmb1XVBCwSy6G1ZrJ3vqzuyL7eBLsNMGBQJzOBcZ84d4A/4fZzFzTAa Up0fXS/IXpWNbqapIoOxUxYTbRWsg3itWjbYPNzNgMzZdlB2nDwtNbVQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id I2FVkAz7WB7A; Sat, 29 Oct 2011 16:41:55 +0100 (IST)
Received: from [10.87.48.4] (unknown [86.46.30.212]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7504515358D; Sat, 29 Oct 2011 16:41:54 +0100 (IST)
Message-ID: <4EAC1EC2.7000207@cs.tcd.ie>
Date: Sat, 29 Oct 2011 16:41:54 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
References: <4EA4463B.6000304@cs.tcd.ie> <4EAC1AF2.6060207@net-zen.net>
In-Reply-To: <4EAC1AF2.6060207@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hokey@ietf.org
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-arch-design
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2011 15:41:57 -0000

Hi Glen,

Those all look fine and are changes that can IMO be made before
or after IETF LC. (Once we bottom out on handling the comment
from the other mail, then that'll tell me whether this should
go revised ID needed or to IETF LC.)

I'd keep the idnits-robot-annoying reference myself, but
whatever:-)

S.

On 10/29/2011 04:25 PM, Glen Zorn wrote:
> On 10/23/2011 11:52 PM, Stephen Farrell wrote:
>
> (pasted from the attachment)
>
>> not quite nits:
>>
>> - I realise that this document references lots of others that define
>> things, but a bit of ascii art at the start would have been helpful.
>> Its not obvious where e.g. the "ER server" might live from the
>> current text.
>
> Actually I removed the ASCII art that was there because I thought that
> it was way confusing.  I suppose that it can be put back.
>
>> - p16, I don't get 6.4 really - why is inter-technology the same as
>> intra-domain?
>
> I guess that in the case of hokey, it's because we never defined an
> authentication protocol for the inter-domain case (ERP is strictly for
> intra-domain re-authentication). So, for hokey, inter-technology _is_
> intra-domain.
>
>> nits:
>>
>> - p5, "For the purpose of this draft" is wrong. s/draft/memo/?
>
> OK.
>
>> - p5, "All three mechanisms..." This description is a bit confusing,
>> since there are many RFCs referenced.  I think it'd be improved if
>> you listed the three mechanisms as bullets.
>
> How's this:
>
>     All three early authentication mechanisms provide means to securely
>     establish authenticated keying material on a Candidate Access Point
>     (CAP) while still being connected to the Serving Access Point (SAP)
>     but vary in their respective system assumptions and communication
>     paths.
>
>> - p5, ER is used as an acronym - expand on 1st use as well as in
>> section 2 would be better
>
> OK
>
>> - p6, s/can be integrated/whether or not it can be integrated/?
>
> How's this:
>
>     However, it is currently unclear how
>     the necessary handover infrastructure can be deployed and
>     integrated into existing EAP infrastructures.
>
> Although I think that this is really a non-issue, as far as the IETF is
> concerned: every deployment will be different; as long as we don't
> inadvertently (or purposely, for that matter) outlaw a reasonable design
> I think that we're fine.
>
>> - p7 - cute that you reference 2119 anyway:-) I wonder if this is its
>> first informative reference?
>
> Maybe ;-).  I hate to miss a chance to annoy the idnits robot, but maybe
> just lose the reference?
>
>> - p7, What is a re-authenticaiton root key? (3.2) I see its defined
>> in 5296 but wouldn't it be ok to just say "required keys" here - do
>> you *need* to be so precise?
>
> I don't think so.
>
>> If so, then maybe add a ref to 5296 to
>> help point the reader to the right place?
>
>> - p8 - what is a "HOKEY server"?
>
> I think that it is generic term for a server supporting hand-over keying
> -- could be a ER server or an AAK server, for example.
>
>> should that be in the terminology
>> section?
>
> Since it seems to appear only once, maybe we could just try to rephrase
> the sentence?
>
>> - p8, 1st para of 4.1 just confuses me - is it needed really?  Maybe
>> you could lose that and just s/subsystem/subsystem provided by HOKEY/
>> in the next para and that'd be good enough?
>
> Works for me.
>
>> (If you do keep the
>> current text, I also wonder if the "This section" at the start refers
>> to setction 4 generally or 4.1 only? As-is its a little ambiguous
>> looking.)
>
>> - p9, end of page - Got any references to that work in progress?
>
> I think that that is RFC 5296bis, so yes.
>