Subject: Re: Signing RPIDS (Was: Re: [Sipping] calling number blocking at sip/isup gateway)]

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Feb 2002 14:03:50 -0600

Warning, indentations may be bogus, message forwarded too many times.

> > On Monday 28 January 2002 03:21 pm, Flemming Andreasen wrote:
> > > In an almost two year old version of the draft, we had the ability
to
> > > sign the Remote-Party-ID (rather than just having the "screen"
> > > parameter), however,  it was subsequently pointed out that it was
> > > subject to cut-and-past attacks as you mention, and that it really
> > > was part of a much larger SIP security problem that should be solved
> > > instead.
> Dean Wrote:
> > The problem is that the ability to use the RPID as an "introduced by"
> > token is contingent on being able to sign it,
>
> That is your contention. While I agree it is a way of solving the
> problem
> in general, it is also a complicated solution that may be overkill for
> several commercially viable architectures. I assume you are talking
> public-key cryptography here which means that we not only incur a
> computational overhead, but we also have to solve the key
> distribution problem and decide upon a proper signature scheme.

It's an either-or question of "trust the network" or "do the crypto". One
simply can't trust the network all the time, which leaves the option of "do
the crypto". The cert management modem in browser TLS is directly
applicable. Every browser is shipped with a bunch of root certs. Every
operator has a cert signed by a root cert. So your "network authenticated"
ID can simply be signed with the operator cert, which answers the questions
of "who vouches for this RPID".
> > as well as context
> > associate it with the session being introduced. Hashing in To, From,
> > and Call-ID headers provides context (which I believe was covered in
> > the two-year-old draft).
>
> I don't believe we ever settled on which headers should be covered by
> the
> signature. The important observation we did make however was, that the
> issue of authenticating parts of a SIP message was a general problem and
> should be solved as such. We should not have individual headers come up
> with their own authentication schemes, etc, but rather take the usual
 > route
> of solving the more general problem. I'm still of that opinion.

I believe there's another draft in circulation that talks about which
headers need to be protected by digest authentication. That should suffice
for RPID vouching as well.

> > The traditional mechanism for bounding replays
> > is to apply temporal information.
> > I believe Michael objected to temmporizing the signing in that earlier
> > draft because of the deifficulty of clock synchronization and of
> > describing durations.
> >
> > >
> I think it was more than that, but I'll let Mike speak to that.
> >

> > However, I think that it might be worth considering what COULD be
> > gained from a time-stamped RPID signature. While one might not wish to
> > use the resultant programatically as a final authenticator, the
> > information might still be useful in making a HUMAN-scale
> > interpretation of the RPID.
> > >
 >
> You are planning on defining a full-fledged signature scheme in
> order to make the authentication information trustworthy, yet you
> recognize
> the practical problems and thus don't really want to rely on it anyway ?
>

I recognize the practical difficulties of implementing a signature
mechanism. I believe it's solvable. However, I don't believe it's an
adequate replacement for all subscriber authentication questions, primarily
for reasons of backward compatibility and subscriber certificate management.
Same reason that HTTP has challenge-response as well as TLS. You CAN use
your browser with a user cert, but you are not required to do so.

--
> Dean
> --
> Flemming Andreasen
> Cisco Systems

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Fri, 08 Feb 2002 12:28:38 -0500

Dean Willis wrote:

> the crypto".

If we want to have a completely general solution, then I agree. However do note,
that this is not the architecture currently assumed and described in the privacy
draft (Section 3).

> The cert management modem in browser TLS is directly

It's not enough to have the root certificates. You still need to obtain the
operator certificate in order to verify such a signature, not to mention making
sure the certificate has not been revoked. Also, as has been noted before,
public-key based signatures carry a non-negligible computational overhead which
you need to take into consideration here (consider the effect of having all
messages going through the proxy)

<snip>

> for RPID vouching as well.

Which draft are you referring to here ?

> mechanism. I believe it's solvable.

OK - I'd like to hear more about the replay protection solution at least.

> However, I don't believe it's an

Fair enough. Which methods do you propose we should have ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 10 Feb 2002 02:11:57 -0600

> Which draft are you referring to here ?

I think I'm thinking of the the pnonce spin-off work that James Undery is
supposed to be editing, but I seem to recall seeing another document
recently that was just discussing which headers need to be protected. IETF
draft searching is down right now, but if it comes back to me I'll let you
know.

> OK - I'd like to hear more about the replay protection solution at least.

Well, if one is willing to accept roughly synchronized clocks (look, for
example, at the nanosecond-level synchronization required for CDMA), then
one can easily reduce the replay window to human-acceptable time scales,
like 30 seconds or so. One might consider fast perfect replay to be a
security flaw, but I've seen enough networks where it happens spontaneously
to realize it isn't much of a problem.

> Fair enough. Which methods do you propose we should have ?

Well, clearly digest has a lot of installed base. 3GPP is leaning towards an
EAP-derived system that can reuse the key management of AKA. The AKA
mechanism is interesting, because they use sequences of one-time keys
generated by a smart-card, which would appear to reduce the probability of
replay attack. Assume that we can cobine the AKA key management with ppnonce
approaches, and it could be interesting -- any message that was being
replayed could only be replayed with the AKA session-key lifetime.

--
Dean

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Feb 2002 21:36:40 -0500

> to realize it isn't much of a problem.

Trouble is, that if you really want to be general, then you cannot assume
synchronized clocks (how many PC's do you think it would with). While I agree
that controlled operator environments can probably get away with such a
requirement, what do you propose for the rest ?

> Well, clearly digest has a lot of installed base.

OK, but how is that going to help you determine the authenticity of a
Remote-Party-ID ? It seems more like you would simply use it to determine the
identity in the first place.

> 3GPP is leaning towards an

I'm not familiar with either of this, but are you proposing that they should be
part of the privacy draft ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Feb 2002 02:20:57 -0600

Well, if 80% of the SIP clients are CDMA or W-CDMA (which by definitition
have synched clocks) that solves a large part of the problem.

Of the otehr 20%, the 80% that know they have bad clocks could just ignore
the signing on RPIDS.

Look, we're talking primarily about a PROXY MODERATED signature. If you're
willing to presume IPSEC and magic key management and all sorts of other
stuff on proxies, chances are the clock is synched up too . . . but at least
this approach lets MY operator proxy evaluate the signing by YOUR operator's
proxy.

I don't understand the emphasis on the crippled RPID mechanism of the
privacy draft. Is there some sort of patent somebody is trying to submarine
into the works?

--
Dean

----- Original Message -----
From: "Flemming Andreasen" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 11, 2002 8:36 PM
Subject: Re: Signing RPIDS (Was: Re: [Sipping] calling number blocking at
sip/isup gateway)]

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Feb 2002 09:58:34 -0500

> Of the otehr 20%, the 80% that know they have bad clocks could just ignore

Is this the SIP/SIPPING WG chair talking ? Are you seriously suggesting that a
secure solution should only be applicable to some subset of the SIP clients ? I
thought the whole idea with this discussion was to come up with a general
solution.

> this approach lets MY operator proxy evaluate the signing by YOUR operator's

Well, this is different from what we have been talking about so far. We are
concerned about user agents determining whether a given Remote-Party-ID is
authentic or not, not proxies.

> privacy draft. Is there some sort of patent somebody is trying to submarine

Cheap and uncalled for Dean. The premise of the privacy-03 draft is a simple
transitive trust model.  Yourself and others desire a more general model and
hence solution, which I have no problem with, *as long* as it then is a general
model that is also usable in practice. You have suggested that we need to sign
Remote-Party-Id's in this more general model, and a number of questions have
then come up, several of which have yet to find a satisfactory answer. I'll
reiterate the questions below:

1.    Is signing of Remote-Party-ID a specific case of a more general problem of
authenticating headers, and hence should be solved in a generic way (outside of
the privacy draft) ?

2.     Is it reasonable to require synchronized clocks between all SIP entities
in order for signing of Remote-Party-Ids to be secure ?

3.    Are people concerned about the computational overhead by always having to
sign a Remote-Party-Id in a message (issue when record-routing for example) ?

4.    If Remote-Party-Ids are signed (one way or the other), should they be
protected against:
    a)    cut-and-paste attacks ?
    b)    replay attacks ?
If not, i.e., it's not really secure after all, what are we gaining by having a
signature scheme ?

5.    If RPIDs can be signed by more than a small number of well-known parties
(which I believe to be the case), how do you verify the signature ?
    a)    In particular, how do you obtain the signer's certificate ?
    b)    How do you handle revoked certificates ?

I would appreciate input from more people on these - especially the security
folks and of course 3GPP as well.

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Feb 2002 15:38:47 -0600

----- Original Message -----
From: "Flemming Andreasen" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "Sipping (E-mail)" <[email-masked]>
Sent: Wednesday, February 13, 2002 8:58 AM
Subject: Re: Signing RPIDS (Was: Re: [Sipping] calling number blocking at
sip/isup gateway)]

> thought the whole idea with this discussion was to come up with a general

What we're talking about here is providing additional information to help
the human participants in a dialog evaluate the preseumed identity of the
other participants. This is why I have clearly said that I don't believe
RPID replaces any of the authentication techniques. It's a hint.

The Privacy draft proposal for RPID provides a very weak indicator of
trustworthinesss , basically on the order of "Some proxy somwhere in the
network believed this RPID to be valid". All we're proposing doing is adding
more indicators: 1) Which proxy(ies) or operator(s) belived this to be true,
2) When they believed it to be true, 3) For what other combinaion of call
distinguishers (to, from, call-ID, etc) did they believe it to be true. The
only "security weakness" you've suggested with the "signed RPID" approach is
that we can't evaluate the reliability of the "when" unless we have a
reasonable idea of what time it is. That's reducible to the simple reflexive
"If we don't know what time it is, we don't know what time it is."

So, even if my client has only a foggy notion of time, I still have a lot
more to go on with a signed RPID than with a non-signed RPID. We're worried
about replay detection, right.  It might be very reasonable for me to look
at an incoming INVITE and say "Well, this claims to be from Flemming, and we
had a talk about this same subject an hour ago, which oddly enough used a
call ID that looked very similar. And look here, the RPID was signed about
an hour ago by Cisco's proxy, and my proxy checked that signature and found
it to be valid. But INVITES usually don't hang around the network that long
before getting to me.  I bet this is spam with a stale RPID attached."

That's about as much of an identity hint as we're going to be able to
produce without a global PKI.

. . .

> authenticating headers, and hence should be solved in a generic way
(outside of

Possible -- if there were a general way of authentiating headers, it could
be re-used here. But the manner in which the authenticity of RPID is
evaluated by humans is probably unique.

> in order for signing of Remote-Party-Ids to be secure ?

The humans operating SIP entities with loosely synchronized clocks need to
be aware of this and probably won't find the RPID as useful as it might be
for people with good clocks.

> sign a Remote-Party-Id in a message (issue when record-routing for
example) ?

Then don't sign it. But people may be less willing to trust it if it isn't
signed.

> If not, i.e., it's not really secure after all, what are we gaining by
having a

better hinting to the user than we have now. It's an improvement, not an
absolute.

>     b)    How do you handle revoked certificates ?

I'd suggest that the certificate model used for web browsing should be
directly applicable. There are more than small number of TLS web servers out
there, and it seems to work OK.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Feb 2002 16:40:04 -0600

----- Original Message -----
From: "Flemming Andreasen" <[email-masked]>
To: "Dean Willis" <[email-masked]>
. . .
> Cheap and uncalled for Dean.

I apologize for being paranoid. But just because I'm paranoid, it doesn't
mean people aren't out to get me, or haven't done so already . . . To my
knowledge, you personally have been forthright and helpful in all matters of
intellectual property, and I apologize for any implication that you might be
otherwise. However, that desirable state is by no means universal, and it is
possible that any of us might be getting influenced by other parties who
have non-technical interests of this sort. Almost everybody has a marketing
department, or IPR office, or friend who's filed a patent application
looking over their shoulder.

--
Dean

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Feb 2002 18:03:06 -0500

Dean Willis wrote:

> otherwise.

No problem.

-- Flemming

> However, that desirable state is by no means universal, and it is

--
Flemming Andreasen
Cisco Systems