[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Capabilities: Moving forward - to the problem, please
There are a minimum of three cases - all of which have been evident in
recent work:
A) One from Prepaid.
B) One from Geopriv.
C) One from CUI.
A) The AAA server needs to know what the NAS supports so that it can
send the appropriate authorization attributes to the NAS or take other
action (make adjustments).
B) The AAA server needs to obtain some information form the NAS inorder
to correctly authenticate and properly authorize the user session.
C) The NAS needs some information from the AAA-Server inorder to satsify
some business relationship requirements.
Also I don't think your GEOPRIV is statement is stated correctly. It's
the AAA server that needs the information, the NAS could careless.
There are also other requiremetns that we cant forget and that is that
we want to make sure that we don't use excessive messages to achieve
these goals.
So how about the above as a concise package of requirements......
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Emile van Bergen
> Sent: Thursday, October 20, 2005 5:39 AM
> To: Alan DeKok
> Cc: radiusext@ops.ietf.org; Bernard Aboba
> Subject: 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/>
>
--
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/>