[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capabilities: Moving forward - to the problem, please
Alan,
Are you being serious? You're *seriously* claiming each item follows
from the previous one?
I think you missed Bernard's line that shopping lists make bad design
documents. You seem to try and distill requirements from every shopping
list item that has ever floated here.
I've understood Bernard's call for concentrating on "The Problem" as a
request to weed out the ones that have real substance, in my mind the
problems that fundamentally require information at either the client or
server side that's currently missing. The ones where no implementation
can currently behave correctly.
So, if we FIRST get a SHORT list of real world problems that are
currently fundamentally impossible to solve due to lack of information
at the client or server AND clearly describe the decision that cannot be
made correctly due to the lacking information, we can THEN worry about
where the information must come from, next about when it should be
provided, and lastly how it should be represented on the wire.
So far, I've seen only two:
* A NAS that cannot decide what information it is allowed to put in the
access request because it first needs information about the user
(GEOPRIV);
* A server that cannot decide what information it must put in its
access accept, or whether to send an accept at all, because it does
not know if the NAS will act upon a set of session limiting
attributes deemed critical by the server ('prepaid').
Can we please, pretty please, get clarity about this? Do you, others,
agree that these are the only two real problems related to missing
information at either client or server side?
Cheers,
Emile.
On Wed, Oct 19, 2005 at 07:26:40PM -0400, Alan DeKok wrote:
> "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/>
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
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/>