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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 21 Jun 2006 14:28:05 +0100

(as WG chair)

This document is in AUTH48, i.e. it has been approved by the IESG, edited by the RFC editor, and had an RFC number assigned, and is just waiting the editor's to validate that this really is the document that the WG finished with, before it hits the published RFC directory.

While we can ask for the document to be withdrawn from publication, this is exceptional, and we will need to persuade the IESG that something really is wrong with the document. Please concentrate on identifying any such issues and the justification (VERY VERY QUICKLY).

The status of all documents can be discovered using https://datatracker.ietf.org/public/pidtracker.cgi

regards

Keith

> -----Original Message-----
> From: Fredrik Thulin [mailto:[email-masked]]
> Sent: 21 June 2006 11:30
> To: [email-masked]
> Subject: [Sip] Comments on draft-ietf-sip-identity-06
> 
> 
> 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
> 

_______________________________________________
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

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 21 Jun 2006 15:43:47 +0200

On Wednesday 21 June 2006 15:28, Drage, Keith (Keith) wrote:
> (as WG chair)
>
> This document is in AUTH48, i.e. it has been approved by the IESG,
> edited by the RFC editor, and had an RFC number assigned, and is just
> waiting the editor's to validate that this really is the document
> that the WG finished with, before it hits the published RFC
> directory.
>
> While we can ask for the document to be withdrawn from publication,
> this is exceptional, and we will need to persuade the IESG that
> something really is wrong with the document. Please concentrate on
> identifying any such issues and the justification (VERY VERY
> QUICKLY).
>
> The status of all documents can be discovered using
> https://datatracker.ietf.org/public/pidtracker.cgi

Hi

Yes, I realized the state of the document after I posted my previous 
message. I fully understand the problems with rising questions about a 
document in AUTH48, but hope that people view it as better that 
potential issues are raised in AUTH48 than not at all.

I would think the Call-Id issues are the most important ones. Most of 
the others are more opinions that I would not have posted if I had 
realized the state of the document. This question was apparently also 
raised by Brian Carpenter, or if it was Lakshminath Dondeti (from 
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=769&filename=draft-ietf-sip-identity
) :

>Normally a hash of the message is stored and compared against for 
>replay protection in addition to things like integrity protected 
>timestamps (Date).  Does the Call-ID provide the same capability 
>(uniqueness)?

I haven't been able to see this question addressed anywhere, but I might 
not know where to look.

Possibly, the text suggesting that only the first request (for a 
specific From:) over a TLS session needs to be Digest-authenticated, 
could also be of the dignity that it needs adressing - since it is 
"merely" a matter of removing a sentence.

I cannot judge whether these issues are serious enough to request 
withdrawal from the RFC-ed queue, others will have to give their view.

/Fredrik

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Jun 2006 10:26:40 -0500

> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=print_ballot&ballot_id=769&filename=draft-ietf-sip-identity
> ) :

Call-ID and typos like extra "s" can easily be fixed in Auth48.

More substantive changes can, if absolutely necessary, be made by  
explicit approval of the supervising AD, who may have to refer some  
questions to the larger IESG.

Restructuring your note to concisely focus on only those things that  
can reasonably be fixed in Auth 48 would probably be useful to the  
editior, who is currently performing the Auth48 editing task.

--
Dean

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 21 Jun 2006 21:04:06 +0200

On Wednesday 21 June 2006 17:26, Dean Willis wrote:
> > Yes, I realized the state of the document after I posted my
> > previous message. I fully understand the problems with rising
> > questions about a document in AUTH48, but hope that people view it
> > as better that potential issues are raised in AUTH48 than not at
> > all.
> >
> > I would think the Call-Id issues are the most important ones. Most
> > of the others are more opinions that I would not have posted if I
> > had realized the state of the document. This question was
> > apparently also raised by Brian Carpenter, or if it was Lakshminath
> > Dondeti (from https://datatracker.ietf.org/public/pidtracker.cgi?

I'm not sure I understand you here, did you read what I wrote about 
Call-ID issues? I think the issues would require far more changes than 
could be done during AUTH48.

> questions to the larger IESG.

After some thought, I personally think that if I haven't misunderstood 
something, the Call-ID related issues I brought up (and Lakshminath 
Dondeti brought up before me, although I didn't know about it) really 
do needs to be addressed. Call-IDs are potentially too predictable to 
be used for determining if a call should be rejected (because of a 
duplicate Call-ID) or not.

> editior, who is currently performing the Auth48 editing task.

Who is the AUTH48 editor? I'll do as you suggest and make a short list 
of proposed AUTH48 changes and send it to this list since I don't know 
who is the AUTH48 editor.

Thanks for both of your advice

/Fredrik