Re: Issue 313: Security Exemption

[Alan DeKok <aland@deployingradius.com>]

Dave Nelson wrote:
>>     * 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?

  Yes.

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

  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.

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

  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.

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

  e.g. the MS-MPPE-keys... but those could fit into the standard RADIUS
data model with a bit of tweaking.

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

  Suggested text is above.

  Alan DeKok.

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