Subject: Re: AD review of draft-zorn-radius-pkmv1-04.txt

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 Aug 2009 16:32:06 -0700

Sorry for the late response -- my laptop was stolen in Stockholm & I'm just
getting back to normal :-(

> If we are to dismiss the Design Guidelines as a "personal preference" how
are they to be taken seriously?

They shouldn't be taken _too_ seriously.  

> I understand that following someone else's design 
> guidance is not always popular with developers, but following regular
design patterns is a well recognized practice
> in software engineering, that is 
> generally attributed with increasing product quality and maintainability.B
I think we simply need to "get with the 
> program" here. 

I really think that the IETF has enough trouble with protocol engineering
w/o setting itself up as a software engineering standards body; indeed, the
"waterfall" design process followed (by & large) in the IETF was discredited
years ago...

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 16 Aug 2009 20:00:32 -0700

...

> 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. 

Actually, the method specified is identical to that in RFC 3579.

? 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. 

Yet again, I'm puzzled: RFC 3579 is "ad-hoc" but an Internet-Draft is a
standard?

...
 
> In Section 3.4. PKM-Cryptosuite-List, can the attribute be longer 
> than 253 bytes? If so, do the same ad-hoc rules as above apply? The 
> IEEE specification seems to permit attributes up to 32768 octets in
length. 

It also defines exactly 6 supported cryptographic suites.  The maximum
length of the PKM-Cryptosuite-List Attribute is therefore 20 octets
(2+3(6)).
 
...

> 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. 

I guess that it's not worth noting that the Salt field in the
Tunnel-Password Attribute (RFC 2868) is 16 bits long (I'm just not sure
why).

> Section3.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. 

It would be good to define dinosaurs are imaginary, too -- that would fit
the Biblical data model.  Unfortunately, dinosaurs did exist and the
PKM-SA-Descriptor is not a 64-bit integer.

...