Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt

From: [email-masked]
Date: Mon, 10 Oct 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: ENUM Validation Token Format Definition
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-validation-token-00.txt
	Pages		: 16
	Date		: 2005-10-10
	
   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether the Registrant of an ENUM
   domain name is identical to the Assignee of the corresponding E.164
   number is commonly called "validation".  This document describes an
   signed XML data format -- the Validation Token -- with which
   Validation Entities can convey successful completion of a validation
   procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-validation-token-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-validation-token-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 10 Oct 2005 18:18:53 -0700

I have not read the I-D, deliberately, but I did read anbd re-read the 
summary. If folks are willing, perhaps discuss the following issues, so I 
have retain open mind before I review the text formally:

The summary says: a validation token conveys (securely) information 
pertainting to the completion of a validation method, by a Validation 
Entity. Presumably, the token conveys the result of the validation, and 
induces the relying party to verify the authority of the token's issuer.

Becuase the security (of the token's communication) depends upon signed XML, 
we know that the token's origin authentication depends itself on the relying 
party first authenticating the token signature's verification key (assuming 
that the signing method for the XML stream depends on crypto).

(a) are we assuming that ENUM and/or secure DNS protocols shall be used to 
distributed information allowing relying parties to authenticate signature 
verification keys, identifed as being associated with the authority of 
particular Verification Entities to issue Verification Tokens?

(b) is reliance on a Verification Token a matter for the public, or is 
reliance on the signature/token intended to be limited to only those parties 
authorized by the Verification Entity?

(c) are we assuming that trust model for distributing the signing/issuing 
authority of Verification Entities shall be "tied to" (or derived from) the 
the number issuing hierarchy, for the identities being Verified?

(d) What IETF disclosures, discussions or contacts have there been between 
IAB and ISO concerning the relationship of the trust model, providing for 
authentication of the tokens conveying an Verification Entities confirmation 
of the domain-name<->E.164 identity?

>From: [email-masked]
>To: [email-masked]
>CC: [email-masked]
>Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Date: 
>Mon, 10 Oct 2005 15:50:02 -0400
>

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 11 Oct 2005 11:25:19 +0200

On 2005/10/11 03:10, Peter Williams <[email-masked]> wrote:
> summary. 

You might want to read the architecture draft by Mayrhofer/Hoeneisen.
(ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-enum-validation-arch-00.txt)

My token draft operates within the role models and trust-relationships 
defined there.

> Becuase the security (of the token's communication) depends upon signed 
> XML, we know that the token's origin authentication depends itself on the 
> relying party first authenticating the token signature's verification key 
> (assuming that the signing method for the XML stream depends on crypto).
> 

> particular Verification Entities to issue Verification Tokens?

No.

>From my draft:

	Whether the Registry acts as a certificate authority, accepts certs
	from a public CA, or only accepts pre-registered keys is a local policy
	choice.

> reliance on the signature/token intended to be limited to only those 
> parties authorized by the Verification Entity?

I'm not sure whether I understand the question here.

It's only the Tier1 registry which really has to check the validity
of a Token while processing a delegation request. If that check
goes though, the domain is delegated in a normal fashion. 

You have to separate the questions

* who is authorized to act as a VE? (i.e. whose Tokens will be trusted and
  accepted by the Registry?)

* how does the Registry makes sure that the Token it receive is authentic?

Both are local policy choices. In the case of Austria's +43 ENUM
production system, the answers are:

* Prospective VEs have to sign a contract with the Registry. The content
  of that contract derives from the NRA's contract with the Registry.

* The VE uses out-of-band mechanisms to send its X.509 Cert to the
  Registry. The Registry will then accept all Token signed with the
  corresponding key. 

> the number issuing hierarchy, for the identities being Verified?

Local policy choice. From a technical point of view, it's the Tier1
Registry which decides what to do. On the policy side, the Registry
always has to act within the framework set by the NRA. After all
the NRA is the one who decided (via the IETF/RIPE/ITU agreement) who
can run the Tier1 registry.

> authentication of the tokens conveying an Verification Entities 
> confirmation of the domain-name<->E.164 identity?

As this model does not in any way touch the delegation of country-code
ENUM domains from the Tier0, everything happens in the Tier1 space.

This draft only proposes how individual countries can structure the
local role model and provisioning protocols *within* that country's 
ENUM domain.

/ol

(NRA = National Regulatory Authority)
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 11 Oct 2005 07:05:52 -0700

>From: Otmar Lendl <[email-masked]>
>To: [email-masked]
>Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt
>Date: Tue, 11 Oct 2005 11:25:19 +0200
>
> >From my draft:
>

We tend to think of digital signatures as Ron Rivest first characterized 
them, for RSA: replacement for contract signing, where email text (or 
html/xml) plays the role of the piece of paper bearing the contract terms. 
Anyone can verify the signature, as such openness of usage is part of the 
signature function: acknowledge that real people having signed terms on 
paper, forming agreement ands contracts, so disputes are handled using 
normal social processes involving evidence and proof of signing intent.

In the case of RSA-based certs, DESMAC-based OCSP responses and other 
crypto-based signing technologies, which can implement Validation Tokens, we 
may or may not wish the signed token to be a "public" object, that anyone 
can verify as a proof of something having occured: e,g. validation of the 
E.164<->d-n identity.

The term "token" implied to me (given ISO uses this term carefully) that we 
were not intending the object to serve as a proof object (which assumes 
public proving processes), but - like an SSL signed token for client auth - 
its signature may be designed for only one party to consume, in the context 
of earlier protocol exchanges.

Ill read the architecture draft next. Whats in my mind is understanding the 
type of validation infrastructure that is being planned; and, whether there 
is any difference in the deployement models of the Validation Infrastrcuture 
for the User vs Carrier ENUM cases - given we now have the Carrier ENUM 
variant to address in the security model.

------

Some Thoughts:

In Carrier ENUM, we are dealing with largely closed systems, closed to 
create a system which satisfies high minimum levels of QoS via controlled 
peering, in which any security tokens used and shared amongst computers in a 
provider community (e.g. GSM) may be largely hidden from end users. All 
disputes within the telematic system involving ENUM will be handled using 
_regulated_ dispute arbitration, like any other PTT-based telco service. The 
notion of "reliance" on the Validation Token may be mute, as all reliance 
and its legal implications within the regulatory framework is defined by the 
regulator. Many of the legal and policy issues that surrounded certs and 
signatures in the e-commerce space may be irrelevant, as Carrier ENUM is 
intended to be a closed system - and a closed reliance system, at that.

In User ENUM, we have a different set of issues, where Validation Tokens may 
be called upon during a dispute to prove something - for one or other party 
to the dispute. If that argument is free form, and in open litigation, we 
have a token issuing and use/reliance environment similar to the world of 
e-commerce: which will require a different set of controls to limit the 
issuer's risks, and controls on who can and who cannot either use or rely 
upon the tokens for particular purposes.

Peter.

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 11 Oct 2005 16:53:29 +0200

On 2005/10/11 16:10, Peter Williams <[email-masked]> wrote:
> crypto-based signing technologies, which can implement Validation Tokens, 
> we may or may not wish the signed token to be a "public" object, that 
> anyone can verify as a proof of something having occured: e,g. validation 
> of the E.164<->d-n identity.
> 

My draft does not specify what which algorithm of XML DSIG MUST be used,
though it suggests RSA-SHA1.

So basically the openess of the Token can vary depeding on the crypto used:

* SHA-1 with a shared symmetrical key:
 
 	Only Registry and VE can validate the signature 

* RSA-SHA1 without a PKI infrastructure:

	Everybody can verify the correctness of the signature, but needs 
	external information on whether that signature should be
	trusted.

* RSA-SHA1 with a PKI

	If the Token is signed with a VE-key whose (included) cert is 
	signed by the NRA's CA-key, then no external info 
	(except that CA-cert) is needed to test and judge a Token.

Right now, we opted for the second option for User ENUM in Austria.

What other word would you use to describe our Tokens?

> is any difference in the deployement models of the Validation 
> Infrastrcuture for the User vs Carrier ENUM cases - given we now have the 
> Carrier ENUM variant to address in the security model.

We developed our validation model for the User ENUM case. 

As you note, Carrier ENUM has different requirements which may well
lead to a different solution.

/ol