Subject: RE: CPLng (was [IPTEL] agenda items)

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Nov 2000 23:41:54 -0500

Michael,

This is a good point. What you are asking for is non-repudiation of script
uploads. Unfortunately, I think its harder to do than you imply. Even if I
have a signed script from you, you could argue that you did indeed sign the
script, but never uploaded it. To prove that you uploaded it, I would have
to remember the message exchanges for the transport itself. I don't think
there is a way around that.

Like many other groups that work on security, we have begun discussing
technology solutions without identifying the requirements. Mike has proposed
one requirement, which is non-repudiation of script uploads. What other
security requirements do we have? Once we know those, we can identify
whether the existing security mechanisms are sufficient.

-Jonathan R.

> -----Original Message-----
> From: hammer michael [mailto:[email-masked]]
> Sent: Monday, November 27, 2000 1:02 PM
> To: Jiri Kuthan
> Cc: James Undery; Jonathan Rosenberg; [email-masked]'
> Subject: Re: CPLng (was [IPTEL] agenda items)
> 
> 
> Suppose, I establish a secure session and securely transmit a 
> script which 
> then gets loaded.  Later, it turns out the script is 
> destructive.  You 
> accuse me of doing some damage.  I deny that the rogue script you are 
> complaining about is mine.  The session is long gone.  You 
> have no proof 
> that the script is mine and any legal claims would be rather tenuous, 
> unless you saved a recording of the session, which would 
> waste memory.  If 
> the script had been signed, then you would have a case against me.
> 
> Transport level assurance is only good if you can absolutely 
> trust the 
> sender.  I am not suggesting that you not use transport layer 
> security, 
> only that some additional level of security might be called for.
> 
> Mike Hammer
> 
> At 03:00 AM 11/23/2000 +0100, Jiri Kuthan wrote:
> >hammer michael wrote:
> > >
> > > Keep in mind that encryption is a technology, not a service.
> > > To be clearer, decide whether you are talking about 
> confidentiality,
> > > authentication, non-repudiation, or whatever.
> >
> >Problem: It is dangerous to transport CPL security credentials (SC)
> >          or even some CPL scripts (like those that include lists of
> >          enemies) in clear-textover a network.
> >Needed service: privacy of transported CPL SCs/scripts
> >Recommended technology: encryption
> >
> > > To say that encryption
> > > belongs only in the transport realm, it taking a very 
> narrow view of its
> > > possibilities.
> >
> >I do not see any advantage of inventing a mechanism for
> >encryption of CPL scripts or SCs if I can take a generic one
> >available in a transport protocol.
> >
> >Jiri
> >
> > > > > Sending authentication in a
> > > > > script like this would require the script be encrypted for
> > > > transmission, clearly stepping
> > > > > outside of CPL's domain.
> > > >
> > > >Encryption is a transport rather than CPL issue. It is 
> useful anyway --
> > > >maybe you are not eager to transport a plain-text CPL 
> script that includes
> > > >a list of inconvenient caller whose calls you drop.
> 
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 30 Nov 2000 09:46:32 -0500

> there is a way around that.

Without trying to play lawyer here, you rarely need absolute proof, but
rather just credible evidence, particularly in a civil suit for damages.
If your signed script shows up on a server, you have to explain how it
got there without your knowledge or consent, particularly if the server
operator can demonstrate that uploading requires some kind of
authentication, as it invariably will. "My dog stole my key and my evil
twin then uploaded the script" is not likely to convince a judge. Thus,
we should be careful not to try to impose requirements that have little
to do with the real world. Indeed, you probably don't even need a signed
script. Requiring authentication during upload means that there is a
prima facie case that you did the upload. You then have to make a
reasonable case that the operator turned your perfectly harmless script
into a monster script that brought down the phone network. Any operator
will write a clause into its contract that will say something like
"you're responsible for your account; if your account uploads a
malicious script, it's your problem".

In real life, we operate with lots of such presumptions of validity. For
example, most receipts are easily forged, as are faxes, yet they are
routinely accepted as evidence. (Most contracts don't require written
evidence at all, but that's a separate issue.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: hammer michael <[email-masked]>
Date: Thu, 30 Nov 2000 10:28:38 -0800

Quick comment on the operator changing the script:  Normally the signature 
would be based on a hash of the message (i.e. script).  Changes to the 
script by the operator would cause the signature verification to 
fail.  Therefore, I do not think that claims that the operator changed the 
script, given a valid signature would hold.

I would agree that a claim that an operator pulled up a malicious script 
and damaged his own network would not hold water, especially if the process 
was one where the scripts are pushed to the server.

Mike