On Oct 24, 2011, at 10:42 AM, [email protected] wrote: Hi Yinxing,
> > I agree with your advice. > One way is to move the use case from draft-wei-abfab-fcla to > draft-ietf-abfab-usecases, and put the different options into the > draft-wei-abfab-fcla. > > Does it make sense? yes it does. Klaas > > ------- > Yinxing > > > Hannes Tschofenig <[email protected]> > 2011/10/24 16:24 > > 收件人 > [email protected] > 抄送 > Hannes Tschofenig <[email protected]>, [email protected], > [email protected], [email protected], Rhys Smith <[email protected]> > 主题 > Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" > > > > > > Hi Yinxing, > > thanks for the quick response. > > It may make sense to somewhere (but not in the scenario document) to describe > how the different building blocks are put together since there are a couple > of different options. > > Ciao > Hannes > > On Oct 24, 2011, at 10:22 AM, [email protected] wrote: > > > > > Hi, Hannes > > > > I think you have already explained it clearly. Current mechanisms, such as > > EAP, GSS-API, SAML, AAA(Radius/Diameter) are enough for this use case. For > > me, The next step is to make use of existing tools defined in abfab to > > support this use case. > > > > ------- > > Yinxing > > > > > > Hannes Tschofenig <[email protected]> > > 2011/10/24 15:07 > > > > 收件人 > > Rhys Smith <[email protected]> > > 抄送 > > Hannes Tschofenig <[email protected]>, [email protected], > > [email protected], [email protected], [email protected] > > 主题 > > Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" > > > > > > > > > > > > I had a look at http://tools.ietf.org/html/draft-wei-abfab-fcla-00 and was > > wondering what specifically needs to be addressed in ABFAB to make use of > > the existing telecommunication subscriber infrastructure. I believe > > everything is supported already. > > > > EAP is used in ABFAB (within the GSS-API) and that allows any > > authentication mechanisms to be used, including the AKA. That isn't a > > problem. > > > > If you don't want to use AKA directly within EAP but add an additional GBA > > run beforehand you can do that as well. > > > > So, Yinxing could you explain what additional functionality is need? > > > > Ciao > > Hannes > > > > On Oct 22, 2011, at 10:51 PM, Rhys Smith wrote: > > > > > Hi Yinxing, (cc:ed to abfab list for discussion). > > > > > > I'm just looking at making the next version of the use case document for > > > ABFAB, and so I've been looking at the use case you suggested (below, if > > > you don't have a copy of the original message sent to the abfab list). > > > > > > Basically, I've reviewed the suggestion and I'm not quite sure what the > > > use case actually is? > > > > > > First, it seems as though most all of the content in the text you've > > > submitted simply describes why federated authentication in general is a > > > good thing - user registration at the user's "home" identity provider, > > > better user experience, etc. In your case, the mobile network operator is > > > the IdP, but they would be a home organisation to some users and > > > consequently an IdP, just like any other organisation performing the same > > > task. I'm not arguing that you're not right about federated > > > authentication being a good thing - but that's not the purpose of this > > > document. > > > > > > Second, the one thing that seems like it could be different at first > > > glance in your use case is that you have a layered architecture where > > > users are using mobile devices, attaching to the network using standard > > > means, and then performing federated authentication from their devices. > > > However, I don't see how this is different at all - applications that > > > users on their mobile devices are using contact the home IdP (in this > > > case it so happens their home IdP is run by the network provider) and > > > authenticate the user based upon that. That's standard federated > > > authentication, just from a mobile device instead of, say, a desktop or > > > laptop. > > > > > > I think there's a good argument in there that mobile telecoms providers > > > might make a good class of IdP, but unfortunately that's not applicable > > > to this document, I don't think. > > > > > > The key thing is that I don't see any new particular applications or use > > > cases for federated authentication in your text, just a so I'm struggling > > > to see how, or if, it fits into the use case document. > > > > > > Yinxing - If you think I'm misunderstanding your use case, please do get > > > back in touch and we can try to figure out what it is and how it fits > > > into the document. > > > > > > Everyone else - If anyone disagrees with this (if I'm missing something > > > obvious here), then please let me know where I'm going wrong... > > > > > > R. > > > -- > > > Dr Rhys Smith: Identity, Access, and Middleware Specialist > > > Cardiff University & JANET(UK) > > > > > > email: [email protected] / [email protected] > > > GPG: 0xDE2F024C > > > > > > On 2 Aug 2011, at 20:53, [email protected] wrote: > > > > > >> > > >> Dear Rhys Smith, > > >> > > >> According to the action in IETF#81, I summarized the use case in > > >> draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01. > > >> Please review it. > > >> > > >> Thanks! > > >> > > >> Yinxing Wei > > >> > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> 4.x. Federated Cross-Layer Access > > >> > > >> Telecom operators have a communication network infrastructures to > > >> provider users with a wealthy of access methods. Telecom operators > > >> have a huge number of registered users, and they can provide trusted > > >> identity and higher security. Therefore they have a natural advantage > > >> to act as an Identity Provider (IdP) to serve for service providers. > > >> On the contrary most service providers on the Internet have limited > > >> amount of users and can not assure the security of user identity, but > > >> they can provide abundant kinds of service. Furthermore, user is > > >> reluctant to register too many accounts because it is inconvenient to > > >> remember dozens of passwords. > > >> > > >> Telecom network supports Web or non-Web application. In some cases > > >> user prefers to choose non-Web application, e.g. Messaging service, > > >> VoIP, EMail service, etc. Based on the result of network stratum > > >> authentication and authorization, User equipment (UE) can access > > >> applications without doing another authentication and authorization > > >> procedure. In this way, the system can implement federated > > >> cross-layer > > >> access. Firstly mutual authentication is performed between UE and > > >> Network, secondly UE accesses Application based on the result of > > >> network stratum's authentication. In this case, a federation is > > >> formed > > >> between Network and Application. The brief steps are as follows: > > >> > > >> 1. When UE attaches the Network, mutual authentication is performed > > >> master session key is created between them. > > >> 2. UE visits non-Web Application, e.g Messaging service, VoIP > > >> service, or Email service. > > >> 3. Application has no information about the UE. The Application > > >> contacts Network to validate the authentication result in the > > >> network stratum. Application can find Network according to the > > >> configuration or dynamical discovery protocol. > > >> 4. Network responds to Application with authentication result. > > >> 5. UE is authorized to access the Application. > > >> > > >> For federated cross-layer access, Network can assure the Application > > >> of the authenticity of user's identity, share some of use profile > > >> with Application. These can bring some benefits to stakeholders: > > >> > > >> o For telecom operators, they can provide identity service, trusted > > >> security service, mobile payment service and sharing some user > > >> profiles according user's preferences. Telecom operators is not > > >> just providing pipeline for communication, but also become a part > > >> of > > >> service value chain as an Identity Provider. > > >> o For service providers, they can focus on core business and reuse > > >> capabilities provided by telecom operators without worrying about > > >> sources of users. > > >> o For end users, they can enjoy seamless service experiences and > > >> improve security and privacy. > > >> > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> -------------------------------------------------------- > > >> ZTE Information Security Notice: The information contained in this mail > > >> is solely property of the sender's organization. This mail communication > > >> is confidential. Recipients named above are obligated to maintain > > >> secrecy and are not permitted to disclose the contents of this > > >> communication to others. > > >> This email and any files transmitted with it are confidential and > > >> intended solely for the use of the individual or entity to whom they are > > >> addressed. If you have received this email in error please notify the > > >> originator of the message. Any views expressed in this message are those > > >> of the individual sender. > > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > >> system. > > >> > > > > > > _______________________________________________ > > > abfab mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/abfab > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail is > > solely property of the sender's organization. This mail communication is > > confidential. Recipients named above are obligated to maintain secrecy and > > are not permitted to disclose the contents of this communication to others. > > This email and any files transmitted with it are confidential and intended > > solely for the use of the individual or entity to whom they are addressed. > > If you have received this email in error please notify the originator of > > the message. Any views expressed in this message are those of the > > individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
