<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Excellent summary! :-)</DIV>
<DIV>Have you looked at <A
href="http://www.cacert.org/">http://www.cacert.org/</A> ?</DIV>
<DIV>g-)</DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=cesc.santa@gmail.com href="mailto:cesc.santa@gmail.com">Cesc</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=klaus.mailinglists@pernau.at
href="mailto:klaus.mailinglists@pernau.at">Klaus Darilion</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=serusers@iptel.org
href="mailto:serusers@iptel.org">serusers@iptel.org</A> ; <A
title=users@openser.org href="mailto:users@openser.org">users openser.org</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, October 12, 2005 11:13
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Users] Re: [Serusers]
trusting peers</DIV>
<DIV><BR></DIV>
<DIV>Hi,</DIV>
<DIV> </DIV>
<DIV>Klaus, i think that you hit the fountain of truth :)</DIV>
<DIV>As of now, ser-tls only provides transport layer authentication. Not
more. Who is allowed to authenticate? all those you trust, that is, all those
with the cert signed by the CAs you trust. If you picked a ruthless CA that
would give away certs to <A
href="http://hacking.incorporated.com">hacking.incorporated.com</A> ... sorry
:)</DIV>
<DIV> </DIV>
<DIV>Now, for sip message authentication and authorization you need to
lift the authentication information from TLS up to the application (ser). It
is not difficult, it just needs a few lines of code for that (all the certs
exchanged are within reach for as long as the tls connection stays up). Here
is where the tls_tools module's functions (to be written) come into play:
</DIV>
<DIV>- tls_check_from/to()</DIV>
<DIV>- tls_check_cn_trusted()</DIV>
<DIV>- ... <BR><BR>So, let's say we want to set up a tls test network (which
we do).</DIV>
<DIV>We don't want to pay for the certs, so we should generate a root cert
(say, "<A href="http://openser.org">openser.org</A>"). It would be even better
if some nice CA whose cert is signed by a recognized root would do sign that
for us ... anyone with connections? :) This would ease transition and
compatibility issues ... </DIV>
<DIV>The root cert provides certs for each domain (providerX.com,
providerY.net, ... )</DIV>
<DIV>Now, we all can authenticate each other.</DIV>
<DIV>With the tools for sip authentication and authorization, you can decide
who you allow to do what in your proxy ...</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV> </DIV>
<DIV>Cesc</DIV>
<DIV> </DIV>
<DIV><SPAN class=gmail_quote>On 10/12/05, <B class=gmail_sendername>Klaus
Darilion</B> <<A
href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Nils
Ohlmeier wrote:<BR>> Klaus, if you do not trust <A
href="http://badguy.com">badguy.com</A> although he has a valid singed
<BR>> certificate from a CA which you trust, then you can throw away
TLS<BR>> completely.<BR><BR>There is a big difference between
authentication and authorization.<BR><BR>1. I have to authenticate the peer.
Using TLS and certifiactes is fine. <BR><BR>2. I have to authorize the peer.
Some peers will be e.g. routed<BR>different. You would this this
like:<BR> if (message is from trusted peer)
{<BR> ....<BR><BR>So I need to check the
certificate in ser.cfg somehow, or associate the <BR>domain in the From
header with the domain in the certificate.<BR><BR>Or do I miss the
point?<BR><BR>regards<BR>klaus<BR><BR>> The hole model only works because
the trust in inherited from the CA when you<BR>> get a singed
certificate. <BR>> If you do not trust any CA, except your own, then you
created your own trust<BR>> database which is hard to maintain. No matter
what is the base of the<BR>> trustworthyness (IP; certificate signed by
you; shared secret or signed <BR>> certificate for IPSec) maintaining the
trust database (or however you call<BR>> it) is a real pain, that is the
reason why you should trust someone else to<BR>> do this
job.<BR>><BR></BLOCKQUOTE></DIV>
<P>
<HR>
<P></P>_______________________________________________<BR>Serusers mailing
list<BR>Serusers@iptel.org<BR>http://mail.iptel.org/mailman/listinfo/serusers<BR></BLOCKQUOTE></BODY></HTML>