RE: Issue 313: Security Exemption

["Dave Nelson" <d.b.nelson@comcast.net>]

Alan DeKok wrote...
> 
>   ?
> 
>    Does the attribute:
> 
>     * define a complex data type
>     * that the RADIUS server and/or client will not treat as opaque data
>       (see Section A.1.3)

Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

A.1.2. Opaque data types

   Does the attribute encapsulate an existing data structure defined
   outside of the RADIUS specifications?  Can the attribute be treated
   as opaque data by RADIUS servers (including proxies?)  If both
   questions can be answered affirmatively, a complex structure MAY be
   used in a RADIUS specification.

   The specification of the attribute SHOULD define the encapsulating
   attribute to be of type String.  The specification SHOULD refer to an
   external document defining the structure.  The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

What's the status of an attribute if the author claims that it can be opaque
to a RADIUS server implementation, but the format of the data payload
contained in the attribute is not defined in any other document, but rather
defined, in standard RADIUS attribute fashion, within the RADIUS extension
document itself?  Does that qualify for meeting the opaqueness test of
A.1.2?
 
>   If the RADIUS server can treat it as opaque data, then it falls under
> the purview of A.1.3.  It is permitted, independent of it being used for
> authentication, security, or anything else.
> 
>   If the RADIUS server has to parse it, then complex attributes are
> allowed for authentication and security...

I want to further nail down these two words: authentication, security.

Does authentication mean that the attribute is used to implement a RADIUS
Authentication Method?

Does security means that the attribute is used to provide message integrity
or message confidentiality for the RADIUS datagram itself?

Those extended definitions match what I think is the intent.

On the other hand, security could mean all sorts of things.  It could be a
key-wrap attribute for a key to be used in the NAS or the attached
end-point.  It could be a security policy such as access control information
or a mandatory cipher-suite.  I could go on.  Lots and lots of things fall
under the moniker of security.

I'd really like to see this definitional issue tightened up before the next
draft version is issued.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>