RE: Issue 313: Security Exemption

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

Alan DeKok writes...

>   See the last sentence you quoted:
> 
>    The specification SHOULD
>    NOT define or describe the structure, as discussed above in Section
>    2.1.3.
> 
>   If it's an opaque type, then the format shouldn't be described in a
> RADIUS document.

Right.  Hopefully future authors will take that to heart.  :-)

>   I believe so.  How about breaking those definitions out into a new
> section:
> 
> A.1.2. Transport of Authentication and Security Data
> 
>    Does the data provide authentication and/or security capabilities, as
>    outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
>    format RADIUS attribute.  It SHOULD NOT be encapsulated in a
>    [RFC2865] format RADIUS VSA.
> 
>       * Complex data types that carry authentication methods which
>         RADIUS servers are expected to parse and verify as part of
>         an authentication process.
> 
>       * Complex data types that carry security information intended
>         to increase the security of the RADIUS protocol itself.
> 
>    Any data type carrying authentication and/or security data that is
>    not meant to be parsed by a RADIUS server is an "opaque data type",
>    as defined below.

That text looks good to me.



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