Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Mar 2003 14:42:20 -0500

A couple of notes about Digest and realms in SIP.

RFC3261 differs from RFC2617 in that it recommends hostname-based realm
names (well, RFC2617 does recommend this in some places, but
inconsistently). In other words, the name of a realm corresponds to a valid
hostname of the challenging UAS or proxy server.

The reason we did this is to make realm names unique. There could be realm
conflicts, where two proxies inadvertantly use the same realm name, that
could have confusing results for user agents. But also, if realm names are
arbitrary (like "foo"), then essentially any proxy server can challenge for
any realm. A malicious proxy that can anticipate the realm in which a UA
would like to authenticate can issue a challenge for that realm, essentially
posing as that proxy server; there are some possible credential-analysis
attacks that can arise from this. 

Tying the realm name to a hostname of the proxy server allows us to use
transport or network-layer authentication to ensure that the right proxy is
challenging with the right realm. When a UA connects to a proxy with TLS, it
can compare the subject of the certificate returned by TLS with the realm
name of a challenge. RFC3261 currently has language about this comparison
(see 26.3.2.1, for example).

This might initially seem to limit each proxy server to one realm, which
would be problematic, especially because some proxy servers have multiple
hostnames. However, this is a known problem for TLS in HTTP cases, and there
is a TLS-specific solution today. The TLS extensions draft defines a
'server_name' extension to the TLS HELLO message that allows the client to
say which hostname, of many possible virtual hosts at a single address, it
intends to connect to. Effectively, by choosing the hostname, in the SIP
case this would also choose the realm. See: 

http://www.ietf.org/internet-drafts/draft-ietf-tls-extensions-06.txt

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2003 12:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> [email-masked] writes:
> 
>  > Digest authenticates the username,
>  > not the From field - these may not be exactly the same.
> 
> i have never claimed that digest authenticates the from field, but in
> case of an initial request, the proxy can get the realm to be used in
> its challenge from the from field.  in subsequent requests this is not
> anymore possible.
> 
>  > This feature of blind challenges in digest has proven problematic
>  > before, and I agree that it would be nice if there was an EAP
>  > Identity request/response -type mechanism available in 
> Digest. But it
>  > isn't an easy add-on.
> 
> we don't need an eap style identity request/response.  what we need is
> an ability for the ua to tell in its requests to the proxy 
> the realm it
> claims to belong to so that the proxy can correctly challenge 
> it.  this
> can be easily fixed with a single new header or parameter.
> 
> -- juha
> 
> _______________________________________________
> Sipping mailing list  https://www1.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
> 
_______________________________________________
Sipping mailing list  https://www1.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: [email-masked]
Date: Tue, 4 Mar 2003 22:46:02 +0200

Peterson, Jon writes:

 > The TLS extensions draft defines a
 > case this would also choose the realm.

this seems to solve what i have been asking for, i.e., allowing the
client to tell to the proxy, which realm it belongs to.

the only problem is that today there exist very few UAs and proxies on
the market that implement TLS.

-- juha