Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access"

From: Rhys Smith <[email-masked]>
Date: Sat, 22 Oct 2011 15:51:49 -0400

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-masked] / [email-masked]
GPG: 0xDE2F024C

On 2 Aug 2011, at 20:53, [email-masked] 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.

---

From: [email-masked]
Date: Mon, 24 Oct 2011 10:50:11 +0800

Hi, Rhys 

  Thanks for your comments. Clarifications are inline.

  Hopefully, we can reach consensus on this use case.

Rhys Smith <[email-masked]> 
发件人:  [email-masked]
2011/10/23 03:51

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked], [email-masked]
主题
Re: Please review the use case "4.x Federated Cross-Layer Access"

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.

Yinxing#1> 

For the text "but they would be a home organisation to some users and 
consequently an IdP, just like any other organisation performing the same 
task.". I could not understand it well. How does it relate to the use 
case?

For the text "but that's not the purpose of this document", the 
clarification is as follows:
(1), Federated identity is in the scope of abfab wg,and the case also 
supports non-web application.
(2), in the section 3. Context of Use Cases in this document 
(draft-ietf-usecases-01), it says: 
In the interest of promoting the development of technology of broad
applicability, the present authors welcome use cases and requirements
from other sectors and communities.

This is my consideration for the use case of  "Federated Cross-Layer 
Access".

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.

Yinxing#2>The point is that the mobile network infrastructure has already 
had security capabilities (e.g. authentication, integrity and 
confidentiality ) which is mandatory for user equipment attacked to 
network.
Application can make use of this capability without duplicating the 
similar task done in network layer. As to desktop or laptop, when they 
connect to the network, the authentication is performed in other way 
provided by network operators.

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.

Yinxing#3>refer to the reply in Yinxing#1>

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.

Dear Rhys Smith, 

Thanks! 

Yinxing Wei 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------------------------------------------------------
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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Oct 2011 10:07:59 +0300

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:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: [email-masked]
Date: Mon, 24 Oct 2011 15:22:36 +0800

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-masked]> 
2011/10/24 15:07

收件人
Rhys Smith <[email-masked]>
抄送
Hannes Tschofenig <[email-masked]>, [email-masked], 
[email-masked], [email-masked], [email-masked]
主题
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.

Ciao
Hannes

use case actually is?

>> 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.
system.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Oct 2011 11:24:07 +0300

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-masked] 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-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
> 主题

---

From: [email-masked]
Date: Mon, 24 Oct 2011 16:42:16 +0800

Hi, Hannes

  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?

-------
Yinxing

2011/10/24 16:24

收件人
[email-masked]
抄送
Hannes Tschofenig <[email-masked]>, [email-masked], 
[email-masked], [email-masked], Rhys Smith 
<[email-masked]>
主题
Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access"

Hi Yinxing, 

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

> 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.
> 
> If you don't want to use AKA directly within EAP but add an additional 
GBA run beforehand you can do that as well.
> > 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).
> > 
> > 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...

> >> 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.
system.
system.

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 24 Oct 2011 11:28:34 +0200

On Oct 24, 2011, at 10:42 AM, [email-masked] wrote:

Hi Yinxing,

>   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

> Hannes Tschofenig <[email-masked]>, [email-masked], [email-masked], [email-masked], Rhys Smith <[email-masked]>
> 主题

---

From: Leif Johansson <[email-masked]>
Date: Mon, 24 Oct 2011 15:15:05 +0200

>>   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. 

I'm assuming we're talking about keeping draft-wei-abfab-fcla an
individual submission then?

	Leif