Alan DeKok [mailto:aland(_at_)deployingradius(_dot_)com] writes:
Romascanu, Dan (Dan) wrote:
I have reviewed as shepherding AD draft-zorn-radius-pkmv1-04.txt
Following on Dan's review, I've reviewed the document for agreement
with the RADIUS design guidelines document [1]
Both the PKM-SS-Cert and PKM-CA-Cert attributes provide 'ad-hoc'
extension of the RADIUS attribute size, much like the EAP-Message
attribute. It would have been preferable to follow the extended
attribute format [2]. This provides a standardized way of carrying
data
larger than a 253 bytes.
However, that document has not yet been published. My question is
that if there are no current implementations of the PKM specification,
it may be preferable to wait until the extended attributes document is
finished, and then to use that format.
No. There _are_ implementations as I rather clearly stated at the meeting
in SF, using the Experimental attribute space.
Section 3.3 defines the PKM-Config-Settings. This is a "complex
attribute" within the meaning of Section 2.1.3 of the design guidelines
document, which states:
As a
result, the introduction of new complex data types within RADIUS
attribute specifications SHOULD be avoided, except in the case of
complex attributes involving authentication or security
functionality.
All of the attributes are security related.
I do not see any pressing need to make this attribute carry seven
independent fields. The RADIUS attribute space has sufficient room to
allocate 7 attributes. If the extended attribute format is used, then
nearly all space limitations are removed. I would recommend that these
independent values be split up into independent attributes that follow
the RADIUS data model.
Given that there are already multiple interoperable implementations and all
of the attributes are security related, I see no pressing need to make
people change running code to satisfy your personal preferences. Sorry if
these attributes were designed to be easy to implement for people writing
PKM code, rather than RADIUS code.
In Section 3.4. PKM-Cryptosuite-List, can the attribute be longer
than 253 bytes?
No. There are exactly
...
Section 3.5. PKM-SAID, defines an attribute containing 2 octets of
data. It would be preferable to use a 4-octet type, and to specify
that
the upper 2 octets are zero. This would allow the attribute to fit
within the existing RADIUS data model, as discussed in Section 2.1.1 of
the design guidelines document:
It is worth noting that since RADIUS only supports unsigned integers
of 32 or 64 bits, attributes using signed integer data types or
unsigned integer types of other sizes will require code changes, and
SHOULD be avoided.
This would allow a lot more code to be written, too.
Section 3.6. PKM-SA-Descriptor defines another complex attribute as
discussed above. It would be good to define this as a 64-bit integer,
which would fit within the RADIUS data model.
You're absolutely right: why make it easy on engineers when there's the
"RADIUS data model" to defend?
Section 3.7. PKM-AUTH-Key defines a complex attribute for
authentication or security, which fits within the design guidelines.
All of these attributes are related to security.
However, the encryption of the attribute is specified by reference to
[IEEE.802.16-2004]. This encryption is unlike anything previously used
in RADIUS, but it appears to be mandated by the IEEE specification.
Yes, in an obvious error, the IEEE seems to have completely ignored the
RADIUS data model. Silly them!
...
I also have some comments on the Security Considerations section:
If the Access-Accept message is not subject to strong integrity
protection, an attacker may be able to modify the contents of the
PKM-Auth-Key Attribute. For example, the Key field could be
replaced
with a key known to the attacker.
Would it be sufficient to require that the Access-Accept contains a
Message-Authenticator for integrity protection?
If you consider MD5 to be "strong integrity protection".
Although it is necessary for a plaintext copy of the Key field in
the
PKM-AUTH-Key Attribute to be transmitted in the Access-Accept
message, this document does not define a method for doing so
securely.
How is inter-operability to be achieved if there is no specification
for how to carry a necessary field?
I suggest changing the suggestion to use MS-MPPE-Send-Key into a
mandatory requirement, and making it part of the specification.
MPPE-Send-Key is broken; I don't see the value in requiring the use of
broken technology. There are much better ways to encrypt attributes for
transmission, in which (once again) the radext WG has shown near zero
interest. Maybe it should be a cisco VSA?
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf