Subject: Fwd: review of draft-zorn-radius-pkmv1-02 (fwd)

From: [email-masked]
Date: Mon, 15 Dec 2008 18:46:03 +0000 (UTC)

Forwarding for a non-list memeber: 

>From [email-masked] Thu Dec 11 19:56:57 MEZ 2008 
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) 
      id AA023651816; Thu, 11 Dec 2008 19:56:56 +0100 
Return-Path: <[email-masked]> 
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) 
      id TAA22615; Thu, 11 Dec 2008 19:56:55 +0100 (MEZ) 
From: Alfred H�nes <[email-masked]> 
To: [email-masked] 
Cc: [email-masked] 
Message-Id: <[email-masked]> 
Date: Thu, 11 Dec 2008 19:56:55 +0100 (MEZ) 
Subject: review of draft-zorn-radius-pkmv1-02 

Hello, 
on my cycle over RADIUS-related Internet-Drafts, I also have 
followed up to your I-D, draft-zorn-radius-pkmv1-02, 
and would like to submit a few comments. 

First of all, I fear that this draft violates the emerging 
guidelines for RADIUS extensions (draft-ietf-radext-design-05, 
IETF LC passed) in so many details that it will most probably 
not be socially acceptable. 
Perhaps it would be prudent to redesign the intended attributes 
as "Extended RADIUS Attributes", following the principles laid 
down in draft-ietf-radext-extended-attributes-05 (you should be 
aware of, as a co-author :-) ) 

Furthermore, I am astonished by seeing the draft making use of 
very outdated references (which perhaps should be Normative!): 

o   [PKCS.1.1998]  had been documented for the IETF in RFC 2437, 
                   which has been obsoleted by RFC 3447 long ago; 

o   [RFC2459]      had first been obsoleted by RFC 3280, 
                   which now has been obsoleted by RFC 5280. 

More details: 

(1)  Section 2.2 

The draft uses, but does not introduce, more Acronyms than presently 
listed there, e.g., 

   SS 
      Subscriber Station. 

   BS 
      Base Station. 

   CA 
      Certificate Authority; trusted party issuing and signing X.509 
      certificates. 

(2)  Section 3.1 

The draft says: 

   Description 

      The PKM-SS-Cert Attribute is variable length and contains the 
|     X.509 certificate [RFC2459] identifying the Subscriber Station; it 
                                  ^^^^^^^^^^^ 
      MAY be transmitted in the Access-Request message. 

That's misleading. 
How about saying more precisely: 

   Description 

      The PKM-SS-Cert Attribute is variable length and contains the 
|     X.509 certificate [RFC2459] binding a public key to the identifier 
      vvv                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
|     of the Subscriber Station; it MAY be transmitted in the Access- 
      Request message. 

'Value' : 

Since you explicitely refer to RSA, how do you imagine to squeeze 
an RSA public key certificate into the Value field (I guess you mean, 
in RADIUS String format, do you?), which is limited to 253 octets ??? 

Did you mean -- contrary to the explanation quoted above -- a plain 
certificate hash? 

(3)  Section 3.2 

The draft says: 

   Description 

      The PKM-CA-Cert Attribute is variable length and contains the 
|     X.509 certificate [RFC2459] identifying the CA certificate for the 
                                  ^^^^^^^^^^^ 
      SS; it MAY be transmitted in the Access-Request message. 

I'm getting confused even more.  Did you mean: 

   Description 

      The PKM-CA-Cert Attribute is variable length and contains the 
|     X.509 certificate [RFC2459] used by the CA to sign the SS 
|     certificate carried in the PKM-SS-Cert attribute of the same 
|     message; it MAY be transmitted in the Access-Request message. 

'Value' : 

Same issue as in (2) above! 

(4)  Section 3.3 

'Description' : 

I fear the text confuses the terms "timer" and "timeout". 
A 'timer' is a running counter; it only makes sense to transport 
its limit/starting value, a 'timeout value' in a packet over the 
network. 

The intended restriction, 

     An instance ... MAY be included ... 

should perhaps better, and more precisely say, 

     One instance ... MAY be included ... 
     ^^^ 

'Value' : 

The definition given is in direct violation of the principles laid down 
in the RADIUS Extension Guidelines.  Following the spirit of that memo, 
doing so requires much more detailed, and much more convincing 
rationale! 

(5)  Sections 3.4 and 3.5 

Using 24- or 16-bit integers seems to be inacceptable, according to 
the Guidelines.  Putting multiple such values into one option also is 
not conformant; the Guidelines recommend using multiple instances 
of an elementary option instead. 

(6)  Section 3.6 

The draft says: 

   Description 

|     The PKM-SA-Descriptor Attribute is 8 octets in length.  It 
      vvvvvvvvv                                               ^^^ 
|     consists of 3 fields, described below, which together specify the 
|     characteristics of a PKM security association.  One or more 
      vvvvvvvvv                                       ^^^^^^^^^^^^ 
|     instances of the PKM-SA-Descriptor Attribute MAY occur in an 
      Access-Accept message. 

Semantically, the "It consists" is ambiguous and misleading; 
obviously the text only talks about the sub-fields of the value 
field; thus, it should be explicit about that and say: 

  "Its value consists ..."    or    "It contains ..."  . 
   ^^^^^^^^^^                           ^^^^^^^^ 

I do not understand the semantics of "One or more instances". 
Other parts of the text indicate that this attributes carries 
the selection from the choice of cryptosuite identifiers offered 
in the PKM-Cryptosuite-List attribute, plus more SA data. 
Also, the table in Section 4 contains '0-1' in the 'Accept' column 
and '0' in all other columns for this attribute. 
Hence, the expected multiplicity needs to be clarified. 

Subsequently, the draft says: 

   SAID 

      The SAID field is two octets in length and contains a PKM SAID 
|     Section 3.5. 

Apparently something is missing here.  I guess: 

      The SAID field is two octets in length and contains a PKM SAID 
|     (see Section 3.5). 

The structured 'Value' field again violated the Guidelines. 
It needs explicit, convincing justification. 

(7)  Section 3.7 

Similar issues as in (6) apply here. 
For brevity, I omit the details. 

Kind regards, 
  Alfred H�nes. 

-- 

+------------------------+--------------------------------------------+ 
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  | 
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         | 
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     | 
+------------------------+--------------------------------------------+