Re: [secdir] draft-zorn-radius-pkmv1-05.txt

Donald Eastlake <d3e3e3@gmail.com> Thu, 27 August 2009 01:47 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82BF28C37C; Wed, 26 Aug 2009 18:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.159
X-Spam-Level:
X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2muqJ40yOwb; Wed, 26 Aug 2009 18:47:29 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 4FD8E28C369; Wed, 26 Aug 2009 18:47:29 -0700 (PDT)
Received: by ewy3 with SMTP id 3so757295ewy.42 for <multiple recipients>; Wed, 26 Aug 2009 18:47:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yaF0D/ZqPrC4EjeBHpWOyCOymXrmV1dY9T8Hnz7ln+k=; b=N+seEZuaOgaX6sByzK84MqTxhiAEE8i5RG+Cmrl20qWlVHqPAhWOL7FNQ3ISZ5hNLC M6FfhOcE/txAG2BeT1QuEqTe1flwFsR7GLG7xSLEWViY7lHiSnEn9vVv6/8RqupULpz1 /OFDULGZY8xVVrK874IrBKmuxy1Kvyq5upEmQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nB0KnYUl94ADdx4qm8SZul50Ksx8spA7AepBFryUxpHnQHe9VISqH68lVOAYHZcQdH W1ERtxXmlMkKh4e1pYzvcUXEHdUtizyusHehxP5Mo8nO4bZ6qsk0LxZGg6gsUsAqsuB1 YmPBl00EwXf+j7LaUf9afZ5qccY1JvOBRuk38=
MIME-Version: 1.0
Received: by 10.216.90.14 with SMTP id d14mr1793047wef.30.1251337650786; Wed, 26 Aug 2009 18:47:30 -0700 (PDT)
In-Reply-To: <00b101ca26b7$615bfe90$2413fbb0$@net>
References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> <00b101ca26b7$615bfe90$2413fbb0$@net>
Date: Wed, 26 Aug 2009 21:47:30 -0400
Message-ID: <1028365c0908261847k72154761kda2ba49f64ca158d@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: Glen Zorn <gwz@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Dan Romascanu <dromasca@avaya.com>, IETF Discussion <ietf@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 01:47:30 -0000

Yes, the changes below look good to me.

Thanks,
Donald

On Wed, Aug 26, 2009 at 9:40 PM, Glen Zorn<gwz@net-zen.net> wrote:
> Donald Eastlake [mailto:d3e3e3@gmail.com] writes:
>
> ...
>
>> >> The wording in Sections 3.1 and 3.2 see to almost be designed to
>> allow
>> >> the possibility of the multiple *-Cert Attributes carrying a
>> >> certificate to appear in more than one Access-Request message. But I
>> >> would assume that's not meaningful and/or was not intended to allow
>> >> that.
>> >
>> > There is no way to do such a thing in standard RADIUS.
>>
>> That's what I thought and why I was puzzled as to why there was a more
>> complex wording that appears to permit this. I suppose it is just the
>> way the words struck me at the time I read them. But I would, instead
>> of
>>
>>           If multiple PKM-SS-Cert
>>       Attributes are contained within an Access-Request packet, they
>>       MUST be in order and MUST be consecutive attributes in the
>> packet.
>>
>> have said
>>
>>       These multiple PKM-SS-Cert Attributes MUST appear consecutively
>>       and in order within an Access-Request packet.
>>
>> and similarly for PKM-CA-Cert.
>
> OK.
>
> ...
>
>> >> This whole table needs to be carefully checked, the
>> >> inconsistencies resolved, and it should be clear if literal binary
>> >> attributes or some sort of logical aggregate attributes (in the case
>> >> of the "Cert" attributes at least), is being counted.
>> >
>> > I can add notes to the table regarding the "logical" vs. "physical"
>> nature
>> > of the PKM-*-Cert Attributes, as well as a key to the meaning of
>> "0+", etc.
>> > Is that OK?
>>
>> Yes.
>
> You were right, the entries for the PKM*Cert Attributes should have been 0+
> instead of 0-1.  The Table of Attributes now looks like this:
>
>   The following table provides a guide to which attributes may be found
>   in which kinds of packets, and in what quantity.
>
>     Request Accept Reject Challenge Acct-Req  #   Attribute
>     0+      0      0      0         0        TBD1 PKM-SS-Cert [Note 1]
>     0+      0      0      0         0        TBD2 PKM-CA-Cert [Note 2]
>     0       0-1    0      0         0        TBD3 PKM-Config-Settings
>     0-1     0      0      0         0        TBD4 PKM-Cryptosuite-List
>     0-1     0      0      0         0        TBD5 PKM-SAID
>     0       0+     0      0         0        TBD6 PKM-SA-Descriptor
>     0       0-1    0      0         0        TBD7 PKM-Auth-Key
>
>   [Note 1]
>      No more than one Subscriber Station Certificate may be transferred
>      in an Access-Request packet.
>
>   [Note 1]
>      No more than one CA Certificate may be transferred in an Access-
>      Request packet.
>
>   The following table defines the meaning of the above table entries.
>
>   0   This attribute MUST NOT be present in packet
>   0+  Zero or more instances of this attribute MAY be present in packet
>   0-1 Zero or one instance of this attribute MAY be present in packet
>   1   Exactly one instance of this attribute MUST be present in packet
>
> Is that OK?
>
> ...
>
>
>