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
