Subject: How to put a Kerberos ticket in SIP messages?

From: Bryan Byerly <[email-masked]>
Date: Thu, 09 Mar 2000 11:04:04 -0500

Hi guys,

I'm trying to understand how best to place a Kerberos (v5) ticket in
SIP messages (i.e. either in SIP request or SIP response).
(If someone already has such as draft, please forward me a copy.)

I can think of two possible approaches:
1) Put it in a SIP header:
2) Put it in the SDP
other ideas?

1) Thoughts on putting it in a header
So, a Kerberos ticket is ASN.1 DER encoded.  Is there any reason we
couldn't just stick the binary representation of the ASN.1 DER encoded
object in a header?
Something like:
ticket=fj7d543ghklc8654f7...
(Yes, you're right, that's not a real ticket).

So, I'm leaning towards a more generic header name like:
Service-Authorization=[service name], [authorization-type],
encoding=[encoding-type], ticket={octet string}
authorization-type=kerberos5
encoding=octet-string

b) Thoughts on putting it in the SDP

Since a Kerberos ticket is ASN.1 DER encoded, it occurs to me that we'd
need a email-safe version of the Kerberos ticket if we were to place it
in the SDP.

Can anyone point me to an existing draft/rfc which converts a Kerberos
key to an email-safe version.  I guess a draft on converting an
arbitrary octet-string to an email-safe version would be fine too.

P.S.
For fun, who has a suggestion for which SDP abbreviation should be used
for a Kerberos ticket?  (It appears all the obvious ones are taken).
taken: a, b, c, e, i, k, m, o, p, r, s, t, u, v, z
remaining: f, g, h, j, l, n, q, w, x, y     (Please correct me if some
of these is already taken).

Thanks for your help!

Bryan

Bryan J. Byerly
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 09 Mar 2000 11:22:20 -0500

Another option is just a SIP MIME bodypart. No binary-to-text
translation needed there. Would be nice to spec this topic out.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Bryan Byerly <[email-masked]>
Date: Thu, 09 Mar 2000 11:34:53 -0500

So I expect a few people to come back and ask why not reuse an existing
header.

I'm trying to achieve a flow where a SIP proxy hands back a Kerberos
ticket to a client.  The client, in turn can use this ticket for
authorization to receive a service.  (Yes, alternatively the client could
go get his own ticket (if he knew the IP address of the KDC and was an
authorized Kerberos client), and this follows along with moving complexity
out to the endpoints.  However, I'm trying to initially simplify things
for dumber, less complex SIP clients.  (and yes, I agree that SIP clients
could eventually go get their own tickets)).

Let's go through the list of existing headers and why we can't use them:

401 WWW-Authenticate: header and Authorization: header
Using 401's WWW-Authenticate: header and the Authorization: header are
used for end-to-end authorization.  So, using WWW-Authenticate is not
appropriate for passing back a Kerberos ticket.

407's Proxy-Authenticate: header and Proxy-Authorization: header
Using 407's Proxy-Authenticate: header and the Proxy-Authorization: header
are used to authorize a SIP client to transit through a SIP proxy.
Proxy-Authorization: is specified by a SIP client to provide credentials
such that he will be authorized by the SIP proxy.  So, I don't think its
appropriate to overload Proxy-Authorization: to mean "here's an
authorization that the SIP proxy is passing to the SIP client".

Response-Key:
This header is used by a client to specify a key which it requests the
called user agent should use to encrypt a response.  So, its not
appropriate to use this header to pass a ticket.

Thanks again for your help and suggestions!

Bryan

Bryan J. Byerly
[email-masked]

---

From: Stephen Thomas <[email-masked]>
Date: Thu, 09 Mar 2000 21:02:04 -0500

Indeed, see draft-thomas-mime-osp-token-00.txt

>translation needed there. Would be nice to spec this topic out.

____________________________________________________________________
Stephen Thomas                                       +1 404 872 4887
TransNexus, Chief Technical Officer    [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2000 02:53:31 -0500

Before jumping into the syntax issues, I'd like to understand exactly
whats going on here. Integration of Kerberos with SIP is a fairly big
topic. There has been some discussion of this for establishing security
associations between clients and local proxies as an alternative to IKE.
You are proposing a different use yet, where it seems a redirect server
is acting as a KDC, handing out tickets in SIP redirects. Lots of issues
here, syntax is the least interesting one, IMHO. How is the client
authenticating itself to the redirect/KDC in the first place? Does a
client cache tickets and try to use them later when connecting to a
server it was redirected to previously? What if the server thats
redirected to, with a ticket, is yet another redirect server? 

I'm not saying I don't like this idea (in fact, I think its a very
interesting one indeed), but I'd rather discuss higher level issues
first. Actually, I'd love to see an I-D first to give a context for the
discussion.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Mar 2000 17:06:07 -0800 (PST)

Jonathan,

There are, in fact, two things going on here.

1) There is a need to secure the base level signaling
   hop by hop. Using Kerberized IPSec with the principle
   name being the FQDN of the box (eg [email-masked])
   is probably the right answer for high fanout networks.
   This would handle the cases where there is a one to
   one relationship between the users of the box and
   the box itself. It also handles the base level 
   requirement for autheticity and privacy of the 
   SIP traffic.

2) When multiple users can simultaneously use the
   same box (eg, [email-masked]), we ALSO need a means of 
   verifying the credentials of the individual
   user in addition to the credentials of the box
   itself. There are many possible answers here, 
   running from HTTP basic authentication to 
   public key signatures, but if you already need
   a kerberos client for other reasons (see #1
   above), it would almost certainly be a win to
   transport a kerberos ticket for the
   Proxy-Authenticate. The nice thing here is that
   we can use either public key cryptography (I 
   think of this in terms of a smart card I'd put
   into a public SIP phone), or "normal" symmetric
   key Kerberos depending on the application.

   The main attraction of public key Kerberos is 
   that it captures the result of the public key
   operation in the ticket which can later be
   verified using just symmetric key operations
   (which are orders of magnitude faster). This 
   is equally important in both cases 1 and 2
   for large scale deployment.

A few inline comments:

Jonathan Rosenberg writes:
 > How is the client
 > authenticating itself to the redirect/KDC in the first place?

It can either be done using public keys and
certificates (PKINIT) or the normal method of
username/passwords.

 > Does a
 > server it was redirected to previously? 

Yes.

 > What if the server thats
 
If you use ticket granting tickets, you just get
and maintain a ticket for each server you need to
create an SA with. You rightly point out above
that the tickets form a cache; nothing bad happens
if you have to throw one away (other than needing
to go back to the KDC on a cache miss).

      Mike

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Mon, 13 Mar 2000 21:03:03 -0800 (GMT-0800)

>    it would almost certainly be a win to

This is indeed a good idea because other methods
of supporting smartcard auth require that the
smartcard be used on *every* connection. This
is not only onerous for the user, but creates
huge load on the authentication server. With
Kerberos, you pull out the smartcard once and
can continue to reuse the ticket after that
until it expires. Of course, don't forget to
include an authenticator in each request for
replay immunity!

An added benefit of PKINIT is that it can be
used for roaming between providers if necessary. 

I'd  add that similar issues come up in
"Presence" applications so that kerberization
is an obvious win there as well. 

BTW, what is "Kerberized IPSEC?" Is this IKE
MM w/GSS_API authentication?

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Mar 2000 08:14:06 -0800 (PST)

> include an authenticator in each request for

   I don't think you need to include an
   authenticator so long as the base level
   transport is replay protected. This would
   be the case if you're using IPsec. As far
   as I can tell, you only need to challenge
   the particular user once ala http.

 > MM w/GSS_API authentication?

   No. Kerberized IPSec is something that got
   created at packetcable and doesn't use IKE at
   all. A normal kerberos ap_req/ap_rep are done
   to a well known port with a SPI and the
   ciphersuite information appended. There are
   no public key operations needed to key the
   the SA on the server.

	  Mike