Subject: [Ietf-krb-wg] Proxiable/forwardable question

From: "Lewis Adam-CAL022" <[email-masked]>
Date: Thu, 26 Jun 2008 11:05:42 -0400

Hi all,
 
I am considering Kerberos as a design solution for a communication
system, and have some questions with respect to its capability for
delegation.  As I currently understand the RFC and deployments thus far,
delegation is used when Alice logs onto Bob, and Bob needs to access a
resource on Carol using Alice's credentials.  My question centers around
integrity and confidentiality of messages.  Using Kerberos, it is
possible for Alice to log into Bob, and for Alice to delegate to Bob,
such that Bob can not only authenticate to Carole (on Alice's behalf),
but also have the authentication result in a shared session key between
Alice and Carole?
 
Thanks
Adam
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Jun 2008 13:27:18 -0400

> but also have the authentication result in a shared session key between

Bob can relay Kerberos traffic between Alice and Carol, such that Alice and 
Carol end up proving their identities to each other and sharing a session 
key no one else knows, even though they can't directly talk to each other. 
If you need a key that all three parties know, start by having two parties 
agree on a key, then have one of them tell the third(*).

Of course, once you have a key all three parties agree on, you have to 
think very carefully about how you're going to use it.  Most cryptographic 
communication protocols are designed to secure communication between 
exactly two parties, and don't automatically scale to cases where there are 
more than two parties, especially if all of them are talking.

(*) In the exchange you describe, there actually is a key that all three 
parties know -- the session key in the ticket which Alice has delegated to 
Bob.  Bob and Carol know this key as a result of the normal Kerberos AP-REQ 
exchange, and Alice knows it because she can look at what she sent to Bob. 
However, you really don't want to use this key for anything other than the 
AP-REQ exchange, because you won't necessarily get a new one every time 
Alice forwards a ticket to Bob, and that makes the analysis much harder.

-- Jeff

---

From: "Lewis Adam-CAL022" <[email-masked]>
Date: Thu, 26 Jun 2008 14:44:42 -0400

Hi Jeff,

> > delegation.  As I currently understand the RFC and deployments thus 
> > far, delegation is used when Alice logs onto Bob, and Bob needs to 
> > access a resource on Carol using Alice's credentials.  My question 
> > centers around integrity and confidentiality of messages.  Using 
> > Kerberos, it is possible for Alice to log into Bob, and for 
> Alice to 
> > delegate to Bob, such that Bob can not only authenticate to 
> Carole (on 
> > Alice's behalf), but also have the authentication result in 
> a shared 
> > session key between Alice and Carole?
> 
> Bob can relay Kerberos traffic between Alice and Carol, such 
> that Alice and Carol end up proving their identities to each 
> other and sharing a session key no one else knows, even 
> though they can't directly talk to each other. 
> If you need a key that all three parties know, start by 
> having two parties agree on a key, then have one of them tell 
> the third(*).
> 

I'm looking at the first option, in fact I would prefer that Bob does
not know the session key between Alice and Carol.  Once the session keys
have been established, bearer traffic will flow directly between Alice
and Carol, by-passing Bob.  Pseudo-logic is something like this:

1) Alice authenticates to Bob
2) Bob authenticates Alice to Carol
3) Alice and Carol get shared secret to authenticate traffic between
them, bypassing Bob

Steps 1 and 2 are straight forward, but what part of the RFC describes
how step 3 is enabled?  
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Jun 2008 15:11:03 -0400

> 2) Bob authenticates Alice to Carol

Bob doesn't authenticate Alice to Carol, at least not if you're using 
Kerberos.  Credential delegation would mean that Bob could authenticate to 
Carol _as Alice_.  Carol won't be able to tell the difference between Bob 
and the real Alice.

You can certainly build an application in which Bob gives a key to Carol 
and says "the other person with this key is Alice", and Carol somehow 
believes Bob.  But that wouldn't be Kerberos.

> Steps 1 and 2 are straight forward, but what part of the RFC describes

Basically, what you want to do is have Alice and Carol conduct an 
AP-REQ/AP-REP exchange, in which Alice authenticates to Carol, after which 
they have a shared secret.  If Alice and Carol cannot directly communicate, 
then Bob can serve as an intermediary, relaying messages between Alice and 
Carol but not being able to interpret them.

It might help a lot if you give up on the hypothetical and tell us what 
you're really trying to do.  There's a good chance that there is a solution 
based on existing technology, but it's hard to tell without knowing more 
about what's going on.

-- Jeff