[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Scope of applicability for CUI
Hi Avi,
I agree with most of what you are saying. I guess I know understand the point "EAP cannot be the only use case for CUI). I can think one example where CUI would not even work with EAP. The way I understand it, EAP-TTLS uses a model where a TTLS server that can be different from the AAAH of the client establishes a TLS session with the client. The purpose of TLS is to protect the user identity/ authentication. So in the early stage of EAP you need to use a pseudo identity. If the AAAH is the only place that understands that pseudo identity, then you are in trouble, because the TLS is established with the TTLS server and not with the AAAH. AAAH only comes in place when the client is authenticating. The TTLS server does not know the CUI. So in that case you can't even use CUI as an alias.
Madjid
-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Friday, December 17, 2004 1:43 PM
To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; 'Nelson, David'; radiusext@ops.ietf.org
Subject: RE: Scope of applicability for CUI
Hi Madjid,
Absolutely not. CUI and EAP usage should not be entertwined. EAP works fine
without CUI and CUI works fine with out EAP.
CUI allows mediating networks and visited networks to implement certain
business logic. For example:
As a driving usecase for this work we noted that when certain EAP methods
are used the identity of the user is hidden and mediating networks have no
way to associate an Authentication\Authorization and or Accounting events to
a specific user or chargeable entity. CUI provides a mechanims whereby the
home network can provide a handle to the chargeable entity (without
revealing the true identity), to the roaming partners and or mediating
networks.
This does not mean that it is required when EAP is used. Nor does it mean
that it can't be used in cases where EAP is not used.
It simply means that it is available to be used when it is required by
roaming partners - for whatever reason.
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Friday, December 17, 2004 12:23 PM
> To: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
>
>
> Avi,
>
> I don't understand CUI well, but I care about EAP. Doesn't
> this mean the EAP server and the EAP authentication methods
> must now support use of CUI as identity and be able to do the
> conversions?
>
> Madjid
>
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
> Sent: Thursday, December 16, 2004 5:14 PM
> To: 'Nelson, David'; radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
>
> David,
>
> Sorry for the short reply. I was rushed away. Let me expand.
>
> We already mention in the document that CUI is useable when
> EAP is used and in particular when EAP methods hide the user identity.
>
> What I am opposed to is mandating that the only case for CUI
> is tied to the use of EAP. Operationaly it does not depend on
> EAP. There could be other uses in the future. So the current
> text in the draft is sufficient.
>
> Avi
>
> > -----Original Message-----
> > From: Nelson, David [mailto:dnelson@enterasys.com]
> > Sent: Thursday, December 16, 2004 1:29 PM
> > To: radiusext@ops.ietf.org
> > Subject: RE: Scope of applicability for CUI
> >
> >
> >
> > Avi Lior writes...
> >
> > > There maybe others that I am not aware of.
> >
> > It's hard to design practical and interoperable protocols to
> > meet the requirements of unknown use cases -- so perhaps we
> > can focus on the known ones.
> >
> > > But these specific once are the once that we have seen
> > requests for. I
> > > believe these are mentioned in the draft as request by folks here.
> >
> > OK. Since User-Name re-write is considered "evil" in roaming
> > applications, because it changes the routing for RADIUS
> > request traffic, can we assume that only addressing use case
> > (B) is sufficient to meet the current needs?
> >
> > If so, how is linking the use of CUI to the use of EAP
> > authentication inappropriate?
> >
> > > > A) when the User-Name re-write feature (for accounting
> > > > purposes) obscures the original authentication identity, or
> > > >
> > > > B) when the RADIUS authentication method is EAP, allowing for a
> > > > "method internal" user identity for authentication, and an
> > > > "anonymous" or "routing-only" value in User-Name.
> > > >
> > > > These use cases are further restricted to multi-party
> > (e.g. roaming
> > > > consortia) environments, because for deployments where
> > the NAS and
> > > > the Home RADIUS server belong to a single administrative
> > entity the
> > > > Class attribute has been seen to be sufficient.
> >
> > --
> > 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/>
>
--
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/>