Subject: Issue 313: Security Exemption

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Sep 2009 16:57:42 -0700

HTML clipboardIssue 313: Security Exemption

Submitter name: Alan DeKok  

Submitter email address:  [email-masked]

Date first submitted: July 24, 2009  

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html

Document: 
Design Guidelines

Comment type: Technical 

Priority: S  

Section:  A.2.1

Rationale/Explanation of issue:

Section A.2.1 states:

      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security, as described below in Section
        A.2.2.
Should this exemption be removed and/or clarified?
[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".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  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.
Proposed Resolution: Discuss

 EMAILING FOR THE GREATER GOOD
Join me

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Sep 2009 15:23:31 +0200

> simply transporting on the behalf of the other protocol.

  Suggested text in Section A.2.2.:

A.2.2. Complex Data Types

   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)
   * for purposes other than authentication or security?

   If the answers to all of the above items are "yes", this data type
   SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 8 Sep 2009 13:05:35 -0400

Sorry for the late response.  I'm still recuperating, and have not remained
on top of my IETF correspondence.

Alan DeKok wrote...

>    Section 2.1.3 for a discussion of why complex types are problematic.

I don't think that the "for purposes other than authentication or security?"
text really addresses the inherent ambiguity.  My understanding is that the
exemption is for authentication or security mechanisms internal to the
RADIUS protocol.  The revised text does not make that "internal to RADIUS"
limitation, and thus remains an open loop-hole, IMO.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Sep 2009 10:48:30 -0700

> limitation, and thus remains an open loop-hole, IMO.

Appendix B talks about complex attributes.  I'm not sure which of these would be considered "internal to RADIUS" and which would not be.  

For example, is Digest Authentication (RFC 5090) internal to RADIUS?  What about CHAP?  Or are we talking about Message-Authenticator?  

IMHO, if an attribute doesn't relate to RADIUS, but to some external entity, then it is effectively opaque and shouldn't be a complex attribute.  I think that's what Alan's suggested text says, more or less.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 8 Sep 2009 13:56:58 -0400

Bernard Aboba wrote...

> IMHO, if an attribute doesn't relate to RADIUS, but to
> some external entity, then it is effectively opaque and
> shouldn't be a complex attribute.

I agree.  My reading of the current, as well as that of others, however, is
that *any* security related attribute, whether in support of the RADIUS
protocol or some external entity, qualifies for an exemption to be designed
as a complex type.  In that regard, "security" attributes for any usage are
covered by this exemption.

> I think that's what Alan's suggested text says, more or less.

It seems to me be way toward the "less".  I think the applicability needs to
be clarified.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Sep 2009 11:17:56 -0700

> covered by this exemption.

OK.  I would agree that this is too broad.  

I think the idea was to exempt attributes where *computation* was required on the server and client (e.g. Digest Authentication, CHAP, etc.).   But if there is no computation occurring, or if the attribute could be construed as opaque, I don't think the exemption is appropriate. 

For example, consider a complex "Security Policy Attribute" sent from server to client.  From the server point of view, there is no computation involved, the server just sends the attribute to the client, who is expected to understand it.  In such a situation, there is no intrinsic reason why server code changes should be required.  Does such an attribute deserve an exemption?  I would say no.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Sep 2009 22:12:04 +0200

> limitation, and thus remains an open loop-hole, IMO.

  ?

   Does the attribute:

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

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Sep 2009 13:36:16 -0700

> allowed for authentication and security...

I think the question is why the exemption should be so broad.  The security and authentication attributes described in Appendix B required computation.  That is the RADIUS server had to add code in order to compare the authentication result presented by the RADIUS client with the result it calculated based on its own data. 

However, if the RADIUS server doesn't have to do any computation (e.g. if it is just sending security or authentication-related data to the RADIUS client), then there is no intrinsic reason why RADIUS server code needs to change.  In that case, why should the exemption apply?

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 16 Sep 2009 08:13:54 -0400

Bernard wrote...

> I think the question is why the exemption should be so broad.  The
> security and authentication attributes described in Appendix B required
> computation.  That is the RADIUS server had to add code in order to
> compare the authentication result presented by the RADIUS client with the
> result it calculated based on its own data. 
>
> However, if the RADIUS server doesn't have to do any computation (e.g.
> if it is just sending security or authentication-related data to the
> RADIUS client), then there is no intrinsic reason why RADIUS server
> code needs to change.  In that case, why should the exemption apply?

I don't think I ever saw an answer to this on the list.  Could we close out
this discussion, and perhaps craft some revised text, before the next draft
version is submitted?

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 16 Sep 2009 08:28:50 -0400

Alan DeKok wrote...
>     * that the RADIUS server and/or client will not treat as opaque data

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Sep 2009 15:26:39 +0200

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

  Yes.

> document itself?  Does that qualify for meeting the opaqueness test of

  See the last sentence you quoted:

   The specification SHOULD

  If it's an opaque type, then the format shouldn't be described in a
RADIUS document.

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

> 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

  Suggested text is above.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 16 Sep 2009 11:18:19 -0400

Alan DeKok writes...

>   If it's an opaque type, then the format shouldn't be described in a

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

>    not meant to be parsed by a RADIUS server is an "opaque data type",

That text looks good to me.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Sep 2009 09:24:54 -0700

+1