Re: Capabilities: Moving forward

["Alan DeKok" <aland@ox.org>]

"Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
> Rather, the hallmark of a good problem statement is brevity, leading to 
> solutions which do what is necessary and little more.

  << 10-20 attempts later >>

  The server cannot send Access-Accept in some cases unless it is sure
that the NAS will behave appropriately (i.e. prepaid).  Otherwise,
services may be offered, but not billed to someone.

  The server cannot send Access-Challenge to the NAS, because it
doesn't know if the NAS will treat that as Access-Reject, or as
extended capability negotiation.

  Therefore, the ONLY requirement that matters here is the first one
listed below.  Later capabilites are follow-ons from it.  These
requirements also avoid the issue raised on the capability draft of a
NAS "rejecting" a response from a server, which can't happen in
RADIUS.

    C1: For new capabilities, Access-Request MUST ALWAYS contain a
        capability advertisement.

  For efficiency, and to avoid unecessary Access-Challenge:

    C2: The advertisement MUST include advertisement of all
        capabilities

  For GEOPRIV and related issues:

    C3: The advertisement MAY include data for only some of the
        capabilities (i.e. location capability, but no location data)

  To later get GEOPRIV location data:

    C4: The advertisement MUST include indication of support for
        Access-Challenge responses to Access-Request with PAP.

  To deal with mandatory and requested capabilities:

    C5: The advertisement implementation MUST support both mandatory
        and requested capabilities.

  To deal with server's capabilities:

    C6: A server MUST be able to send capabilities, just like a NAS

  To deal with backwards compatibilty:

    C7: A server MUST NOT send capability advertisement to a NAS
        if the Access-Request did not contain a capability advertisement
        (modulo EAP, etc, where capabilities can be cached per-session,
         and therefore don't have to be sent in each packet)

  To deal with information leak:

    C8: A server MUST NOT advertise to a NAS that the server is capable
        of services that the NAS did not advertise as being mandatory
        or requested

  To ensure security:

    C9: A server MUST send an Access-Reject if a capability it deems
        mandatory is not advertised by the NAS.

  To help with debugging:

    C10: A server MAY advertise mandatory capabilities in an Access-Reject,
         as a hint to the NAS about why the request was rejected.

  To deal with per-capability data (also see C4).

    C11: The capability negotiation MUST include support for
         per-capability data.

  To deal with the content of the data:

    C12: The capability negotiation MUST include the ability for
         the server to indicate to the NAS that the data supplied is
         inadequate or improper.

  To deal with proxying:

    C13: Packets containing capability advertisements MAY be proxied

  To deal with proxy security:

    C14: Proxied Access-Request packets MUST have their capability
         advertisements updated with the intersection of capabilities
         of the NAS and the proxying server.  (i.e. the NAS supports
         CoA, but the proxy doesn't)

  To deal with proxying by servers unaware of new capabilities:

    C15: Capabilities MUST be validated per-hop.
         e.g. signed, or containing information that will not be
         updated by a capability un-aware proxy

  <whew> Comments?  Did anyone read this far?

  That's all I have for now.  I think it covers a lot of the problem
space and discussion.

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