Dave,
apologies regarding the repeated use of HTML format, I have now corrected the problem which made me believe I sent in text only format, but infact it got converted to HTML.
I like to comment on your statement:
David Nelson wrote:
You seem to think the "supports CUI but did not advertise" scenario is reasonable, and I disagree. I really can't comment, other than to repeat myself."
I continue to believe that "supports CUI but did not advertise" is a possible scenario.
It is IMO an implementation decision of the NAS manufacturer to allow this or not, and a configuration decision of the network access provider to adopt an always advertise policy or not, unless the specification says "MUST advertise".
If you want to exclude this implementation decision and configuration decision, than the text should say: if CUI is supported, it MUST be advertised in all Access Request Messages.
So far, this has nothing to do with capability negotiation.
Capability negotiation type functionality would only come into play, when the NAS makes an additional implementation decision complemented by the network access operator making a configuration decision to apply a "advertise only on as needed basis" policy.
When such "advertise only on as needed basis" policy is in place, the NAS could on receipt of a Access-Reject with failure cause "CUI-not-determined" delay sending the reject message to the client, and rather send a second access-request with the CUI-NUL attribute to the server, hoping to get back an Access-Accept in time in order to be able to proceed with accepting the user. Are you aware of any standard which would be violated by such an implementation specific behaviour of a NAS ?
Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Freitag, 10. Dezember 2004 17:41
An: radiusext@ops.ietf.org
Betreff: RE: backwards compatible introduction of NEW attribute such as CUI
Lothar Reith writes (still in HTML!)...
> to a) what would be "the appropriate helpdesk" in a WLAN roaming
> scenario ?
This is an important question for those in the "roaming consortium" business, as well as home ISPs, to answer. I remember the "bad old days" before seamless roaming for cellular telephony. Only the brave and the technically savvy were able to use roaming services effectively. Today, I expect to be able to dial 611 on my cell phone wherever I am and get appropriate assistance. (Of course, talking to a human still requires an Act of Congress -- but I digress :-) If WLAN roaming wants to be successful, IMHO, the industry needs to make it as transparent as cellular roaming.
> Also, should the error message say: did not support CUI or perhaps
> supports CUI but did not advertise ?
You seem to think the "supports CUI but did not advertise" scenario is reasonable, and I disagree. I really can't comment, other than to repeat myself.
> A related question is if the server counts an authentication request
> rejected due to missing knowledge about the NASes CUI support as an
> unsuccessful login attempt with regards to security thresholds ?
That is likely an implementation decision. Personally, I would tend to count it as "failed to meet policy requirements" as apposed to "failed to authenticate".
--
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/>