Subject: [Sipping] draft-ietf-sipping-update-pai-05 - response authentication

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Aug 2008 11:18:44 +0100

During discussion of 04 in Dublin, concerns were raised about the
conditions in which it is possible to assert identity in a response. The
present text says:

"        <t>The proxy behaviour specified in RFC 3325 is applicable to
responses with the following qualifications. A proxy that receives a
response from a node outside the Trust Domain cannot directly
authenticate the UAS by SIP means. Therefore it MUST NOT include a
P-Asserted-Identity header field when forwarding the response unless it
has authenticated the UAS by other means.</t>
        <t><list>
          <t>One possible circumstance in which a proxy can include a
P-Asserted-Identity header field when forwarding a response from a node
outside the Trust Domain is when the proxy has direct TLS connectivity
with the UAS and has authenticated the UA by some other means (e.g., SIP
digest authentication) during that same TLS session.</t>
        </list></t>"

A concern raised was as follows. How does the proxy know that it has
**direct** TLS connectivity with the UAS, as opposed to going through
some intermediary (e.g., an edge proxy)? If there is an intermediary,
the response may not have come from the UA that was earlier
authenticated, since the intermediary may have sent a response from a
different UAS over the same TLS connection (or even responded itself
over the same TLS connection). Unless the intermediary is also a trusted
node (in which case the provisions of the paragraphs above do not
apply), it is important for the proxy to know that there is no
intermediary, i.e., that the TLS connection is with the UA. Although
there are signalling mechanisms possible to achieve this, they are not
standardised. Therefore a proxy can only rely on prior knowledge (e.g.,
configuration) to know whether to assert an identity in such
circumstances.

Do people consider this to be a sound basis for accepting asserted
identity in responses from untrusted nodes? Is it realistic to assume
that there will be situations where it would be safe to configure a
proxy to assert an identity when a response is received over a TLS
connection over which digest authentication has already taken place? The
existing wording in the draft would then be basically correct, but might
benefit from some additional explanation, particularly in the Security
Considerations section.

John

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Aug 2008 18:05:15 -0400

I don't understand why this issue is unique to responses. You have the 
same problem with requests. If a proxy authenticates a client over TLS, 
and then later on does not re-authenticate each request, it is possible 
that subsequent request might actually come from clients further upstream.

Since we have not viewed this as a problem for requests I don't see why 
we should consider it for responses.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2008 18:37:21 -0400

> we should consider it for responses.

Or, maybe it really *is* a problem for requests as well!

I always viewed the workable use of this in requests to be for the first 
trusted node to authenticate, perhaps using digest, and then to insert a 
PAI. The IMS folk always asserted that they had some magic way to verify 
that the sender of a message was the same one that earlier sent a 
REGISTER that had been authenticated. If they in fact do not have a way 
to do that, then they have no business inserting a PAI assuming they do.

I agree the response side is only different to the extent that the magic 
mechanisms differ.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Aug 2008 07:31:20 +0100

Paul, Jonathan,

Yes, I failed to mention that this is a problem impacting requests too,
but with the big difference that each request can be digest
authenticated. I agree with Paul, that unless you have some way of tying
together the client of a TLS connection with the client of an earlier
digest authentication over that same TLS connection, then you have no
business asserting identity. I am sure practice differs from this! Can
one of the IMS experts explain how this is achieved?

So the question (to the whole group, and particularly to Cullen and Jon)
is, should we add some words (for both requests and responses) that
explains that in order to assert an identity based on an earlier digest
authentication over the same TLS connection, you must have some means of
tying together the two clients? Would this be sufficient? Or is it
necessary to give at least one example of how this might be achieved
(and AFAIK, there are no standardised examples).

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 18 August 2008 23:37
> To: Jonathan Rosenberg
> Cc: Elwell, John; SIPPING LIST
> Subject: Re: [Sipping] draft-ietf-sipping-update-pai-05 - 
> responseauthentication
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Aug 2008 08:00:47 -0600

For several years we have discussed that it would be nice to have a  
way to tie the previous authentication of a UA to a security channel  
and use that binding for response authentication. Outbound + TLS  
seemed like one way to do this. The plan was to get basic outbound  
done before starting this type of work. It will be a major piece of  
SIP security work to get this done. It will need it's own draft and it  
probably needs to happen in the SIP WG.

Cullen

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Aug 2008 07:25:22 +0100

Cullen,

Perhaps I don't recall all of the earlier discussions, but I don't see
where Outbound comes in. Can you give me an idea of what might be
involved? Or was it simply that, without Outbound, TLS is not deployable
in many situations on the first/last hop?

One mechanism I could see working would be for digest authentication to
be applied to responses based on a nonce given in the request or in an
earlier message. Another mechanism would be to bind a digest signature
to a TLS client, by including a fingerprint of the certificate in the
digest signed information. The latter mechanism would also be useful for
requests. I agree such enhancements to digest would need to be done as a
separate task (in the SIP WG). Is this the sort of thing you had in
mind?

Having done something of this nature, then the proxy could use digest
authentication to support a PAI or Identity assertion.

The question is, do we need to hold up the update-PAI draft waiting for
such work, or can we proceed with suitable warnings about needing to
have authenticated the UAS and the pitfalls involved?

John

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 19 August 2008 15:01
> To: Elwell, John
> Cc: Paul Kyzivat; Jonathan Rosenberg; Peterson, Jon; SIPPING LIST
> > So the question (to the whole group, and particularly to 
> Cullen and  
> > Jon)
> >>>> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping