Forwarding for a non-list memeber:
From A.Hoenes@TR-Sys.de 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: <A.Hoenes@TR-Sys.de>
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 <ah@TR-Sys.de>
To: gwz@net-zen.net
Cc: radiusext@ops.ietf.org
Message-Id: <200812111856.TAA22615@TR-Sys.de>
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: ah@TR-Sys.de |
+------------------------+--------------------------------------------+