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

From: Rhys Smith <[email-masked]>
Date: Tue, 1 Nov 2011 23:06:35 +0000

Hi Yinxing, (cc:ed to abfab list for discussion),

Some answers to your answers below, followed by some suggested rewording. 

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

1 - Yes, federated identity is in the scope of the WG. But the purpose of the working group is not to explain why federated identity in general is a good thing.

2 - Absolutely, please don't misunderstand, I'm happy to accept all valid use cases that people come up with...

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

OK, yes, I see that in your particular use case the process would be slightly different than in normal use cases, and so therefore might well be worthy of including in the use case doc - if your separate I-D gains consensus.

If it is to go in the use case doc, however, the current text doesn't really fit in the document as it stands (both in terms of style and content). It really does say a lot of unnecessary things (e.g. federated access is good because it means users don't have to remember multiple credentials) and things that I'm sure people (including myself) would argue with (e.g. do all telecom operators always provide trusted identity? I think not!).

So I've had a go at writing my own version of this use case trying to draw out the main points that you're arguing for. Does this capture what is trying to be said sufficiently well? (It still needs tidying up, but I'm just trying to get the gist of your use case first).

=====

Accessing Applications from Devices on a Mobile Telecoms Infrastructure

Mobile telecom operators typically have the following properties:

    * A large collection of registered users, many of whom may have identities registered to a fairly high level of assurance (often for payment purposes). However, not all users will have this property - for example, non-contract customers in countries with low levels of identity registration requirements.

    * An existing network infrastructure capable of authenticating a mobile device, and by inference, its owner.

    * A large collection of applications (both web-based and non web-based) that its users wish to access using their mobile device. These applications could be hosted by the mobile telecoms operator directly, or could be any application or system on the internet - for example, network messaging services, VoIP, email, etc.

At present, authentication to these applications will be typically configured manually by the user on their mobile device but inputting their (usually pre-provisioned out-of-band) credentials for that application - one per application.

The use of ABFAB technologies in this case, via a mechanism dubbed "federated cross-layer access" (see [ref]) would enhance the user experience of using these applications on mobile devices greatly. Federated cross-layer access would make use of the initial mutual authentication between device and network to enable subsequent authentication and authorisation to happen in a seamless manner for the user of that device authenticating to applications.

=====

Rhys.
--
Dr Rhys Smith: Identity, Access, and Middleware Specialist
Cardiff University & JANET(UK)

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2011 21:27:03 -0400

>>>>> "Rhys" == Rhys Smith <[email-masked]> writes:

    Rhys> The use of ABFAB technologies in this case, via a mechanism
    Rhys> dubbed "federated cross-layer access" (see [ref]) would
    Rhys> enhance the user experience of using these applications on
    Rhys> mobile devices greatly. Federated cross-layer access would
    Rhys> make use of the initial mutual authentication between device
    Rhys> and network to enable subsequent authentication and
    Rhys> authorisation to happen in a seamless manner for the user of
    Rhys> that device authenticating to applications.

I'm not fond of the architecture of re-using the authentication or at
least am nervous about the architectural coupling involved.  Why isn't
it sufficient to simply re-use the credential? I.E. we cann't we perform
a second mutual authentication.?

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 02 Nov 2011 09:20:44 +0100

>>> "Rhys" == Rhys Smith<[email-masked]>  writes:
>

Well, I guess that the point is exactly that, to avoid that second 
mutual authentication by resuing cryptographic material generated during 
the network authentication. An average user would like to enter his PIN 
number only once, when the device starts, and then, he can access 
services seamlessly, without being prompted about the PIN number again. 
This is even more interesting if instead a PIN number the user has to 
write a passphrase (not thinking in a mobile phone now, but in a 
WPA-enterprise authentication, for example).

If you are thinking on providing SSO within all the services of the 
federation, as we do in our kerberized proposal, the intention is to 
incorporate the network access as another service, without worrying in 
which layer it works. As it is usually the first service accesed by the 
user in a session, it would be in charge to "bootstrapp" the SSO.

Regards,
Alejandro

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

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 2 Nov 2011 10:21:33 +0100

On Nov 2, 2011, at 9:20 AM, Alejandro Perez Mendez wrote:

> Well, I guess that the point is exactly that, to avoid that second mutual authentication by resuing cryptographic material generated during the network authentication. An average user would like to enter his PIN number only once, when the device starts, and then, he can access services seamlessly, without being prompted about the PIN number again. This is even more interesting if instead a PIN number the user has to write a passphrase (not thinking in a mobile phone now, but in a WPA-enterprise authentication, for example).
> 
> If you are thinking on providing SSO within all the services of the federation, as we do in our kerberized proposal, the intention is to incorporate the network access as another service, without worrying in which layer it works. As it is usually the first service accesed by the user in a session, it would be in charge to "bootstrapp" the SSO.

yes, I agree with that. Furthermore, I can imagine mobile operators offering brokered services (operator A strikes a deal with SaaS provider B) to their users, by definition the authentication process of the operator is the one you want to rely on. I could also imagine a step-up authentication sort of scenario, in which the network authentication acts as the first factor and another authentication method is used as additional authentication for services that have a demand for stronger authentication.

Klaas

P.S. I like Rhys' wording

---

From: [email-masked]
Date: Wed, 2 Nov 2011 23:05:25 +0800

Hi, Rhys

  Thanks for your clarifications.
  I agree that the whole document SHOULD conforms with the same style. I 
appreciate your rewording work.

My comment is as follow.
=====

Accessing Applications from Devices on a Mobile Telecoms Infrastructure
Yinxing#1> Shall the use case be limted in Mobile Telecoms Infrastructure? 
The mobile access is just one specific example, some other access types 
(e.g. fixed-line access such as ADSL access) may need to be considered. 
My suggestion is to remove "Mobile" in the title.

    * A large collection of registered users, many of whom may have 
identities registered to a fairly high level of assurance (often for 
payment purposes). However, not all users will have this property - for 
example, non-contract customers in countries with low levels of identity 
registration requirements.

    * An existing network infrastructure capable of authenticating a 
mobile device, and by inference, its owner.

    * A large collection of applications (both web-based and non 
web-based) that its users wish to access using their mobile device. These 
applications could be hosted by the mobile telecoms operator directly, or 
could be any application or system on the internet - for example, network 
messaging services, VoIP, email, etc.

At present, authentication to these applications will be typically 
configured manually by the user on their mobile device but inputting their 
(usually pre-provisioned out-of-band) credentials for that application - 
one per application.

The use of ABFAB technologies in this case, via a mechanism dubbed 
"federated cross-layer access" (see [ref]) would enhance the user 
experience of using these applications on mobile devices greatly. 
Federated cross-layer access would make use of the initial mutual 
authentication between device and network to enable subsequent 
authentication and authorisation to happen in a seamless manner for the 
user of that device authenticating to applications.

=====

-------------
Best Regards!
Yinxing Wei

Rhys Smith <[email-masked]> 
发件人:  [email-masked]
2011/11/02 07:06

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

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. 

1 - Yes, federated identity is in the scope of the WG. But the purpose of 
the working group is not to explain why federated identity in general is a 
good thing.

2 - Absolutely, please don't misunderstand, I'm happy to accept all valid 
use cases that people come up with...

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. 

OK, yes, I see that in your particular use case the process would be 
slightly different than in normal use cases, and so therefore might well 
be worthy of including in the use case doc - if your separate I-D gains 
consensus.

If it is to go in the use case doc, however, the current text doesn't 
really fit in the document as it stands (both in terms of style and 
content). It really does say a lot of unnecessary things (e.g. federated 
access is good because it means users don't have to remember multiple 
credentials) and things that I'm sure people (including myself) would 
argue with (e.g. do all telecom operators always provide trusted identity? 
I think not!).

So I've had a go at writing my own version of this use case trying to draw 
out the main points that you're arguing for. Does this capture what is 
trying to be said sufficiently well? (It still needs tidying up, but I'm 
just trying to get the gist of your use case first).

=====

    * A large collection of registered users, many of whom may have 
identities registered to a fairly high level of assurance (often for 
payment purposes). However, not all users will have this property - for 
example, non-contract customers in countries with low levels of identity 
registration requirements.

    * An existing network infrastructure capable of authenticating a 
mobile device, and by inference, its owner.

    * A large collection of applications (both web-based and non 
web-based) that its users wish to access using their mobile device. These 
applications could be hosted by the mobile telecoms operator directly, or 
could be any application or system on the internet - for example, network 
messaging services, VoIP, email, etc.

At present, authentication to these applications will be typically 
configured manually by the user on their mobile device but inputting their 
(usually pre-provisioned out-of-band) credentials for that application - 
one per application.

The use of ABFAB technologies in this case, via a mechanism dubbed 
"federated cross-layer access" (see [ref]) would enhance the user 
experience of using these applications on mobile devices greatly. 
Federated cross-layer access would make use of the initial mutual 
authentication between device and network to enable subsequent 
authentication and authorisation to happen in a seamless manner for the 
user of that device authenticating to applications.

=====

Rhys.

--------------------------------------------------------
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: Rhys Smith <[email-masked]>
Date: Wed, 2 Nov 2011 18:34:54 +0000

On 2 Nov 2011, at 15:05, [email-masked] wrote:

> Yinxing#1> Shall the use case be limted in Mobile Telecoms Infrastructure? The mobile access is just one specific example, some other access types (e.g. fixed-line access such as ADSL access) may need to be considered. 

Good point - when I was reading your work I was assuming mobile telecoms - an incorrect assumption on my part. I'll remove Mobile as suggested and put in the use case doc.

R.

---

From: Rhys Smith <[email-masked]>
Date: Wed, 2 Nov 2011 19:07:16 +0000

> a second mutual authentication.?

Well, not my use case - but I was assuming exactly that - a second mutual auth without having to involve the user, rather than actual reuse of a single authentication event...

R.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Nov 2011 18:19:52 -0400

>>>>> "Rhys" == Rhys Smith <[email-masked]> writes:

    Rhys> On 2 Nov 2011, at 15:05, [email-masked] wrote:
    Rhys>     Accessing Applications from Devices on a Mobile Telecoms
    Rhys> Infrastructure Yinxing#1> Shall the use case be limted in
    Rhys> Mobile Telecoms Infrastructure?  The mobile access is just one
    Rhys> specific example, some other access types (e.g. fixed-line
    Rhys> access such as ADSL access) may need to be considered.  My
    Rhys> suggestion is to remove "Mobile" in the title.

    Rhys> Good point - when I was reading your work I was assuming
    Rhys> mobile telecoms - an incorrect assumption on my part. I'll
    Rhys> remove Mobile as suggested and put in the use case doc.

    Rhys> R.  -- Dr Rhys Smith: Identity, Access, and Middleware
    Rhys> Specialist Cardiff University & JANET(UK)

I object to this going into the use case doc until we resolve the
question about authentication vs credential re-use.
I want wording that is neutral on that subject or that favors credential
re-use.

Obviously, if I'm in the rough I'll stand aside.

---

From: Rhys Smith <[email-masked]>
Date: Wed, 2 Nov 2011 23:11:00 +0000

> I want wording that is neutral on that subject or that favors credential

OK - you're right, it's important that this is made clear in the use case.

Yinxing, what does the federated cross-layer idea that you're promoting actually do in terms of reuse of an authentication instance versus reuse of a credential to create new authentications? We need to make sure the description is accurate, and when it's accurate, we then need to make sure that there's consensus in this group that this (whatever your ideas are) is a good thing.

R.

---

From: [email-masked]
Date: Thu, 3 Nov 2011 19:35:56 +0800

Hi, Rhys

   I agree with the point that credential re-use is more accurate. If 
someone prefers to use the result of network access authentication, the 
view of credential re-use is OK. If does not, one can choose to initiate 
another authentication  for higher security, it also works. It MAY depend 
on local policy.

-----------
Yinxing Wei

2011/11/03 07:11

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

Yinxing, what does the federated cross-layer idea that you're promoting 
actually do in terms of reuse of an authentication instance versus reuse 
of a credential to create new authentications? We need to make sure the 
description is accurate, and when it's accurate, we then need to make sure 
that there's consensus in this group that this (whatever your ideas are) 
is a good thing.

R.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Nov 2011 13:39:16 -0400

>>>>> "wei" == wei yinxing <[email-masked]> writes:

    wei> Hi, Rhys

    wei>    I agree with the point that credential re-use is more
    wei> accurate. If someone prefers to use the result of network
    wei> access authentication, the view of credential re-use is OK. If
    wei> does not, one can choose to initiate another authentication for
    wei> higher security, it also works. It MAY depend on local policy.

OK.
I expect this issue will pop up again if we go beyond use-case, but I
think that can wait until a mechanism discussion happens.

--Sam

---

From: [email-masked]
Date: Fri, 4 Nov 2011 09:37:40 +0800

Hi, Sam

 I do not understand the text "that can wait until a mechanism discussion 
happens" you wrote. For my experience, use case is developed at first 
stage and it is independent of mechanisms. Currently, the use case do 
exist and can bring some benifits.

 My suggestion is to seperate the disussions between the use case and 
potential solutions. If a use case is OK, we can document it firstly. In 
the second stage we try to find solutions or mechanisms for that case. We 
may evaluate some candidated solutions at this stage.

------------
Yinxing Wei

Sam Hartman <[email-masked]> 
2011/11/04 01:39

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

    wei> Hi, Rhys

OK.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Nov 2011 22:23:53 -0400

>>>>> "wei" == wei yinxing <[email-masked]> writes:

    wei>  My suggestion is to seperate the disussions between the use
    wei> case and potential solutions. 

that is what I was proposing.  I have some concerns about one of the
solutions you propose, but think discussing those concerns can wait
until/if the working group considers such a mechanism.

--Sam