Subject: [Sip] Question regarding draft-dotson-sip-mutual-auth-03

From: "Nils Ohlmeier" <[email-masked]>
Date: Thu, 12 Mar 2009 19:50:02 +0100 (CET)

Hello,

after reading the mutual auth draft:

http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt

I have an open question:
what should the client do if the server send authentication informations
in a Proxy-Authentication-Info header back in a let say 200 response, but
when the client computes response it comes to a different result (e.g.
because man in the middle changed something in the messages)?

In chapter 5 of your draft you are simply referring to RFC3261 for more
details regarding the implementation of the UAC. But I failed to find any
information about the UAC handling of this header in 3261. Even RFC2617
gives no hints, at least I did not found any, what a client should do when
the server authentication fails.
So it is probably not your fault, but still an interesting question I
think. Especially because the client has already send its credentials when
the check of the server authentication fails.

Best regards
  Nils Ohlmeier

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 12 Mar 2009 14:24:38 -0600

Nils,

In the case you describe, the UAC cannot trust the response. So it can
take actions similar to when it does not receive a valid response: e.g.,
it can reasonably retry, log the error, and/or any other appropriate
behavior specified by the architecture. 

RFC3261 supports the Authentication-Info header (used in registration)
and not the Proxy-Authentication-Info header; which is why this I-D was
authored in the first place. The reference was to ensure that the
behavior is kept consistent, and available irrespective of registration
and non-registration messages. 

In any case, please refer to the following small thread (3 emails) for
the feedback I received during offline discussions at the last IETF:

http://www.ietf.org/mail-archive/web/sip/current/msg25882.html

- S

-----Original Message-----
From: Nils Ohlmeier [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 12:50 PM
To: [email-masked]
Cc: [email-masked]; Stuart Hoggan; Sumanth Channabasappa
Subject: Question regarding draft-dotson-sip-mutual-auth-03

Hello,

I have an open question:
what should the client do if the server send authentication informations
in a Proxy-Authentication-Info header back in a let say 200 response,
but
when the client computes response it comes to a different result (e.g.
because man in the middle changed something in the messages)?

In chapter 5 of your draft you are simply referring to RFC3261 for more
details regarding the implementation of the UAC. But I failed to find
any
information about the UAC handling of this header in 3261. Even RFC2617
gives no hints, at least I did not found any, what a client should do
when
the server authentication fails.
So it is probably not your fault, but still an interesting question I
think. Especially because the client has already send its credentials
when
the check of the server authentication fails.

Best regards
  Nils Ohlmeier

---

From: Victor Pascual Ávila <[email-masked]>
Date: Thu, 12 Mar 2009 23:21:06 +0100

On Thu, Mar 12, 2009 at 9:24 PM, Sumanth Channabasappa
<[email-masked]> wrote:
(snip)

>From [1]: "the UA trusts its connection with the next-hop and does not
need to authenticate any elements beyond the next-hop"

[1] http://www.ietf.org/mail-archive/web/sip/current/msg25890.html

Could you please develop this assumption?

Thanks,
-- 
Victor Pascual Ávila

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Fri, 13 Mar 2009 13:15:28 +0100 (CET)

> Could you please develop this assumption?

I also do not understand this sentense. It sounds like the IP connection
to the next hop is so trustworthy that we could use clear text passwords
instead of digest auth?!
But I think that such conditions would only be given when we use TLS or
IPSec, in which case digest mutual auth makes no real sense any more.

Regards
  Nils

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Fri, 13 Mar 2009 13:37:29 +0100 (CET)

Hi Sumanth,

> behavior specified by the architecture.

Ok, but the point is that in most of the cases it will be too late already.
Maybe an example is helpfull:
I try to register via proxy.hotel.com to my registrar at example.com.
Note: I'm using the open WLAN of hotel of cours. Now proxy.hotel.com
challenges my initial REGISTER request, which my UA replies to with the
password which I got at the receiption. Now this second REGISTER request
is forwarded to example.com and replied with a 200 OK.
When my UA receives the 200 OK it checks the Proxy-Authentication-Info
header and detects an error (maybe because a man-in-the-midlle modified
something). Upppss!
What should the UA do here? Display me a warning "It looks like you
successfully registered to example.com. Unfortunately something went
wrong. But your credentials where send already to example.com... Maybe now
someone else is registered with your account to example.com?!"

> and non-registration messages.

I understand that your draft is only adding the Proxy-Authentication-Info
header.
On the other hand I doubt that the whole mutual digest auth like it is
described in 2617 and 3261 is usuable for SIP at all.

>From that small thread I can only ask the same question as Victor did
already: what is meant by this trusted connection to the next hop?

And another issue in your draft in my opinion is what you describe in
second paragraph of section 10:
If someone is going to use mutual digest authentication it can not be
optional! As recent "demonstrations" on HTTPS and SMTP with TLS have shown
security "upgrades" of an IP connection are not optional. If you know that
your server (the hotel proxy in the example above) supports mutual auth,
you should configure your UA to require mutual auth. If the mutual auth is
not there or failed, something is really wrong in the network and you
should definately not proceed with whatever you wanted to do.

If you insist on the Proxy-Authorization-Info header being optional is
will be of no use at all. Because in all positiv working scenario it will
be present and working. But in all scenarios with broken, tapped or
whatever networks the header will be missing and your UA should send any
message with credentials in first place.

Best regards
  Nils Ohlmeier

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 13 Mar 2009 11:08:11 -0600

Nils,

Ok, but the point is that in most of the cases it will be too late
already.
wrong. But your credentials where send already to example.com... Maybe
now

[S] In the registration example you provide, the SIP UA will need to
verify the Authentication-Info header (per RFC 3261), which is specific
to the UA-to-registrar interactions.

However, the example can be easily generalized for UA-to-Proxy
interactions, where the Proxy-Authentication-Info header is used. When
the response (say 200 OK) cannot be authenticated, then the UA probably
cannot ascertain as to what happened; for example, the proxy could have
been an imposter who generated a phony response (i.e., it never reached
the intended proxy) or there was a M-i-M who modified a valid response
(i.e., it did reach the intended proxy). What the UA can ascertain is
that something is wrong! This is similar to the case where it does not
receive a response, i.e., the UA does not know if the other end did
receive it and the response was lost (in your registration example, the
device will be registered without the UA knowing about it), or the other
end did not ever receive it (and registration request never made it
through). 

By rejecting an unauthenticated response, the UA can potentially
minimize some of the threats (e.g., a hijack of the UA by a phony
proxy). Further, actions such as a retry may help. For example, if the
proxy sees a retry after it sent a response, then it can ascertain that
something went wrong (e.g., the packet was dropped) and clear up
associated resources. [Obvious caution: Too many retries can lead to
dictionary attacks.]

[Of course, if the MiM did not manipulate the parts of the response that
are authenticated by the Proxy-Authentication-Info header, then the
threat never surfaces. This is a drawback/limitation.]

I understand that your draft is only adding the
Proxy-Authentication-Info
header.
On the other hand I doubt that the whole mutual digest auth like it is
described in 2617 and 3261 is usuable for SIP at all.
[S] Well, digest is being used by quite a few implementations :)! And in
the presence of multiple proxies, digest is an option to authenticate
(or authorize) end-to-end. Thus, even when TLS is established with the
next-hop, it can be a useful tool. Is it a replacement for SIPS? Perhaps
not! But what are the other options? 

already: what is meant by this trusted connection to the next hop?
[S] The feedback I received (as I understood) was that once you
establish mutually-authenticated-TLS with the next-hop, you trust any
communication over that link (even to registrars and proxies outside of
the next-hop). This also meant that the Authentication-Info header (for
registration) is redundant (in RFC3261).

And another issue in your draft in my opinion is what you describe in
second paragraph of section 10:
If someone is going to use mutual digest authentication it can not be
optional! As recent "demonstrations" on HTTPS and SMTP with TLS have
shown
security "upgrades" of an IP connection are not optional. If you know
that
your server (the hotel proxy in the example above) supports mutual auth,
you should configure your UA to require mutual auth. If the mutual auth
is
not there or failed, something is really wrong in the network and you
should definately not proceed with whatever you wanted to do.
[S] The reason it is optional is primarily due to WG feedback that it
may not be required in all cases. For example, if you use SIPS or your
access network is always integrity-protected (e.g., Cable access with
DOCSIS BPI+). As Section 10 tries to say, use of this header is not a
replacement for TLS. It is only useful in architectures where digest is
used (with or without TLS) and you prefer mutual authentication to
minimize some threats. I say minimize since some threats still exist
(e.g., a transparent MiM who is an active or passive participant).

- S