Subject: [IPTEL] agenda items

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2000 02:11:28 -0500

Folks,

I had sent out a note a few weeks back encouraging people to submit drafts
to facilitate discussion of future directions for the group. These include
things like intra-domain routing, service routing, CPLng, etc. To date, I
know of only one draft and one agenda slot request as a result of that. If
you submitted a draft and didn't tell me, please do so. Also, if you want a
slot and haven't yet told me, please do so now.

It is likely that our time will be reduced from our current 2.5 hours to
half that. We don't need 2.5 hours (since there will not be a trip or cpl
discussion), and there is a long waiting list for BoFs that could use the
time. 

I am unsure if this will cause the group time to be moved away from its
current Monday morning 9am slot. If it does, I will advise asap.

Finally, I put out a plea for help on TRIP security on the list a while
back. Response was thin, very thin. Once again, if you know anything about
security and TRIP, please contact the authors.

Thanks,
Jonathan R.

---
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: Jiri Kuthan <[email-masked]>
Date: Tue, 21 Nov 2000 20:05:38 +0100

Jonathan,

I would like to see three CPL extensions:
- authentication support -- useful if signaling depends
  on user credentials
- access to external databases -- useful with long shared lists
- support for usage of CPL in end-devices -- useful if CPL services 
  are stored at a SIM card which the users put into different cell
  phones  (we already had this on the list, a solution could look 
  like <ring user_profile="ring_and_shake">)

I submitted a tiny I-D on the first two issues. Its main purpose
is to stimulate a discussion on whether these extensions are
considered needed, though some examples on how it could 
look like are also attached.

Until it appears in the I-D directory, it is available at
http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt

Jiri

---

From: James Undery <[email-masked]>
Date: Wed, 22 Nov 2000 10:04:58 +0000

> - authentication support -- useful if signaling depends

This is a endpoint issue, the only time I can see you'd want authentication support is in
outgoing calls, so your phone should handle it if needed. Sending authentication in a
script like this would require the script be encrypted for transmission, clearly stepping
outside of CPL's domain. If you can think of a sane case where a subscriber wants to
authenticate incoming calls I'd be impressed.

> - access to external databases -- useful with long shared lists

Access to external databases is supported for lookups (Unfortunately I can't contact

>   like <ring user_profile="ring_and_shake">)

This is sort of demonstrated in figure 27 of the last two drafts.

---

From: James Undery <[email-masked]>
Date: Wed, 22 Nov 2000 10:13:15 +0000

Oops I appear to have lost some of the last message

> Access to external databases is supported for lookups (Unfortunately I can't contact

Unfortunately I can't contact your website to check the usage of databases you want.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 22 Nov 2000 15:03:11 +0100

James Undery wrote:
> outgoing calls, so your phone should handle it if needed. 

Not necessarily. If you want to filter out some callers and do not trust 
the From field you may want to make sure a caller authenticated himself. 
The process of authentication can take place as most of other call processing 
in UAs as well as in proxies. If a user moves from a device to a device, the 
latter alternative is preferable.

> Sending authentication in a
> 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.

> your website to check the usage of databases you want

I'd like to have access to external DBs in matching expressions as well.

The webserver is up and running again and the document is available at 
http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt
before it appears in the IETF directory. Sorry for server outage.

> This is sort of demonstrated in figure 27 of the last two drafts.

Exactly.

Jiri
-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
		    tel:+49-30-34637271
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: hammer michael <[email-masked]>
Date: Wed, 22 Nov 2000 12:03:50 -0800

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.  To say that encryption 
belongs only in the transport realm, it taking a very narrow view of its 
possibilities.

Mike

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 23 Nov 2000 03:00:12 +0100

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

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 22 Nov 2000 21:05:21 -0500

> Recommended technology: encryption

Already exists, as REGISTER script uploads can be encrypted, either at
transport (TLS) or application (PGP) level.

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

---

From: hammer michael <[email-masked]>
Date: Mon, 27 Nov 2000 10:02:17 -0800

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

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 27 Nov 2000 17:35:01 +0100

> the script had been signed, then you would have a case against me.

What you are asking for is a definitely useful service. Note that
it is neither specific to the proposed extensions nor to CPL.
We already have secure transport mechanisms ( E.g., TLS/PGP if you 
use SIP REGISTER for transport, draft-lennox-sip-reg-payload-01.txt )
that cover the need for security in payload-independent way.

Note that there can be a terminological confusion here -- transport does 
not necessarily imply layer 4. In this context it can be also an arbitrary 
application protocol used to transport CPL scripts from one place to another 
one.

> sender.  

If there is support for it you can authenticate using the transport mechanism.

> I am not suggesting that you not use transport layer security,

Actually, the sip-reg I-D already mandates REGISTERs to be authenticated
and strongly recommends verification of message integrity. Of course, 
these requirements are reasonable for any other transport mechanism 
(e.g., HTTP) as well.

Jiri

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 28 Nov 2000 15:33:42 -0500 (EST)

> - authentication support -- useful if signaling depends

I agree this is useful.  One big hole in CPL as it is now is that you can
have your call handling be based on the origin, but in SIP as it exists now,
there's no guarantee that someone claiming to be [email-masked]
actually is that person.

Unfortunately, this is a bigger problem than just for CPL.  While I would
love to have some way of switching on authenticated addresses in CPL, it
first needs to be figured out how to do this in IP telephony in gneeral, or
at least in specific protocals such as SIP.  Once a framework for this is
worked out, we can figure out how best to map these things into CPL.

I don't think IPTel is the right forum for doing this sort of thing, though
certainly the needs of a CPL authentication switch would be a major
requirement sent as input to that process.  (Given that it would probably be
much the same *people* doing this, I don't think a formal liaison statement
from the IPTel working group to the SIP working group listing authentication
requirements would be too helpful, though.)

> - access to external databases -- useful with long shared lists

The idea being to have something like the "rogue site blacklists" used for
E-Mail to cooperatively block spammers?  This would be useful; I don't
really understand the syntax you were proposing, though.

>   like <ring user_profile="ring_and_shake">)

I agree with this, but we need a clearer picture of what the capabilities
and requirements should be.

-- 
Jonathan Lennox
[email-masked]

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 28 Nov 2000 22:36:21 +0100

Jonathan Lennox wrote:
> requirement sent as input to that process. [...]

Actually, I'd like to have authentication switching dependent on
authentication id and independent on authentication mechanism. The
place where mechanism-dependencies is unavoidable is the credential 
database. 

The authentication switch can be specified at iptel because it is 
independent on the mechanism. Authentication protocols come and go
and should not affect authentication switching. I'm not sure what 
the most appropriate place for working on a specification of the 
credential database format is.

> E-Mail to cooperatively block spammers?  

Exactly.

> This would be useful; I don't really understand the syntax you were proposing, though.

The idea behind that particular proposal is to enable accessing the lists
from any place (address switches, string switches, whatever) without changing
CPL's syntax. The hack is to indicate with an escape sequence that a value
should be interpreted as a reference to a list. E.g., 
  <address is="@@http://www.nospam.org/badguys.txt">
	<reject/>

I do not insist on this particular syntax, other ideas are appreciated.

> > - support for usage of CPL in end-devices [...]
> 

Yes. What is IMHO needed is an operation that passes signaling control
to human user and allows to specify how the user is rung in a device-
independent manner. (I.e., what Figure 27 shows in -04 I-D.) Any other 
suggestions/requirements?

Jiri

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 28 Nov 2000 17:04:05 -0500

> credential database format is.

In practice, this is not likely to be as big a deal. Authentication at
CPL level is primarily useful for rejecting spammers, as mentioned, and
possibly to give access to otherwise restricted destinations to
'special' people. For that, we have three levels of 

- make sure the caller can be reached - to prevent the SIP version of
kids ringing doorbells and running away

- make sure that the caller's SIP or H.323 address is legitimate. One
could, for example, build a UA that doesn't accept calls, but rather
returns the INVITE with the same Call-ID or other token to the caller.
Assuming intercept is not likely, this is reasonably secure and requires
no PKI.

- set up secrets ahead of time, by (e.g.,) emailing them to the caller,
similar to how most level-1 certificates work

- full-fledged PKI. Not likely except in closed communities, i.e., at
best useful for the second application of authentication.

CPL doesn't have to know anything about the details, just needs to
convey the level of authentication used to verify the identity, allowing
the script to make appropriate choices.

> I do not insist on this particular syntax, other ideas are appreciated.

I have to admit that I find this type of URL special-casing less than
savory. If you want to check for a list, create a new qualifier other
than 'is'.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 29 Nov 2000 03:11:36 +0100

> savory. If you want to check for a list, create a new qualifier other

Why could not I indicate list iteration in the operand (as opposed
to operator) and interpret 'is=<somelist:={a,b,c,...}>' as
'is a OR is b OR is C or ...' ? 

Such an interpretation does not sound violent to me. I can also think 
of embedded lists such as is="a | b | c" -- they would save some script 
typing as opposed to an enumeration is=a, is=b, is=c.

An overview of the alternatives is attached. They differ
in whether list iteration and exteral reference are 
indicated in operator or operand. They include the possibility
of embedded lists as an option. 

Any preference? 

Jiri

----

			| External References
        Multiple Values |  by operand    |   by operator
			| (w/escape)     |  (per switch)
       -----------------+----------------+----------------
            by operand  |       A        |       B
       (redefinition of |                |
        operand meaning)|	         |
       -----------------+----------------+----------------
            by operator |       C        |       D
       (+per switch)    |                |

A) URL by operand, list by operand
remote list:	         <address is="@@http://www.nospam.org/badguys.txt">    
local list (optional):   <address is="[email-masked] | [email-masked] | @@http....">  

=> no new operator needed, 1-2 operand changes needed

B) URL by operator, list by operand
rl:	<address is_aturl="http://www.nospam.org/badguys.txt">	
	(the same goes for contains and subdomain-of)
ll(o.):  <address is="[email-masked] | [email-masked]">    

=> 3 new operators (for each switch, incl. accompanying operands), 
   0-1 operand change needed

C) URL by operand, list by operator
rl:	  <address is_anyof="@@http://www.nospam.org/badguys.txt">   
	  (the same goes for contains and subdomain-of)
ll:       <address is_anyof="[email-masked] | [email-masked] | @@http...."> 
	  (the same goes for contains and subdomain-of)

=> 3 new operators (for each switch, incl. accompanying operands),  
   1 operand change needed

D) URL by operator, list by operator
rl:	<address is_anyof_aturl="http://www.nospam.org/badguys.txt">   
	(the same goes for contains and subdomain-of)
ll(o.): <address is_anyof="[email-masked] | [email-masked]"> 
	(the same goes for contains and subdomain-of)

=> 3-6 new operators (incl. accompanying operands),  0 operand 
   change needed

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 28 Nov 2000 21:51:41 -0500

> typing as opposed to an enumeration is=a, is=b, is=c.

Yes, but the problem is that you're now making certain characters
special in the string. Leads to escaping, special syntax. Since CPL is
not primarily meant to be written by hand, I'd rather let the XML parser
do all the parsing rather than writing another expression parser.

> of embedded lists as an option.

As I indicated above, doing expressions in "" arguments is, in my view,
a real big hack, complicated to implement and leading to escaping and
spacing nightmares (foo|bar is now possibly different than foo | bar).

>                         | (w/escape)     |  (per switch)

None of these ll options are, in my view, acceptable. We have nesting
and alternatives at the CPL level, so there's no need to replicated
this.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 29 Nov 2000 16:08:31 +0100

> spacing nightmares (foo|bar is now possibly different than foo | bar).
[...]
> and alternatives at the CPL level, so there's no need to replicated

Given the priority to retain meaning of operators used with existing
operands, the extensions could look like this:
- new operators that indicate that operand is to be evaluated as a list
- if prefixed by an escape sequence a list item is interpreted as
  a reference to an external list
Examples:

<address is_anyof="[email-masked] | [email-masked] | @@http://www.nospam.org/badguys.txt">
<subject contains_anyof="make money | for free | @@http://www.nospam.org/dirtywords.txt">

This syntax still uses the local list:
a) it is much more convenient for "vi-powered" writers
b) since it refers to a new operator, meaning of existing operands remains unchanged.

Does this make sense? If not, than the "only-external-lists" alternative
(i.e., new operators that indicate that operand is to be evulated as
a reference to external list) would look like:

<address is_anyof_aturl="http://www.nospam.org/badguys.txt">
<subject contains_anyof_aturl="http://www.nospam.org/dirtywords.txt">

Jiri

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 29 Nov 2000 11:45:33 -0500

I made my point a few times that I find syntax within "" arguments
dangerous and a recipe for escaping and parsing nightmares. I'm not sure
what else to say. No, I still don't find the syntax acceptable. CPL can
be written by vi, but that is, in the long run, not necessarily going to
be the most common means, so I see no need to optimize for that.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 29 Nov 2000 18:24:06 +0100

So this is the escape-free alternative:

  Adding new parameters to address and string switches. The parameters
  indicate that a value is a URL pointing to a list of values separated
  by a well-known delimiter. The condition matches if any of list items
  matches.

Examples:
  <address is_anyof="http://www.nospam.org/badguys.txt">
  <subject contains_anyof="ftp://www.nospam.org/dirtywords.txt">

Can we agree on this?

If so, how do will we deal with error handling? Does indication of timeout
and subaction for processing of failed list access sound reasonable?
I.e., something like 
  <address is_anyof="http://www.nospam.org/badguys.txt" 
	   timeout="10" error_handler="drop_call_and_log">

Jiri

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 29 Nov 2000 14:06:27 -0800

>do all the parsing rather than writing another expression parser.

To steer this in another direction, could XMLDSIG be successfully applied 
here to solve some of the problem?