An Approach for Integrating Kerberized non Web-based Services with

Web-based Identity Federations

Aleksandr Bersenev

1,2

, Arsen Hayrapetyan

, Marcus Hardt

and Michael Simon

Institute of Mathematics and Computer Sciences, Ural Federal University, Yekaterinburg, Russia

IMM UB RAS, Yekaterinburg, Russia

Steinbuch Centre for Computing (SCC), Karlsruhe Institute of Technology, Karlsruhe, Germany

Keywords:

Federation, Kerberos, SSO, SAML, LDAP-Facade, NFS.

Abstract:

Many identity federations are designed to be used with web browsers. This paper proposes an approach

for integrating non web-based applications with web-based identity federations using Kerberos protocol. We

evaluate this approach by making NFS server available for users of SAML-based identity federation of Baden-

Württemberg state of Germany. We make use of LDAP-Facade software for federating non web-based ser-

vices. We have modiﬁed the web-interface component of LDAP-Facade to enable the registration with kerber-

ized services. Our approach can be used without modiﬁcations on the client side.

1 INTRODUCTION

Identity federations allow users to authenticate on

services hosted by external organizations with their

home organization accounts. Rather than storing all

identities in the same place, each organization is re-

sponsible for keeping an up to date information about

its users and authenticating them, becoming the Iden-

tity Provider (IdP). Service Providers (SP) consume

the information from IdPs they trust.

There are a number of technologies for establish-

ing identity federations. Authors of (Pérez-Méndez

et al., 2014) divide them into three groups:

• Web-based identity federations which base on

standards like SAML (Security Assertion Markup

Language), OpenID (Open Identity) or OAuth

(Open Authorization);

• AAA-based (Authentication, Authorization and

Accounting) identity federations. They use pro-

tocols like RADIUS or Diameter for data transfer.

Both of those protocols support EAP (Extensible

Authentication Protocol) for authentication. An

example of a federation of this type is the eduroam

network;

• Application-Agnostic Identity Federations, which

rely on Kerberos in cross-realm operation or on

middleware layers like GSS-API (Generic Secu-

rity Services API) (Linn, 2000) or SASL (Sim-

ple Authentication and Security Layer) (Melnikov

and Zeilenga, 2006).

In addition, Grid Trust Federations are based on

X.509 standard PKI and use GSS-API middleware

layer for authentication and authorization.

This paper focuses on web-based identity federa-

tions. On this type of federations the primary protocol

for communications with IdPs and SPs is HTTP, often

over TLS (Dierks and Rescorla, 2008). SPs usually

redirect browsers to the IdP for authentication and can

consume tokens from it.

However there are a lot of popular non web-based

protocols, for example SSH, NFS, RDP, IMAP or SIP.

Most implementations of these protocols can not use

authentication against web-based identity federations

out of the box yet, but instead support the Kerberos

authentication protocol.

In the ﬁrst part of this paper we propose an ap-

proach how to pass a federated authentication result

to a service with Kerberos protocol as a mediator.

Our approach does neither require modiﬁcation of the

Kerberos server nor of the service. Extensions on the

client side will be described.

In the second part we describe one way of how this

approach can be implemented in practice. We used

these components:

• NFS-Ganesha as an NFS (Network File System)

server implementation;

• SAML-based identity federation of Baden-

Württemberg state called bwIDM;

144

Bersenev A., Hayrapetyan A., Hardt M. and Simon M..

An Approach for Integrating Kerberized non Web-based Services with Web-based Identity Federations.

DOI: 10.5220/0005509901440150

In Proceedings of the 10th International Conference on Software Paradigm Trends (ICSOFT-PT-2015), pages 144-150

ISBN: 978-989-758-115-1

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

• Modiﬁed LDAP-Facade as an implementation of

an SP and its LDAP-backend as a storage for

service-local data.

The main contributions of this paper are:

• A concept of integrating non web-based services

using Kerberos authentication into Web-based

identity federations;

• Evaluation of the concept through the deployment

of the experimental setup and its testing.

1.1 The Background

The primary motivation for this work was to enable

federated SAML-based user access via NFS to the

LSDF, Large Scale Data Facility at Karlsruhe Institute

for Technology (KIT) (Garcia et al., 2011). The ap-

proach which we were to propose as a solution had to

be general enough to allow federated access to other

non Web-based applications and protocols.

The Baden-Württemberg state in Germany has an

identity federation called bwIDM federation

. It in-

cludes several dozens of IdPs from different univer-

sities and several SPs. The bwIDM federation is a

subfederation of another federation, the DFN-AAI

–

a Germany-wide identity federation for scientiﬁc in-

stitutions. DFN-AAI is based on SAML. Most of its

IdPs and SPs are using Shibboleth implementation of

SAML.

To add the SAML-based authentication features

to non web-based services the abstract layer called

LDAP-Facade was developed at Karlsruhe Institute

of Technology (KIT). It consists of an LDAP-server,

which is accessable for the non web-based services,

and a web-interface, which authenticates users with

SAML and allows them to manage data on the LDAP

server. They can register for a particular service (e.g.

add their entry to the LDAP), get their data, change

some parts of it (e.g. local service passwords), or un-

LDAP-Facade is already used to federate several

non web-based services in KIT. Some of them store

scientiﬁc data for more than 100 000 students in

Baden-Württemberg. This data can be accessed via

various protocols, but no NFSv4-based access was

available at the time of this writing.

NFSv4 has several features some other protocols

lack:

• It is standardized and supported by all major OS;

Föderiertes Identitätsmanagement der baden-

württembergischen Hochschulen, https://www.bwidm.de/,

last checked: 2015-02-27

DFN-AAI, https://www.aai.dfn.de/, last checked:

2015-02-27

• It is scalable because of optional parallel opera-

tion (pNFS);

• It uses traditional Unix permissions model and

can use access control lists;

• It has a data encryption option.

Since Kerberos is the only protocol for user-based

authentication implemented by NFS servers (Adam-

son and Williams, 2014), we were looking for ways to

have the LDAP-Facade work with it. In the previous

version, NFS 4.0, it was required to implement two

alternative mechanisms for authentication: LIPKEY

and SPKM-3 (Shepler et al., 2003), but they were un-

supported by all major implementations and this re-

quirement was dropped in the NFS 4.1 standard (She-

pler et al., 2010).

The SAML-based bwIDM federation, LDAP-

Facade, Ganesha-NFS (as NFS server implementa-

tion) and Kerberos protocol served as building blocks

for the construction of a solution for the problem de-

scribed at the beginning of this section. Extending the

LDAP-Facade to Kerberos allowed us to apply the ap-

proach not only to NFS but to additional services as

well.

We found that our approach had nothing speciﬁc

to SAML or LDAP-Facade and we have extended it

to the abstract web-based federation.

1.2 Kerberos Authentication Protocol

The Kerberos protocol is described in detail in (Neu-

man et al., 2005). It requires a trusted third party and

uses symmetric key cryptography.

Figure 1: Typical Kerberos workﬂow.

The KDC (Key Distribution Center) is a server

part of Kerberos. It consists of two subservices: AS

(Authentication Server) and TGS (Ticket-Granting

Server). Tickets are used to verify the identity of the

client for a particular service.

The AS is responsible for user authentication

and for granting initial ticket (called Ticket Granting

AnApproachforIntegratingKerberizednonWeb-basedServiceswithWeb-basedIdentityFederations

145

Ticket or TGT) which veriﬁes the identity of a client

for TGS. Authentication is based on preshared key, so

AS has access to a database of keys for each client.

Usually, the client derives its key from the password

by using a string-to-key function. If an attacker man-

ages to capture AS_REP, he can try to bruteforce the

user password (Wu, 1999). The Kerberos speciﬁca-

tion does not handle this and recommends the use of

complex passwords. To protect from active attacks

of this type AS can require pre-authentication before

issuing the TGT.

TGS is responsible for issuing service tickets. The

service ticket is encrypted by the service key. Every

service has such a key, hence communication between

service and Kerberos is unnecessary.

Figure 1 shows the three data exchanges required

to autenticate to a service: AS_REQ/AS_REP,

TGS_REQ/TGS_REP and AP_REQ/AP_REP.

The Kerberos standard allows multiple

AS_REQ/AS_REP data exchanges, if needed.

2 RELATED WORK

To address federated identity issues for non web-

based services, the Application Bridging for Feder-

ated Access Beyond web (ABFAB) working group

was established (Smith, 2012). They focus on cre-

ating a design that will combine the existing proto-

cols, such as RADIUS, EAP and SAML. The group

uses GSS-API to integrate the established mecha-

nisms with application protocols.

The implementation of the set of standards devel-

oped by the ABFAB working group is the Moonshot

Project. It requires modiﬁcations of servers, clients

and an IdPs (Pérez-Méndez et al., 2014).

In the same time authors of (Marín-López et al.,

2011) proposed an approach of integrating Kerberos

pre-authentication with existing AAA (Authentica-

tion, Authorization and Accounting) infrastructure

by using EAP. Their approach requires modiﬁcation

of clients, Kerberos server, IdPs and modiﬁes the

Kerberos protocol removing the “statelessness” from

Kerberos’s Key Distribution Server (KDC).

Two years later the same group of authors pro-

posed to employ an authentication mechanism in-

dependent of Kerberos (Pérez-Méndez et al., 2013).

They use Protocol for Carrying Authentication for

Network Access (PANA) as out-of-band protocol.

This enables the use of standard Kerberos servers, but

requires modiﬁed clients.

The scope of all these projects is the AAA-based

identity federations. This is a big drawback for or-

ganizations, who use web-based identity federations

instead, like bwIDM, because they are not designed

to support such protocols and it requires a lot of orga-

nizational and development work to integrate them.

An approach to federating non web-based ser-

vices in web-based identity federations was described

in (Köhler et al., 2012). The authors federate ser-

vices by developing access control modules, using ex-

isting security interfaces of particular services, e.g.

the Pluggable Authentication Module (PAM) inter-

face used by many unix services, for example by the

SSH-server. These modules consume assertions from

the IdP. This approach works with applications that

are able to use PAM.

The same group of authors extended their work

in (Köhler et al., 2013) including the web registra-

tion application, called LDAP-Facade, and offering a

generic LDAP interface to services. We use a mod-

iﬁed LDAP-Facade to implement our approach in

practice.

3 PROPOSED APPROACH

The main idea of our approach is to set up a web-

to-kerberos service. This service forwards successful

authentication against a web-based identity federation

to KDC. To do so, it sends the user her client key via

the HTTPS (HTTP+TLS) protocol to protect from un-

trusted network. This key can be obtained either man-

ually by browser or automatically by a key-obtaining

script on the client side.

In contrast to federated Kerberos approach, which

requires every user to authenticate with KDC in their

home organization, KDC in our approach operates on

the SP-side (which can be in external organization).

The services share their keys with that KDC. After

the user has obtained her key, she can obtain TGT

from KDC with the command-line tools (e.g. kinit).

Having TGT it is possible to get service tickets from

TGS to authenticate to the service. Figure 2 shows

this workﬂow.

In our experimental setup the workﬂow on Fig-

ure 2 takes place as part of the user’s initial subscrip-

tion to the service and should occur only once. The

actual use of the kerberized service is then possible as

per workﬂow on the Figure 1.

In the rest of this section we present the important

aspects which should be considered when implement-

ing the proposed approach.

3.1 Initial Key Placement

There are several options how the client key can be

generated on the web-to-kerberos service at the ﬁrst

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

146

Figure 2: Before AS_REQ: User gets Kerberos client key

with HTTPS.

time:

1. From service-local password, speciﬁed by user

with the web-service. As said before, if the pass-

word is simple, the attacker, who has the AS_REP

message can try to bruteforce it. Password com-

plexity checks should be in place.

The key sending step is unnecessary – the client

can derive it from the password on his own host;

2. From the result of base64 of a long random string;

3. From the result of keyed-hash message authen-

tication code (HMAC) (Krawczyk et al., 1997)

cryptographic mechanism with a long string as a

key (shared between web-service and KDC) and

user principal as a message. The KDC needs to

be modiﬁed to obtain keys dynamically from the

HMAC mechanism.

When the ﬁrst or second option is used, KDC and

web-service must have access to a common key stor-

age. Most implementations of KDC support querying

data from a key storage with an LDAP protocol.

The third option can be used without common key

storage. The cost for this is the modiﬁcation of a Ker-

beros service and difﬁculties on user account depro-

visioning.

3.2 Converting Federated User

Identiﬁers to Kerberos Principals

To make Kerberos Principals unique for users with

the same names, but from different organizations, the

Kerberos principal name should include the unique

name of the IdP. It may be difﬁcult for a user to re-

member it, so some mapping from IdP names to short

name preﬁxes proved to be useful.

3.3 Authorization and Deprovisioning

The Kerberos standard (Neuman et al., 2005) does not

recommend services to base its authorization only on

ticket issuance because this check can be bypassed if

the application uses other authentication methods. If

it is necessary, the Kerberos server can be modiﬁed

to check client authorization before issuing each ser-

vice ticket. After the user account is deprovisioned

and has her record removed from the KDC database,

she is still able to authenticate with tickets she already

obtained. To minimize negative effects from it, the

maximum service ticket lifetime should be set to a

reasonably low value.

The authorization should be implemented on the

application level. Before the user is let in, the ap-

plication should check the user against her identity

federation. If the identity federation does not support

such types of checks, the application can make a re-

quest to SP web-service by using a common protocol,

like LDAP.

In our case, checks are done by the LDAP-Facade

and all provided attributes are mapped to a group-id

that can be used for authorization.

3.4 Security Considerations

Historically Kerberos protocol version 4 used only

DES (Data Encryption Standard) encryption, which

has an effective key size of 56 bits. This makes the

whole keyspace prone to brute-force attacks on mod-

ern hardware. In Kerberos version 5 the support of

other ciphers was added and DES was deprecated

by (Astrand and Yu, 2012). The DES encryption sup-

port should be turned off on both server and client.

To protect from replay attacks, a secure clock syn-

chronization protocol should be used where possible.

LDAP and HTTP protocols should be used only

with TLS.

4 IMPLEMENTATION

To evaluate deployment efforts and operation of

our approach in practice, we implemented it using

Ganesha-NFS as service, extended LDAP-Facade as

an SP and bwIDM as a SAML-based identity feder-

ation. The rest of this section describes these com-

ponents and the extensions we developed to integrate

them into our implementation.

4.1 LDAP-Facade

Two major LDAP-Facade components are a web-

application and an LDAP-server.

The web-application is an SP in terms of SAML. It

allows a user to log in with her home IdP and register

AnApproachforIntegratingKerberizednonWeb-basedServiceswithWeb-basedIdentityFederations

147

for one or several services. It keeps a database of reg-

istered users for each service which it makes available

to services via LDAP protocol. The LDAP directory

has a tree structure, the services’ data about users and

groups is located in non-intersecting subtrees (parti-

tions) of it. LDAP-Facade enables to store service-

local data (service-local password, local name, unique

identiﬁers, primary group identiﬁer and so on) in the

attributes of the user entry.

The authors of LDAP-Facade use specially-

conﬁgured ApacheDS open source implementation

of LDAP-Server, which has a Kerberos server em-

bedded. This Kerberos server stores KDC-speciﬁc

data (principal names, client and service keys, key

version numbers) in the entries of krb5KDCEntry

class (which is subclass of krb5Principal). The Ker-

beros server is tightly integrated with the LDAP part

of ApacheDS, for example, if the user entry has a

krb5PrincipalName attribute, her keys are regenerated

after each password change.

Our ﬁrst modiﬁcation of LDAP-Facade was

made to assign krb5KDCEntry class to the freshly-

created user accounts. Mandatory attributes

(krb5KeyVersionNumber and krb5PrincipalName)

are also ﬁlled. ApacheDS stores Kerberos keys in

the krb5Key attributes of entries which belong to

krb5KDCEntry class. Each krb5Key attribute con-

sists of a key type and a key itself and is encoded using

ASN.1 (Abstract Syntax Notation One) standard.

The second modiﬁcation of LDAP-Facade al-

lowed user to download her Kerberos client key from

the web-service. The web-service redirects the user

to her home IdP for authentication following stan-

dard SAML Web Browser SSO proﬁle (Hughes et al.,

2005).

4.2 NFS Speciﬁcs

We use Ganesha-NFS as NFS server, because it al-

lows to export clustered GPFS (General Parallel File

System) with pNFS protocol. Furthermore it works

in userspace, which allows debugging and patching it

more easily.

The setup with the NFS server implemented in

Linux kernel 3.19.0 on Gentoo Linux was also tested.

Both implementations support only Kerberos as

user-based authentication. They can operate in three

modes (security ﬂavors):

1. krb5 requires user to prove her identity cryp-

tographically on each RPC request. Identity of

server is also veriﬁed;

2. krb5i is like krb5, but additionally protects in-

tegrity of the data on each RPC request;

3. krb5p is like krb5i, but prevents any data expo-

sure by encrypting it.

We use the NFS client as implemented in the

Linux kernel. It requires a userspace process rpc.gssd

to be launched. By default, to mount NFS, the princi-

pal of the client machine is used. Since our approach

does not provide any means to get principals for ma-

chines, this behavior should be turned off using the

‘-n’ option of rpc.gssd process.

NFS internally uses numerical user and group

ids, but not principal names. If information about

ﬁles owner and group is important, some mechanism

should be set up on the client to map numerical ids

to the readable names and vice versa. This can be

done statically by using the generic idmap mecha-

nism. More convenient way is to set Linux up to

use LDAP for such mapping with the Name Service

Switch mechanism.

Since NFS has a lot of speciﬁcs, it may be incon-

venient to require a user to mount NFS shares man-

ually. To make NFS mounting easier for the user we

developed a shell-script. This script executes the fol-

lowing steps:

1. Checks if required software is installed;

2. Checks that rpc.gssd process is launched with ‘-n’

option;

3. Asks user for her authentication credentials at IdP;

4. Authenticates on IdP and uses the data from it to

5. Downloads Kerberos client-key from the SP in a

keytab format;

6. Uses Kerberos client-key to obtain TGT;

7. Mounts NFS share in the speciﬁed directory.

Steps 3-5 are optional if user already has its Ker-

beros client key. To avoid storing Kerberos client key

on physical storage, virtual ﬁle systems like tmpfs can

be used.

To access the share, each Linux user on the client

side must have a valid ticket. Usually, only superuser

can make a mount, so every other user should obtain

the ticket in order to use mounted share.

4.3 Other Tested Setups

The ApacheDS’s implementation of KDC is able to

serve only one Kerberos realm at a time. In the case

we have distinct set of users for each service, the other

implementation of the KDC may be used. We tested

our setup with MIT krb5 server. It stores all client

keys in the LDAP encrypted with master-key. To

be able to retrieve and decrypt keys the master-key

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

148

should be shared between KDC and web-service. Us-

ing distinct Kerberos servers makes deployment more

difﬁcult.

We successfully tried our approach also with SSH

and MongoDB (Enterprise server and a standard

client).

5 EVALUATION

In this section we evaluate our approach in terms of

deployability, usability, scalability and maintenance

efforts from the perspective of user, service provider

and identity federation.

The user does not need to deploy any non-standard

tool or do any speciﬁc conﬁguration on her machine.

The Kerberos service ticket management can be done

with standard kinit program and NFS operations can

be performed with standard NFS client tools. The

initial registration phase can be completed with the

use of a standard web browser and, optionally, the

command-line script described in previous section.

Thus, the deployability and the usability of the ap-

proach are enabled for the user. For the user of the or-

ganisation hosting the kerberised service, the registra-

tion step might be not necessary if the service admin-

istrator has imported user home organisation data into

LDAP-Facade beforehand. For the external user the

registration provides means to use the service with-

out undergoing potentially complex procedure of cre-

ation of a user account in the organisation, thus im-

proving the usability of the service. The use of the

command-line script also helps to diminish the main-

tenance efforts for the Kerberos client key manage-

ment and NFS speciﬁc conﬁguration for the user.

From the point of view of the service provider the

deployment of our approach does not require mod-

iﬁcation of the Kerberos server nor of the service.

Furthermore, if a service local identity management

system (e.g. local LDAP server containing local ac-

counts) exists beforehand, the migration to the LDAP-

Facade can be done seamlessly either migrating ex-

isting LDAP directory into LDAP-Facade or linking

it via LDAP proxying (Köhler et al., 2013). Using

LDAF-Facade instead of a plain LDAP server allows

the service provider to increase greatly the number of

the users of the service (the scale) by accepting them

from the whole federation instead of the local organi-

sation only. Depending on the policy of the service

provider, it can be conﬁgured to automatically ac-

cept new users joining the identity federation via their

home organisation IdPs. The scalability of the service

is enhanced by the registration interface which allows

to add user data to the LDAP-Facade directory easily.

From the perspective of the identity federation the

service provider integration can be done seamlessly,

without requiring adaptation of the existing compo-

nents of identity providers in the federation. The iden-

tity providers have to support WebSSO, ECP and As-

sertionQuery proﬁles of SAML standard. All three

proﬁles are supported by Shibboleth implementations

of the identity providers.

Though we have tested our approach with bwIDM

identity federation, it is not speciﬁc to it and can be

used with any SAML-based identity federation.

The implementation of our approach described in

this paper allowed us to provide NFS-based access

to LSDF facility to approximately 450,000 users of

bwIDM federation (Schlitter et al., 2014) in a deploy-

able, usable, scalable manner with minimal mainte-

nance efforts.

6 CONCLUSION AND FUTURE

WORK

In this paper we presented a general approach to inte-

grate web-based identity federations with non web-

based services that support Kerberos autentication

protocol. It does not require service or client mod-

iﬁcation or modiﬁcation of standard protocols. The

components that should be set up are: web-service,

KDC service and a common database. We evaluated

this approach, using existing bwIDM identity feder-

ation and modiﬁed LDAP-Facade software as an im-

plementation of aforementioned components. For our

case deployment efforts were minimal. As non-web

based kerberized services we have chosen NFS, SSH

and MongoDB.

In the future we plan to test our approach with

more kerberized services. We will also work on the

improvement of commandline user tools for the man-

agement of their Kerberos credentials.

REFERENCES

Adamson, W. and Williams, N. (2014). Nfsv4 multi-domain

fedfs requirements. Internet-Draft draft-adamson-

nfsv4-multi-domain-federated-fs-reqs-05, IETF Sec-

retariat.

Astrand, L. H. and Yu, T. (2012). Deprecate des, rc4-hmac-

exp, and other weak cryptographic algorithms in ker-

beros. RFC 6649, RFC Editor.

Dierks, T. and Rescorla, E. (2008). The transport layer secu-

rity (tls) protocol version 1.2. RFC 5246, RFC Editor.

Garcia, A., Bourov, S., Hammad, A., van Wezel, J., Neu-

mair, B., Streit, A., Hartmann, V., Jejkal, T., Neu-

berger, P., and Stotzka, R. (2011). The large scale

AnApproachforIntegratingKerberizednonWeb-basedServiceswithWeb-basedIdentityFederations

149

data facility: Data intensive computing for scientiﬁc

experiments. In Parallel and Distributed Processing

Workshops and Phd Forum (IPDPSW), 2011 IEEE In-

ternational Symposium on, pages 1467–1474.

Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P.,

Philpott, R., and Maler, E. (2005). Proﬁles for the

oasis security assertion markup language (saml) v2.0.

OASIS Standard.

Krawczyk, H., Bellare, M., and Canetti, R. (1997). Hmac:

Keyed-hashing for message authentication. RFC

2104, RFC Editor.

Köhler, J., Labitzke, S., Simon, M., Nussbaumer, M., and

Hartenstein, H. (2012). Facius: An easy-to-deploy

saml-based approach to federate non web-based ser-

vices. pages 557–564.

Köhler, J., Simon, M., Nussbaumer, M., and Hartenstein,

H. (2013). Federating hpc access via saml: Towards

a plug-and-play solution. Lecture Notes in Computer

Science (including subseries Lecture Notes in Artiﬁ-

cial Intelligence and Lecture Notes in Bioinformatics),

7905 LNCS:462–473.

Linn, J. (2000). Generic security service application pro-

gram interface version 2, update 1. RFC 2743, RFC

Editor.

Marín-López, R., Pereñíguez, F., López, G., and Pérez-

Méndez, A. (2011). Providing eap-based kerberos

pre-authentication and advanced authorization for net-

work federations. Computer Standards and Inter-

faces, 33(5):494–504.

Melnikov, A. and Zeilenga, K. (2006). Simple authentica-

tion and security layer (sasl). RFC 4422, RFC Editor.

Neuman, C., Yu, T., Hartman, S., and Raeburn, K. (2005).

The kerberos network authentication service (v5).

RFC 4120, RFC Editor.

Pérez-Méndez, A., Pereñíguez-García, F., Marín-López, R.,

and López-Millán, G. (2013). Out-of-band federated

authentication for kerberos based on pana. Computer

Communications, 36(14):1527–1538.

Pérez-Méndez, A., Pereñíguez-García, F., Marín-López, R.,

López-Millán, G., and Howlett, J. (2014). Identity

federations beyond the web: A survey. IEEE Com-

munications Surveys and Tutorials, 16(4):2125–2141.

Schlitter, N., Yasnogor, A., and Sprajc, C. (2014).

bwsync&share: A cloud solution for academia in the

state of baden-württemberg. In Kao, O. and Hild-

mann, T., editors, Cloudspeicher im Hochschulein-

satz : Proceedings der Tagung

Cloudspeicher im

Hochschuleinsatzäm 05. und 06. Mai 2014 am IT-

Service-Center (tubIT) der Technischen Universität

Berlin, volume 2014.

Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,

Beame, C., Eisler, M., and Noveck, D. (2003). Net-

work File System (NFS) version 4 Protocol. RFC

3530, RFC Editor.

Shepler, S., Eisler, M., and Noveck, D. (2010). Network

File System (NFS) Version 4 Minor Version 1 Proto-

col. RFC 5661, RFC Editor.

Smith, R. (2012). Application bridging for federated access

beyond web (abfab) use cases. Internet-Draft draft-

ietf-abfab-usecases-05, IETF Secretariat.

Wu, T. D. (1999). A real-world analysis of kerberos pass-

word security. In NDSS. The Internet Society.

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

150