Subject: [Sip] Comments on draft-ietf-sip-identity-06

From: Fredrik Thulin <[email-masked]>
Date: Wed, 21 Jun 2006 12:29:57 +0200

Hi

I've read the sip-identity draft, and have a number of 
comments/questions (in the order the text appear in the document) :

>4.  Overview of Operations
>...
>and thus can validates that the domain indicated

nit: should be "can validate"

>5.  Authentication Service Behavior
>...
>                                             Note that if that proxy
>    server is maintaining a TLS connection with the client over which
>    the client had previously authenticated itself using Digest
>    authentication, the identity value obtained from that previous
>    authentication step can be reused without an additional Digest
>    challenge.

How can the authentication service know for sure that a TLS connection 
was initiated by the client, and not an intermediate SIP ALG in front 
of a wifi hotspot for example (assuming that the client does not 
present a client certificate)? The SIP ALG might be hiding the inside 
topology so that there is only a single Via header present.

I realize that this is non-normative text, but I think it is bad advice 
security-wise unless it is said explicitly that it only applies if the 
client has a SSL client certificate.

>    If the authentication service is instantiated by a SIP user agent,
>    a user agent can be said to authenticate its user on the grounds
>    that the user can provision the user agent with the private key of
>    the domain, or preferably by providing a password that unlocks
>    said private key

I'm sure this is not what is intended, but this almost sound as if you 
think it is perfectly normal to make the private key available publicly 
as long as it is protected by a password. That might be true if the 
password is _stronger_ than the certificate, but passwords typically 
aren't. I propose that you remove the last part (", or 
preferably ...").

>   Finally, the authentication service MUST forward the message
>   normally.

I don't think you need RFC2119 language to describe that someone must do 
what they normally would.

>6.  Verifier Behavior
>...
>   Once the certificate is acquired, it MUST be
>   validated following the procedures in RFC3280 [9].  If the
>   certificate cannot be validated (it is self-signed and untrusted, or
>   signed by an untrusted or unknown certificate authority, expired, or
>   revoked), the verifier MUST send a 437 'Unsupported Certificate'
>   response.

I understand that your intentions are good, but I'm afraid that this 
part will make deployment on the open internet close to impossible 
until there is a global PKI root (will not happen), or the number of 
bridge CA's make close to 100% of all certificates verifiable.

For example, Swedish universitys can join the SwUPKI PKI, and those of 
us that have typically only use certificates issued by sub-CA's to 
SwUPKI. I won't be deploying sip-identity if it makes the chances of my 
users calls being accepted by any third party on the Internet fail, if 
the alternative is to NOT implement it, and have the calls succeed 
although without identity assertions.

Note that there are several reasons why small-scale PKIs are common,
most of them have nothing to do with economy. There is a trend towards
bridging PKIs which eventually will bring several local community PKIs
into a loosly connected network of trust but this is a gradual process
which will take several years and one which will never be entierly 
complete.

Since, as you say in the draft, a man-in-the-middle attacker can just 
strip the sip-dentity related headers from requests, I really think it 
is reasonable that the text above opens up for a identity validator 
that receives something signed by an unknown party _removes_ the 
identity related headers, and forwards the request as if there were no 
identity headers if local policy says that this is what should be done.

Text could be ", the verifier SHOULD send a 437 'Unsupported 
Certificate' response. The verifier MAY forward the request as if no 
Identity headers were present, if local policy permits, but in this 
case it MUST remove the Identity and Identity-Info headers from the 
request".

>9.  Header Syntax
>...
>the first letter of each week and month MUST be capitalized

nit: should be weekday I believe

>10.2.  Identity for a Request with no MIME body or Contact
>...
>   When the authentication service receives the BYE, it authenticates
>   Bob by sending a 407 response.

Can a BYE really be challenged? RFC3261 15.1.1 (UAC Behavior) says a UA 
can consider the session terminated as soon as the BYE is passed to 
it's transaction layer. In my experience, user agents aren't trying 
very hard to clean up network state for sessions they themselves 
consider terminated, although I agree they should. This issue was 
discussed for example in this thread on sip-implementors :

http://www1.ietf.org/mail-archive/web/sip/current/msg11118.html

I'm not sure what to do from the sip-identity perspective. My personal 
preference would be to push for making UAs actually handle challenges 
to BYE, but as Paul Kyzivat said in the message linked above, that 
ain't going to happen if the credentials have expired and the user has 
walked away from the terminal.

If some kind of change to the draft is made, then the update of Table 2 
of RFC 3261 in section 9 of the draft might also need updating.

>13.1.  Handling of digest-string Elements
>...
>  Implementations MUST also record Call-IDs received in
>  valid requests containing an Identity header, and MUST remember those
>  Call-IDs for at least the duration of a single Date interval (i.e.
>  commonly 3600 seconds).  Because a SIP-compliant UA never generates
>  the same Call-ID twice, verifiers can use the Call-ID to recognize
>  cut-and-paste attacks; the Call-ID serves as a nonce.

This seem problematic

1) This applies to _all_ the verifiers in a domain. If the verification 
is done by a domains SIP servers (not the callee's user agent) then 
they will have to use a distributed database or a single point of 
failure database to remember the Call-Ids seen by _any_ of the 
verifiers.

2) If the verification is done by the callee's end user agents, I 
beleive it would be possible for an attacker to capture a request (say 
a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and then send 
an identical MESSAGE with From: sip:bob@biloxi, To: sip:alice@atlanta 
but Request-URI sip:carol@atlanta.

I'm not sure there will ever be a value for any attacker in doing this, 
but it seems possible since Alice and Carol's user agents are very 
unlikely to share information about previously seen Call-Ids. Even if 
it seems to be a meaningless attack, it is still an attack, or have I 
missed something making this impossible?

3) This IS a problem if the Call-Ids generated by a UA is predictable, 
although unique. I beleive RFC3261 doesn't say that Call-Ids must not 
be predictable, even though it says they must be unique. For example, 
say that Alice has a UA that produces sequential Call-Ids with the IP 
address as 'what makes these unique'. Alice calls me, so I get her UAs 
current Call-Id. She tells me that she is going to call 
sip:[email-masked] right after our call. I want to prevent her 
from doing that. During our call, I send requests to example.org with 
the Call-Id's I predict Alices UA will use. Alices call to 
sip:[email-masked] will get rejected 

Also, what makes subsequent requests in the same dialog as the first one 
not get rejected? They will have the same Call-Id. 

>13.2.  Display Names and Identity
>...
>SIP accounts with arbitrarily display-names.

nit: I'm not a native english speaker, but I believe it should be 
"arbitrary".

>13.4.  Domain Names and Subordination
>...

su.se has about ~120 subdomains for different parts of the organization. 
Many of these run their own web servers and so on, some with SSL 
certificates for the domain name. It is not an appealing idea to have 
all these certificates on our SIP identity providing servers. There 
have been a couple of different proposals of how to create certificates 
for specific services of a domain. I think this draft should point at 
draft-ietf-pkix-srvsan as how this should be done, as this is the 
sollution I believe have gained most acceptance, but I might be 
wrong...

/Fredrik

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