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. > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
