Subject: E911 location services

From: Info <[email-masked]>
Date: Fri, 11 Jun 2004 06:47:51 -0400

Good day.

Does anyone know if there is any work going on within the IETF on E911 
location services???   If there is, which working groups should we sign 
up to.

Regards

Kelvin

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Richard Shockey <[email-masked]>
Date: Fri, 11 Jun 2004 10:27:51 -0400

At 06:47 AM 6/11/2004, Info wrote:

>location services???   If there is, which working groups should we sign up to.

start here

http://www.ietf.org/html.charters/geopriv-charter.html

Check out this work ..

http://www.ietf.org/html.charters/ieprep-charter.html

monitor ongoing developments here.

http://www.ietf.org/html.charters/sipping-charter.html

There is very very active coordination in the IETF with NENA on these issues

http://www.nena.org/

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Sal Mangiapane" <[email-masked]>
Date: Fri, 11 Jun 2004 12:01:25 -0400

Hello Kevin and all,

I have been researching digital signatures in the hope of finding or starting a work to develop a scalable certificate authority
server (CAS) system based on standards such as X.509v3 from the pkix working group and using domain names from DNS as the basis for
tree rather than X.500 naming convention.

The PKI standards are stable and in current use today.  This CAS system would provide services such as non-repudiation of servers
for other applications to use.  Initially, I see it used only for authentication.  The CAS system could be extended for access
control and encryption too.

For example (authentication),
   * DNS could use it to prevent name server IP spoofing.
   * e-Mail could use it to verify SMTP servers, sender and receiver email addresses (Similar to the Yahoo offering - privacy of
valid email addresses must be supported).
   * VoIP in conjunction with ISP could use it to provide verifiable locations.
   * routers could support signing to provide a auditable traces for law enforcement, etc.  (Lots of overhead - not recommended for
general use).
   * IM could use it to prevent spoofing.
   * LDAP could be extended to become an organizations CAS authoritative server.  For example ldap.example.com would provide public
keys for example.com.
I expect each working group would participate in their application's implementation.

The root of the trust could be a "Bridge" certification authority as defined in 1.4.4 within draft-ietf-pkix-certpathbuild-03.txt.
Each TLD would be a "Principal" Certification Authority.
The draft is found at www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt NOTE: the draft expires this month.  Some
RFCs refer to PKI implementations within their application such as: routers - RFC2154; IP - RFC1825; email - RFC1422, RFC1423, and
RFC1424.  This is why I thought a standardized platform would make sense.  Consider DNS many applications rely upon DNS to provide
their services.  I see the same being true for CAS.  Actually, I was hoping to find someone already working on this....

Is there a group working for goals like this?
      OR
How do I make a presentation to IETF in order to begin a work?

> location services???   If there is, which working groups should we sign

Something like this could fit into the E911 that you are researching.

Regards,

Sal

Salvatore Mangiapane

---

From: "Sal Mangiapane" <[email-masked]>
Date: Fri, 11 Jun 2004 16:22:19 -0400

I'm new to this process.

I'm now reviewing RFC2026 and I see that I should not have referenced a "draft".  

Pardon me for that mistake.

> The root of the trust could be a "Bridge" certification authority as defined 
> in 1.4.4 within draft-ietf-pkix-certpathbuild-03.txt.
> The draft is found at www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt
> NOTE: the draft expires this month.

Let me change the reference to:

Bridge Certification Authorities: Connecting B2B Public Key Infrastructures 
by William T. Polk and Nelson E. Hastings 
for National Institute of Standards and Technology.

This document can be found at:
http ://csrc.nist.gov/pki/documents/B2B-article.pdf

The "Bridge" and "Principal" explanations are virtually the same in both documents.

Best Regards,

Sal

Salvatore Mangiapane

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 11 Jun 2004 14:56:33 -0700

Sal,

the idea of setting up a server that everyone in the world would trust was 
suggested in RFC 1422 (IPRA), in 1993.
It did not succeed terribly well then, and people have tended to look very 
skeptically upon ideas that require some sort of "single root" since then.

What's your reason to believe it could succeed this time?

--On 11. juni 2004 12:01 -0400 Sal Mangiapane <[email-masked]> 
wrote:

> Hello Kevin and all,
>
> I have been researching digital signatures in the hope of finding or
> starting a work to develop a scalable certificate authority server (CAS)
> system based on standards such as X.509v3 from the pkix working group and
> using domain names from DNS as the basis for tree rather than X.500
> naming convention.
>
> The PKI standards are stable and in current use today.  This CAS system
> would provide services such as non-repudiation of servers for other
> applications to use.  Initially, I see it used only for authentication.
> The CAS system could be extended for access control and encryption too.
>
>    * e-Mail could use it to verify SMTP servers, sender and receiver
> email addresses (Similar to the Yahoo offering - privacy of valid email
> addresses must be supported).
>    * VoIP in conjunction with ISP could use it to provide verifiable
> locations.    * routers could support signing to provide a auditable
> traces for law enforcement, etc.  (Lots of overhead - not recommended for
> general use).
>    * LDAP could be extended to become an organizations CAS authoritative
> server.  For example ldap.example.com would provide public keys for
> example.com.
> The root of the trust could be a "Bridge" certification authority as
> defined in 1.4.4 within draft-ietf-pkix-certpathbuild-03.txt. Each TLD
> would be a "Principal" Certification Authority.
> The draft is found at
> www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt NOTE:
> the draft expires this month.  Some RFCs refer to PKI implementations
> within their application such as: routers - RFC2154; IP - RFC1825; email
> - RFC1422, RFC1423, and RFC1424.  This is why I thought a standardized
> platform would make sense.  Consider DNS many applications rely upon DNS
> to provide their services.  I see the same being true for CAS.  Actually,
> I was hoping to find someone already working on this....
>

---

From: "Sal Mangiapane" <[email-masked]>
Date: Fri, 11 Jun 2004 22:37:26 -0400

> What's your reason to believe it could succeed this time?

The short answer; I'm not sure.  A PKI system is technically a good mechanism
to provide non-repudiation.  I think there is tremendous benefit in non-
repudiation which makes it worth while.  Non-repudiation is all that I'm
suggesting.

The long long long answer (forgive the lengthy answer :)

Some differences to this proposal(CAS) compared to RFC 1422:

1422: Based upon X.500 naming convention which is not in general use.
CAS : Based upon DNS naming convention which in foundational to internet use.

1422: Use PKI to validate foreign users.  Foreign being email addresses in a
      different domain, the RCPT TO address.
CAS : Require data privacy.  The first SMTP server MUST verify the MAIL FROM
      the last SMTP server MUST verify the RCPT TO.  Every SMTP would append
      a digital signature.

1422: Single root the IPRA.
CAS : Each TLD would be the root of it's tree very similar to DNS today.  The
      bridging certificates are provided as a service so a server with a name
      ending in COM could trust a server with a name ending in NET.

1422: Use PKI to encrypt messages.
CAS : MAY use PKI to encrypt messages.  This is not part of the requirement
      for a CAS system.  It is a feature of PKI that could be used.

1422: IPRA is certifying body and provider of certificates.
CAS : Each domain would provide it's own certificates.  Let me explain how
      I see this implemented because this is where (I think) the scalability
      and biggest differences comes in.

There would be a CAS record in DNS to designate the authoritative CAS server.
This server would own all certificates for it's domain (example.com).  Every
domain owner would be REQUIRED to have a CAS server just like every domain
owner is REQUIRED to have a DNS server.  The hierarchy just manages the trust.
COM would provide certificate for EXAMPLE.  EXAMPLE would provide
certificates for WWW, MAIL, LDAP, whatever... I would suggest that each email
address could have a certificate too.  The [email-masked] certificate
would be managed by CAS server for EXAMPLE.COM too. 

In order to send "trusted" email from [email-masked] to
[email-masked] the MAIL.EXAMPLE.COM would 1)verify [email-masked]
with or without a certificate, 2)sign the email and 3) forward it
to MAIL.EXAMPLE.NET.  MAIL.EXAMPLE.NET would 1) verify [email-masked]
2) query it's own CAS server which would recursively query CAS servers up
the NET tree across the bridge and back down the COM tree to EXAMPLE.COM
CAS server.  The CAS server would then pass the public key to
MAIL.EXAMPLE.NET so it could verify the signature from MAIL.EXAMPLE.COM and
accept the email, and 3) sign the email, and finally 4) forward the email to
[email-masked].

The CAS servers would rely upon DNS for resolving IP addresses as you would
expect.  But, I would recommend that CAS IP address would be REQUIRED as
manual entry similar to the default gateway and DNS server entries.  I do not
believe that DNS can provide trust by itself.  I do not believe that CAS can
provide trust by itself.  Both the DNS and the additional setting for CAS IP
address would be required to provide independent path for auditing.  You
can't have one server that just provided you an answer to verify itself,
because any attack to compromise a server could and would authenticate
itself.  At least two servers (DNS and CAS) would need to be compromised to
successfully complete an attack.

Also, I would expect two types of CAS servers.  One being the authoritative
CAS server for authoritative public keys.  The other being resolving CAS
server for querying (and cache-ing) public key answers.  Note, resolving CAS
servers would need to be simple to implement but also need to be uniquely
named.  I believe there would be trust assumptions possible for Private-use
networks(as defined in RFC 3330) that also mask to a local address.

Also, each entity could have multiple key pairs.  I see the need for 1)single
use and 2)limited timestamp certificates.  For example, com.user has web
based access to email.  When working from the office com.user would have an
established PKI.  Planning for vacation or business trip, com.user would
create a set of key pairs with a timestamp for each day.  So entering a
private key on an untrusted computer would only cause limited damage.  A
single use key may also work in this situation.  The private keys could be
stored on some device like a san disk or floppy disk.

Also, PKI needs some assistance for initially establishing authenticity.  I
would propose using Shared Secret Keys(SSK).  Because certificates can be
revoked additional overhead would be required to rely upon PKI for initial
startup. So, each internet based server(IBS) would be REQUIRED to have an SSK
with it's resolving CAS server.  There might be multiple CAS servers, just
like DNS, but the number of servers would be manageable.  Exceptions for
omitting the SSK MAY be provided for private-use networks (as described in
RFC 3330).  The SSK would need to be entered via some out-of-band method.
The IBS would have to know 1)it's own private key 2)the shared secret key and
3)the CAS IP address.  The resolving CAS server would have to know 1)the IBS
public key and 2)the shared secret key.  Upon IBS startup, it would query the
CAS providing it's public key.  The CAS would respond with 1)the SSK and
2)the CAS (it's own) public key.  The CAS would encrypt these with the IBS
public key. The IBS would decrypt the message and verify the SSK.  The IBS
would have a trusted CAS public key!  All public servers including CAS
servers would have to include this extra step during startup.

Also, CAS could be used for SERVER-A to directly establish a PKI trust with
SERVER-B.  This could be used for B2B or legal type transactions.  SERVER-A
and SERVER-B would have to self maintain this key pair for their trust
relationship it would not be maintained by the CAS system.  This would be a
business decision and would require some command to initiate this trust
transaction.  The business server only needs to know the FQDN to setup the
trust because it could rely upon CAS to initially establish the trust. This 
would truly help prevent MiTM attacks.

If you are reading this, I may actually have an implementation that merits
further review.  Thanks for your inquiry.

Best Regards,

Sal
Salvatore Mangiapane

---

From: Bill Manning <[email-masked]>
Date: Fri, 11 Jun 2004 20:27:12 -0700 (PDT)

% If you are reading this, I may actually have an implementation that merits
% further review.  Thanks for your inquiry.
% 
% Sal
% Salvatore Mangiapane

	roughly, see DNSSEC.  If you just want to use the
	DNS to store CERTS, yor in luck.  The CERT RR is supported
	in most of the deployed software.  If you -really- want this
	to work, you need to be able to trust what the DNS gives you.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Sal Mangiapane" <[email-masked]>
Date: Sat, 12 Jun 2004 01:22:29 -0400

>     If you -really- want this

If (this is a BIG if):

1) this so called CAS system were implemented
2) DNS chose to use the CAS system to provide DNS server digital
   certificates
3) DNS servers would sign queries.  I mean server signatures as in
   non-repudiation that the response originally came from the
   authorized DNS server.

I'm trying to say that you could trust what DNS gives you.  Of course,
the trust is only as good as the protection of the private key and the
technology providing PKI.  I'm relying upon the reading I have done
that simply states that a third party verified digital signature can
provide nonrepudiation. I think the CAS system could be used to
reliably establish the DNS "trust anchor" because CAS becomes the
third party verifier between a DNS resolver and a requesting computer.

Sounds like this is an uphill battle.  I believe that a CAS system
does have merit.

Sal
Salvatore Mangiapane

---

From: Bill Manning <[email-masked]>
Date: Sat, 12 Jun 2004 09:00:49 -0700 (PDT)

% 
% >     If you -really- want this
% > 	to work, you need to be able to trust what the DNS gives you.
% > 
% > 
% > --bill
% 
% If (this is a BIG if):
% 
% 1) this so called CAS system were implemented
% 2) DNS chose to use the CAS system to provide DNS server digital
%    certificates
% 3) DNS servers would sign queries.  I mean server signatures as in
%    non-repudiation that the response originally came from the
%    authorized DNS server.
% 
% I'm trying to say that you could trust what DNS gives you.  Of course,
% the trust is only as good as the protection of the private key and the
% technology providing PKI.  I'm relying upon the reading I have done
% that simply states that a third party verified digital signature can
% provide nonrepudiation. I think the CAS system could be used to
% reliably establish the DNS "trust anchor" because CAS becomes the
% third party verifier between a DNS resolver and a requesting computer.
% 
% Sounds like this is an uphill battle.  I believe that a CAS system
% does have merit.
% 
% Sal
% Salvatore Mangiapane
% 

	please review the namedroppers archives, much of the
	operational DNSSEC workshop/presentation material
	<www.dnssec.net>.  Further discussion should likely
	be on the pki & dns wg lists and not on the general IETF
	list.

--bill

---

From: Stephen Kent <[email-masked]>
Date: Sun, 13 Jun 2004 13:49:09 -0400

Harald,

You are right that the scheme I proposed inn 1422 did not succeed, 
and today I would not suggest it. But, the reason I would not suggest 
it today is because I have come to believe that one should adopt CAs 
that are authoritative for the certs they issue, not "trusted" third 
parties. The DNS root is an example of such a CA, whereas RSA 
(proposed as the IPRA) was not.  If we deploy DNSSEC in a full, top 
down fashion, the effect is the same as what Kevin is suggesting, 
expect that we would be using a standard cert format that is employed 
by many security protocols.

steve

---

From: "Sal Mangiapane" <[email-masked]>
Date: Mon, 14 Jun 2004 14:48:02 -0400

Thanks for the insight,

> by many security protocols.

I have no problem with the DNS authorities providing the authoritative
certs.  Actually without saying that I was thinking that they would be
authoritative for their own tree.  And just as DNS lets me
(servanttechnology.com) setup the servers (www, mail, etc...) in my tree
I would see the CAS system giving that same authority. I do believe that
a "bridge" trust between top level domains is a good solution rather
than the single root CA that if compromised would compromise all certs.
One difference between my vision for CAS and DNS is that DNS is expected
to provide all information publicly.  The CAS would be required to
keep some information private.

I am trying to see if there is any interest using a parallel set of 
servers providing basically public keys.  This would parallel DNS which 
would continue providing IP addresses.  Maybe the parallel system is
overkill I'm not sure.  I like it because it provides an independent
path to verify certs.  For example, the DNS could provide a signed
response and the CAS would be act like a third party providing the
public key to verify the cert.  Otherwise, DNS would provide the 
signed cert and the public key to verify it.

I'm not sure but I would like to work out a solution.  DNSSEC works in
addition to what I think CAS would be.  The CAS cert would be for the
actual server answering the question "Can I believe that you are who
you say that you are?"  Where the DNSSEC is mainly concerned that the
DATA has a cert.  It is a different approach.  Also, DNSSEC refers to
an undefined "trust anchor" I think CAS could fill that void.

The reason I think there is need for a CAS is because DNS is beginning
to use certs.  E-mail is talking about it.  VoIP will need to work out
some mechanism too.  Why not just put a general system of servers that
provides services (a framework) for cert.  Then every application (DNS,
E-mail, VoIP, etc...) can use it to support their own PKI services
requirements.  As I see it, even this framework should not reinvent the
wheel because work is already being done by the pkix WG.

Thanks again for the feedback.

Sal
Salvatore Mangiapane

---

From: "Sal Mangiapane" <[email-masked]>
Date: Mon, 14 Jun 2004 14:48:20 -0400

> 	be on the pki & dns wg lists and not on the general IETF

Thanks I will do that.

I think that I will need to more clearly present my ideas
within a WG list.  I will work on that too.

Regards,

Sal
Salvatore Mangiapane