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

"Glen Zorn" <gwz@net-zen.net> Thu, 27 August 2009 01:40 UTC

Return-Path: <gwz@net-zen.net>
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 39A923A70A6 for <secdir@core3.amsl.com>; Wed, 26 Aug 2009 18:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level:
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.509, 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 5o6eBOgWmRei for <secdir@core3.amsl.com>; Wed, 26 Aug 2009 18:40:39 -0700 (PDT)
Received: from smtpout06.prod.mesa1.secureserver.net (smtpout06-01.prod.mesa1.secureserver.net [64.202.165.224]) by core3.amsl.com (Postfix) with SMTP id 55C043A7095 for <secdir@ietf.org>; Wed, 26 Aug 2009 18:40:38 -0700 (PDT)
Received: (qmail 28859 invoked from network); 27 Aug 2009 01:40:45 -0000
Received: from unknown (71.231.55.1) by smtpout06.prod.mesa1.secureserver.net (64.202.165.224) with ESMTP; 27 Aug 2009 01:40:45 -0000
From: "Glen Zorn" <gwz@net-zen.net>
To: "'Donald Eastlake'" <d3e3e3@gmail.com>
References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com>
In-Reply-To: <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com>
Date: Wed, 26 Aug 2009 18:40:37 -0700
Organization: Network Zen
Message-ID: <00b101ca26b7$615bfe90$2413fbb0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcomUEf16wCeDaZiTCOBHwvBgKiHxwAZYc7Q
Content-Language: en-us
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:40:40 -0000

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?

...