Subject: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt

From: [email-masked]
Date: Mon, 07 Mar 2011 17:30:02 -0800

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

    Title         : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases

    Author(s)     : R. Smith, et al
    Filename      : draft-ietf-abfab-usecases-00.txt
    Pages         : 7
    Date          : 2011-03-07
    
Federated authentication is most commonly associated with Web-based
   services, but there is growing interest in the application of
   federated authentication for non-Web services.  The goal of this
   document is to drive the development of requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Gabriel López <[email-masked]>
Date: Tue, 08 Mar 2011 08:38:31 +0100

Hi,

I always thought in the campus use case like a good example for this wg. 
I mean, students and professors roaming between universities and 
requesting federated access to service such as FTP, SSH, SMTP, etc. etc. 
Something that eduroam is not providing currently. Do you plan on the 
description of this scenario in the draft?

Best regards, Gabi.

El 08/03/11 02:30, [email-masked] escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Mar 2011 07:36:12 -0500

Could we get you to work on some text for this campus use case?

Also, do e actually have campuses who have indicated that deploying a
new technology to solve this use case would be worthwhile for them?

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 8 Mar 2011 14:47:36 +0000

> new technology to solve this use case would be worthwhile for them?

We have to do something. For some of us that something might be deploying a SAML solution, or it might be EAP for some, and with ssh it may well just be pushing keys around, but the current state is a problem.

-- Scott

---

From: Gabriel López <[email-masked]>
Date: Wed, 09 Mar 2011 11:54:20 +0100

> Could we get you to work on some text for this campus use case?

yes, we can provide some text for this use case
> new technology to solve this use case would be worthwhile for them?

As far as I know it was the main objective of the Moonshot proposal 
(describing Kerberos like an example of technology easily adaptable to 
provide federated services to federations like eduroam). Indeed, If I'm 
not wrong it (in general) should be the objective of the moonshot tasks 
in GN3 :)

I have been talking with Diego (RedIris) and it seems there has been 
interest of some universities for using federated SSH. Indeed, they 
(RedIris) deployed a proposal (FedSSH) for the Red Española de 
Supercomputación (Supercomputing Spanish Network). Also, the Internet2 
web page 
(https://spaces.internet2.edu/display/COmanage/Functional+Roadmap) 
describes future work on a Federated SSH toolset ("[... ] leveraging 
work within IETF and in Project Moonshot").

Others alternatives that have been taking into account by universities 
(UMU among them) is to make use of the CAS Proxy for services like IMAP, 
SSH, SAMBA, etc. In fact, UMU has some of these services running through 
pamCAS.

So, it seems there is interest in this use case.

     Best regards, Gabi.

email:[email-masked]

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 9 Mar 2011 12:26:12 -0800 (PST)

> Also, do we actually have campuses who have indicated that deploying a

Some interested parties are not central IT organizations at universities 
but rather research projects, typically e-science, typically very 
multi-organizational, often called "Virtual Organizations" or VOs.  These 
orgs have their own legacy technology issues but in many cases are very 
interested in solving these problems, eg making the secure 
multi-organizational use of ssh more scalable, interested enough to 
consider new technologies.

  - RL "Bob"

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Mar 2011 15:32:48 -0500

>>>>> "RL" == RL 'Bob' Morgan <[email-masked]> writes:

    >> Also, do we actually have campuses who have indicated that
    >> deploying a new technology to solve this use case would be
    >> worthwhile for them?

    RL> Some interested parties are not central IT organizations at
    RL> universities but rather research projects, typically e-science,
    RL> typically very multi-organizational, often called "Virtual
    RL> Organizations" or VOs.  These orgs have their own legacy
    RL> technology issues but in many cases are very interested in
    RL> solving these problems, eg making the secure
    RL> multi-organizational use of ssh more scalable, interested enough
    RL> to consider new technologies.

we've definitely seen significant interest from the VO use case. However
I'm not entirely sure that's the same as the campus use case.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 9 Mar 2011 11:35:51 -0900

> I'm not entirely sure that's the same as the campus use case.

I don't think so.  In the grid context a VO can
be pretty dynamic.  Might be worth checking out
the use cases at the Globus Consortium and the 
Open Grid Foundation.

Melinda

---

From: Leif Johansson <[email-masked]>
Date: Wed, 09 Mar 2011 21:58:46 +0100

>> I'm not entirely sure that's the same as the campus use case.
not speaking as chair in any way...

> the use cases at the Globus Consortium and the 

Right. We touched on this very briefly in China I think. There was
a discussion about the need to incorporate attribute authorities
that are separate from identity providers in the model. In the
WebSSO case this corresponds to an entity that (only) implements
attribute SAML query (typically using the SOAP binding).

In WebSSO land (and I suspect this will be true for abfab aswell)
there are different schools of thought as to how such attribute
authorities become part of an authentication flow. One school
favors proxy IdPs and one prefers having the service provider
query the AA directly. Both have their benefits and drawbacks.

	Cheers Leif

---

From: Rhys Smith <[email-masked]>
Date: Thu, 24 Mar 2011 10:01:24 +0000

Obviously happy to receive any additional use case text people think is important.

Federated ssh is something that is a prime factor of the Grid and/or HPC use-cases already included in the 00 draft - though both use cases don't currently mention any specific technologies (e.g. the current text of "federated access to HPC systems" is pretty vague). Those technologies, including federated SSH, should probably be more specifically enumerated in the next draft...

But a more generic use case discussing federated access to organisational services such as SSH, SMTP, and whatnot does seem probably worth including. All text gratefully received!

Regards,
R.

On 8 Mar 2011, at 07:38, Gabriel López wrote:

> 
> Hi,
> 
> I always thought in the campus use case like a good example for this wg. I mean, students and professors roaming between universities and requesting federated access to service such as FTP, SSH, SMTP, etc. etc. Something that eduroam is not providing currently. Do you plan on the description of this scenario in the draft?
> 
> Best regards, Gabi.
> 
> email: 
> [email-masked]

--
----------------------------------------------------------------------
Dr Rhys Smith                                   e: [email-masked]
Engineering Consultant: Identity & Access Management  (GPG:0xDE2F024C)
Information Services,
Cardiff University,                            t: +44 (0) 29 2087 0126
39-41 Park Place, Cardiff,                     f: +44 (0) 29 2087 4285
CF10 3BB, United Kingdom.                      m: +44 (0) 7968 087 821
----------------------------------------------------------------------

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 24 Mar 2011 17:44:36 -0700

This is totally in left field, and my not make any sense at all, but is anyone thinking about DBMS access?

Nobody seems to do it, but I don't see any reason why a "thick" client application shouldn't want to use a WAN connection to a DBMS as part of its operation.

>>> implementation to automatically retrieve the ASCII version of the

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Mar 2011 04:36:48 -0400

Doing something with DBMSes would be interesting.
I think using ABFAB with postgres for example would be relatively easy.

I guess the interesting challenge is coming up with a specific
application where this would be desired.

--Sam

---

From: Tim Bannister <[email-masked]>
Date: Mon, 28 Mar 2011 10:33:23 +0100

> application where this would be desired.

How about SPARQL access to a triplestore? Yes, it's typically done over
HTTP – but not necessarily in a web browser. Linked data sets are also
commonly provided with open access, but updates and inserts might well
require federated authnz. I think this kind of HTTP access is an
important use case for the technologies the group will deliver.

My other use HTTP-derived use case would be SCEP for online certificate
enrollment: http://tools.ietf.org/html/draft-nourse-scep-22
…but this is a whole new world of careful complexity. I'm mentioning it
just as an aside.

I've got one final protocol. Its origins are in HTTP, it's used on the
web, but it's different enough to matter: RTSP. Streaming is another
area where Abfab promises new benefits.

-- 
Tim Bannister
IT Services, The University of Manchester

e: [email-masked]
w: http://www.manchester.ac.uk/itservices

---

From: Tom Scavo <[email-masked]>
Date: Mon, 28 Mar 2011 08:39:14 -0400

> …but this is a whole new world of careful complexity. I'm mentioning it

In some situations, at least, SCEP should be able to leverage
browser-based protocol flows just fine (but I haven't done it, so who
knows). For instance, it's pretty easy to see how SAML Web Browser SSO
can lead right into a SCEP workflow.

Cheers,
Tom

---

From: Luke Howard <[email-masked]>
Date: Mon, 28 Mar 2011 23:49:34 +1100

> area where Abfab promises new benefits.

What about SIP? OK, it's a potentially a fairly chatty protocol, but it seems that at some point VoIP is going to be more used in mobile devices, and those that support WiFi already have EAP supplicants. I'd kind of like to get GSS into Asterisk at some point, but I've been thinking about that for years and haven't done it yet.

-- Luke

---

From: Leif Johansson <[email-masked]>
Date: Tue, 29 Mar 2011 09:07:01 +0200

> What about SIP? OK, it's a potentially a fairly chatty protocol, but it seems that at some point VoIP is going to be more used in mobile devices, and those that support WiFi already have EAP suppli…

I seem to recall that Sam was thinking about how to "port"
"Negotiate-NG" to SIP a couple of years ago.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 03:38:34 -0400

The issue is that SIP has a fairly constrained authentication model
today which doesn't meet our needs.
We could either use something like draft-howlet-radsec-kmp to key it
out-of-band or we could revise the authentication model.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Tue, 29 Mar 2011 08:05:25 +0000

> today which doesn't meet our needs.

Constrained in what sense?

Josh.

Book your place at Networkshop 2011  http://www.ja.net/networkshop

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 04:17:06 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    >> The issue is that SIP has a fairly constrained authentication
    >> model today which doesn't meet our needs.

    Josh> Constrained in what sense?

Only supports digest.

There is a Microsoft-specific thing for GSS-krb5 that is not
standardized and that is krb5 specific.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 29 Mar 2011 11:34:44 +0200

> standardized and that is krb5 specific.

Right but can't you shoe-horn something that looks like negotiate
onto the SIP request-response model, especially if you do TCP?

	Cheers Leif

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 29 Mar 2011 12:07:12 +0200

On 3/29/11 11:34 AM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>>>>>>> "Josh" == Josh Howlett<[email-masked]>  writes:
>>

I think we should talk to the SIP crowd, it does sound appealing to get 
in touch with such a large community that does have some (federated) 
authentication challenges....

Klaas

---

From: Gabriel López <[email-masked]>
Date: Tue, 29 Mar 2011 12:21:00 +0200

El 29/03/11 12:07, Klaas Wierenga escribió:
>
> I think we should talk to the SIP crowd, it does sound appealing to 
> get in touch with such a large community that does have some 
> (federated) authentication challenges....

Federated SIP would be interesting if you could allow roaming users to 
make use of their softphones to issue and receive calls when they roams 
to visiting institutions. Moreover, you could provide some kind of SSO 
token to avoid re-registering and re-autentications. SIP proxies could 
solve this issue directly by redirections but sometimes firewalls filter 
those calls. Maybe the VoIP operators  in such organizations could 
clarify this scenario.

Best regards, Gabi.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 29 Mar 2011 13:01:31 +0200

> those calls. Maybe the VoIP operators  in such organizations could

(not as chair in any of this thread btw) The "Negotiate-ng" draft had a
re-authentication token to be used for that purpose.

	Cheers Leif

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 29 Mar 2011 13:30:43 +0200

Hi Rhys,

following you can find UMU's first draft for the campus use case. 
Comments are welcome.

CAMPUS USE CASE
---------------------------------

Universities usually offer different kind of services to their students 
and staff, ranging from basic network access to the more advanced campus 
intranet, passing through services such as remote computing systems, 
storage, mail and printing services, etc. Access control to these 
services is usually managed by means of end user’s login and password.

Although it is fairly extended that users can make use of the same 
credentials to access different services, thanks to a central identity 
information storage center within each university (e.g. LDAP or 
database), the authentication mechanism usually differs for each 
service. This heterogeneity leads to deployment and usability problems, 
as most of the authentication and authorization functionality must be 
implemented on each service that the university deploys. Usability 
issues are related with the lack of a Single Sign-On (SSO) service, 
avoiding users to re-introduce their credentials on each service access, 
and the existence of several configuration points where the user needs 
to configure authentication-related aspects (web browser, network 
supplicant, mail user agent, remote access software, etc...).

The issues described above are motivating service administrators to look 
for access control solutions that can be applied to a wider range of 
services. An example of this would be the deployment of CAS – Central 
Authentication Service (http://www.jasig.org/cas) as an authentication 
and SSO solution suitable for web services, or Kerberos [RFC 4120], 
broadly used to provide authentication and SSO for services like SSH, 
SMTP or POP. However, an integrated solution that can be applied to a 
wider range of services is still missing.

Beside, in order to help mobility of students and staff between 
different universities, there exists an increasing interest to provide 
these services also to users coming from other universities or 
organizations. These /foreign /users should be able to access the 
services at the /remote /institution making use of the credentials 
provided by their /home/ University, without the need of creating a new 
user profile for them in the visited one. This interest for federated 
services has already been demonstrated with the expansion of /eduroam 
/(_www.eduroam.or <http://www.eduroam.or/>_g), the secure international 
roaming network service that allows users belonging to one institution 
to get network access when visiting another institution. This federation 
is based on the deployment of EAP (Extensible Authentication Protocol) 
for authentication and a hierarchy of RADIUS servers for authorization 
and accounting. However, eduroam only covers the network access control, 
but has nothing to do with access control to upper layer services. 
Besides, several approaches to federate these upper layer services exist 
(e.g. Shibboleth, OpenID...), and some of them have even been deployed 
in several universities to manage access to specific services [SIR], but 
they are intended for web-based oriented services and do not apply to 
other application services.

For example, some universities have shown interest for using federated 
SSH. RedIris (http://www.rediris.es) deployed a proposal (FedSSH) for 
the Spanish Supercomputing Network. Also, the Internet2 web page 
describes future work on a Federated SSH toolset 
(_https://spaces.internet2.edu/display/COmanage/Functional+Roadmap_). 
Other federated services of interest, besides SSH and web-based 
services, are network storage (where students can store files related 
with different subjects and access them from any place within the 
campus) based on NFS (Network File System) or CIFS (Common Internet File 
System).

Hence, it is envisioned that universities will be very interested on a 
solution that can provide an unified and federated access to their 
services based on the already deployed AAA infrastructure (i.e. 
eduroam), providing an homogeneous authentication and SSO alternative 
that, on the one hand, simplifies deployment of new services, and on the 
other, improves their usability.

Best regards,
Alejandro

>> El 08/03/11 02:30,[email-masked]  escribió:
> Dr Rhys Smith                                   e:[email-masked]
> Engineering Consultant: Identity&  Access Management  (GPG:0xDE2F024C)
> Information Services,

---

From: Luke Howard <[email-masked]>
Date: Tue, 29 Mar 2011 23:34:43 +1100

> Federated SIP would be interesting if you could allow roaming users to make use of their softphones to issue and receive calls when they roams to visiting institutions. Moreover, you could provide some kind of SSO token to avoid re-registering and re-autentications. SIP proxies could solve this issue directly by redirections but sometimes firewalls filter those calls. Maybe the VoIP operators  in such organizations could clarify this scenario.

That sounds like a good idea. We already have a re-authentication token in mech_eap, see util_reauth.c :-)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Tue, 29 Mar 2011 23:36:47 +1100

> standardized and that is krb5 specific.

Unless there are IPR issues can't we just do what Microsoft does in [MS-SIPAE] and make it mechanism agnostic?

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 09:45:38 -0400

So, you're asking in the IETF context.
I don't know how the SIP community would respond to that.
We certainly can propose that and see what happens.