Shibboleth Developers

[Scott Cantor <>]

Forwarded on behalf of Klaus...

-----Original Message-----
From: Klaas Wierenga 
[mailto:]
 
Sent: Thursday, May 06, 2004 5:38 PM
To: Scott Cantor
Cc: 'David L. Wasley'; 'Bart Kerver'; 

Subject: Re: [Fwd: A Case for Shibboleth and PKI]

Scott Cantor wrote:

Scott,

(please forward my reply to the shib-dev list as I'm not allowed to post)

>>User-accounts are 
>>of the form 
>>,
>> user credentials of a visitor are 
>>proxied to the RADIUS-server of the home institution of that user via 
>>this hierarchy.
> 
> I'm not RADIUS literate, but am I mistaken, or does this imply that the
> user's password is potentially being given to the local RADIUS proxy and
> then forwarded (using TLS or whatever) to the actual home campus RADIUS
> server?

*Potentially* yes, but with the EAP-types I mentioned (TLS, TTLS and 
PEAP) the user's password is only visible to the home authentication 
server. With beforementioned types a secure tunnel is set up between the 
client and the home authentication server, no intermediary server can 
see the credentials.

> I think you have to factor in trade-offs, though. You get more security,
but
> I'm perhaps forced to give you my password. You're happy, but that doesn't
> mean I am. Of course, your solution is fine in a PKI world, but Earth
> doesn't qualify, yet anyway. ;-)

fair enough, security *always* is a trade-off. But in this case, you're 
only forced to give your password to your own institution. In a 
PKI-world things are easier, but indeed, such a world doesn't exist. You 
can compare *my* solution to the solution online banks use, first you 
set up a SSL tunnel to the bank website, then you enter you credentials 
in a login page. The SSL tunnel ensures that noone can eavesdrop, the 
actual authentication uses whatever means the bank feels like.

>>This is imnsho a rather clumsy approach. The only reasons I can think of 
>>  to do this would be that Shib is web-based and there are no other 
>>interfaces to it or that you want to use an authentication method that 
>>requires a direct web-connection to the authentication server (like in 
>>the Netherlands to the Internet banking page that we can use to 
>>authenticate users via their bank card)
>  
> Having a web connection isn't the essential aspect of the use case, having
a
> *direct* connection to my home authentication server instead of relaying
my
> credentials through the target is the use case.

Indeed, 802.1X provides for that.

> I don't want my password sent to your access point. If the network
precludes
> me from accessing my authentication service, then that seems to leave us
> with X.509 as a better form of user credential to give to the access
point,
> and David was essentially proposing some kind of means of using PKI even
if
> my campus won't issue me a long term certificate (and if I in particular
> don't want to manage one as an end-user, which I don't).

Your password is sent *through* the AP, not visible *to* the AP. X.509 
certificates (i.e. EAP-TLS) are a good way of doing 802.1X 
authentication whenever a PKI is in place.

> Secondarily, he's suggesting that SAML is a potential vehicle for
exchanging
> attributes about the user so that the access point can decide whether to
let
> me on the network.

Yes, I appreciate that. In fact that is one of the things we are 
thinking about too. My point is that I believe these SAML exchanges 
should take place accross some EAP connection.

>>3) Make existing RADIUS-servers talk to a Shib backend and use Shib to 
>>verify the user credentials. User credentials then first travel through 
>>the RADIUS-hierarchy towards the home RADIUS-server that verifies the 
>>credentials against its Shib backend.
> 
> Shib per se doesn't ever verify user credentials. Something else does and
> then Shibboleth issues a different, short term credential to deliver to
the
> application in lieu of the user's credentials.

Hmmm, agreed. But Shib relies on some kind of authentication mechanism 
for the user credentials and that provides some handle. I think this 
goes into too much detail, but with 802.1X one could in essence use 
whatever type of handle one feels like.

Hope this clarifies things.

Klaas