Subject: SIP and GSS

From: Luke Howard <[email-masked]>
Date: Sun, 18 Jun 2006 10:43:31 +1000

Has anyone thought about a profile for doing GSS authentication in
SIP?

Presumably it could use a similar method to existing approaches
for HTTP authentication (although integrity protecting the header
is probably important, too).

-- Luke

--

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Sat, 17 Jun 2006 23:25:07 -0400

On Sun, 18 Jun 2006 10:43:31 +1000

> is probably important, too).

I don't know anything about SIP but I think it's worth pointing out that
I think there is a potential issue with trying to perform multi-step
authentication over stateless protocols like HTTP. Or at least there
is if you're pipelining requests. For this reason, I would recommend
considering having a multiplex id somewhere (e.g. a separate header with
a numeric value).

Mike

-- 
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/

---

From: Luke Howard <[email-masked]>
Date: Sun, 18 Jun 2006 13:36:55 +1000

>considering having a multiplex id somewhere (e.g. a separate header with

I'm not terribly familiar with the protocol either but I think you
could use the Call-ID for this. From RFC 3261:

   Call-ID contains a globally unique identifier for this call,
   generated by the combination of a random string and the softphone's
   host name or IP address.  The combination of the To tag, From tag,
   and Call-ID completely defines a peer-to-peer SIP relationship
   between Alice and Bob and is referred to as a dialog.

It appears that MS supports Kerberos authentication in SIP, see:

   http://www.mcse.ms/archive246-2006-1-2073250.html

The header is different to draft-jaganathan-kerberos-http-01.txt,
though -- it's unclear whether Negotiate would work.

-- Luke

--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Jun 2006 14:17:42 -0400

I was hoping to do something like http negotiate authentication for
sip after we get something reasonable with channel bindings for http

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Jun 2006 16:46:28 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> But you do realize that http negotiate requires HTTP/1.1
    Martin> Connection:keep-alive and does not provide data integrity,
    Martin> so the use of SSL/HTTPS to protect the communication
    Martin> channel is strongly advised.

Yes.  I do hope to fix the keep alive requirement and to look at
channel bindings for integrity.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jun 2006 23:04:52 +0200 (MET DST)

> channel bindings for integrity.

Microsoft NTLM and negotiate authentication impose TCP-session semantics
on the HTTP protocol carried within.  Every new TCP-session will be
forced through a new handshake with 401 Unauthorized replies until
the handshake completes, and every follup HTTP-Request does not
carry any HTTP headers refering to the initial authentication.

The authentication scheme is based on Microsoft's impersonation model,
where the server thread is expected to impersonate the client in order
to perform all the authorization decisions when processing the request
at the OS level.  The thread is supposed to work exclusively for
all of the pipelined HTTP/1.1 Connection: keep-alive requests.

The I-D proposal (which originally expired in 2002 and was reissued
in 2004 under a different name, but it has also expired), does account
for client-side proxies (client-aware proxies), but is totally ignorant
about server-side proxies (which are usually invisible to the client).

If you add code at the application layer to issue some kind of
session-credential (secure session id) in the reply to the browser
which the browser can and will resend with every new request,
then this would be a possibility to limit the negotiate authentication
requirement for HTTP/1.1 connection keep-alive to the initial handshake
-- which, in case of negotiate/Kerberos, makes it sort-of stateless again.
It requires just one round-trip for authentication and carries the initial
token (AP_REQ) together with the entirely unprotected HTTP request and
the final token (AP_REP) together with the equally unprotected HTTP
response in case the authentication succeeded.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jun 2006 16:07:19 -0500

> about server-side proxies (which are usually invisible to the client).

There's a new I-D coming that deals with both!

---

From: Leif Johansson <[email-masked]>
Date: Mon, 19 Jun 2006 23:07:44 +0200

> channel bindings for integrity.

The draft(s) Sam so cryptically is referring to are under way.

	Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jun 2006 23:19:05 +0200 (MET DST)

> The draft(s) Sam so cryptically is referring to are under way.

Well, the original drafts were informational and supposed to describe
the behaviour of an incredibly large installed base of Web clients
and Web servers.  While there is nothing wrong to come up with a
better proposal, we will likely have to live with many the originally
documented installations for quite some time.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jun 2006 16:23:01 -0500

> documented installations for quite some time.

This is true of anything we do in this space.  We can't let that
paralyze us.  As Sam says, the browser must change, and then not only
the browser.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jun 2006 22:40:47 +0200 (MET DST)

> sip after we get something reasonable with channel bindings for http

But you do realize that http negotiate requires
HTTP/1.1 Connection:keep-alive and does not provide data integrity,
so the use of SSL/HTTPS to protect the communication channel is
strongly advised.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Tue, 20 Jun 2006 08:27:21 +1000

Also it would be interesting to consider the interaction with key
exchange proposals for SRTP (eg draft-ietf-mmusic-sdescriptions-12.txt).

-- Luke

--

---

From: Leif Johansson <[email-masked]>
Date: Tue, 20 Jun 2006 07:01:51 +0200

> so the use of SSL/HTTPS to protect the communication channel is

Yup, however it is possible to add support for mutual authentication.

	MVH leifj