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? ...
- [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Bernard Aboba