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

From: "Glen Zorn" <[email-masked]>
Date: Sat, 15 Aug 2009 19:32:51 -0700

[email-masked] wrote: 

> > Yeah. I've always been a bit uncomfortable with the "security 
> > functionality" escape clause in the RADIUS Design Guidelines draft.  
> > Lots of things can reasonably be claimed to be "security related". I 
> > would have preferred the exception to be crafted a bit narrower, just 
> > for this reason. But, unless wording of Design Guidelines is changed, 
> > you have a legitimate argument. 
> 
> I believe the intent was "related to RADIUS security". 

This statement puzzles me: section 2.1.3 of the design guidelines document
says:

   As can be seen in Appendix B, most of the existing complex attributes
   involve authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

But none of the Attributes mentioned in Appendix B have anything to do with
RADIUS security as I understand it.  Can you explain?

> The guidelines 
> document could be updated to address this. 
>  
> RADIUS could transport parameters for *another* protocol. 

Like EAP?

> Those 
> attributes are not security related. 

I see.  What attributes (besides Message-Authenticator) are related to
RADIUS security?

> They either follow the RADIUS data 
> model (int, IP address, etc.), or they are "opaque data" that RADIUS is 
> simply transporting on the behalf of the other protocol. 
 
Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 16 Aug 2009 11:33:22 -0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
>   From the document:
>    Appendix B includes a
>    listing of complex attributes used within [RFC2865], [RFC2868],
>    [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
>    these attributes includes reasons why a complex type is acceptable,
>    or suggestions for how the attribute could have been defined to
>    follow the RADIUS data model.
> 
>   The intent of Appendix B is to explain what is *wrong* about the use
> of complex attributes in previous RFCs.

You seem to be honing you mastery of the non sequitur ;-).  My original
question was:

<quote>
> > would have preferred the exception to be crafted a bit narrower, 
> > just for this reason. But, unless wording of Design Guidelines is 
> > changed, you have a legitimate argument.
> 

</quote>

How does your response relate to my original question?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 16 Aug 2009 08:47:07 +0200

From the document:

   Appendix B includes a

  Alan DeKok.