[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thread 1: Sharing
- Date: Thu, 26 Dec 1996 01:59:01 +0000
- From: Jeff Williams <jwkckid1@ix.netcom.com>
- Subject: Re: Thread 1: Sharing
Kent,
It will depend on the Master Key size you are planning to use with
PGP. If it is smaller than 56bit, it is very vunderable. If it is
larger than 56bit, it violates NSA requirnments. 40bit, now most
commonly used, has been broken by Man-in-the-middle attacks many times.
I have done so myself for some US gov. agencies as refrence info.
The 40bit master key can be broken in 2 seconds elapsed cpu time.
I did it with a low end laptop, for instance. There are other
various problems with PGP as well. The encryption algorythems
do not allow for shared Master Keys for instance, etc, etc...
Regards,
Kent Crispin wrote:
>
> Jeff Williams allegedly said:
> >
> [...]
> > > -- it is not a database itself. It uses PGP to supply authentication
> > > because PGP is widely and freely available worldwide.
> >
> > I am a bit concerned with PGP as the security authentication. It is
> > susceptable to "man-in-the-middle" attacks.
>
> Could you please elucidate -- I don't think that could happen, at
> least not in this application.
>
> > I have a protocol
> > interface which will encompas several security protocols for this
> > situation.
>
> I would be interested in seeing more details.
>
> > I could make this avalible. Some registrars are going
> > to have problems with PGP.
>
> I'm not sure why you say this. PGP is the most widely distributed
> authentication product available. It is essentially the only one
> that is available world-wide, and world-wide availability is a prime consideration.
>
> > > SRP is intended to be a public standard by which registrars can
> > > communicate. It does not dictate any particular database
> > > technology. Because it is so simple, it is very easy to extend or
> > > modify it to suit different environments.
> >
> > I would love to see this in more detail. BUt it sounds great!
>
> I am enclosing the draft I submitted to iahc:
>
> ===========================================================================
>
> INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT
>
> STLD Working Group K. Crispin
> Category: Informational November 1996
>
> Simple Protocol Supporting Shared TLDomain Registrars
>
> <draft-iahc-stldsup-crispin-00.txt>
>
> Status of this Memo
>
> This document is a submission to the Internet Ad Hoc Committee.
>
> This document is an Internet-Draft. Internet Drafts are working
> documents of the Internet Engineering Task Force (IETF), its
> Areas, and its Working Groups. Note that other groups may also
> distribute working documents as Internet Drafts.
>
> Internet Drafts are draft documents valid for a maximum of six
> months. Internet Drafts may be updated, replaced, or obsoleted by
> other documents at any time. It is not appropriate to use
> Internet Drafts as reference material or to cite them other than
> as a "working draft" or "work in progress."
>
> To learn the current status of any internet-draft, please check
> the "1id-abstracts.txt" listing contained in the internet-drafts
> Shadow Directories on:
>
> ftp.is.co.za (Africa)
> nic.nordu.net (Europe)
> ds.internic.net (US East Coast)
> ftp.isi.edu (US West Coast)
> munnari.oz.au (Pacific Rim)
>
> Abstract
> --------
>
> This Internet-Draft describes a simple, effective protocol
> supporting Shared Top-Level Domain Registrars called the Simple
> Registrar Protocol (SRP). The protocol provides a high level of
> authentication between mutually suspicious registrars, and a
> robust, fail-safe design. The protocol is partially implemented,
> and a version suitable for testing should be available by
> mid-January.
>
> The primary purposes of the protocol are 1) to provide secure and
> authenticated communication between registrars and a central
> Trusted Third Party, and 2) provide impartial FCFS allocation of
> domain names.
>
> The protocol and it's implementation are neutral as far as use of
> separate databases is concerned. As implemented, the only
> database used is DNS itself, but it is indeed trivial to add
> support for updating another database. In particular, there is
> no support for centralizing whois data, though such support is
> trivial to add.
>
> Introduction
> ------------
>
> A registry with multiple registrars must contain at its heart a
> synchronization method to handle the problem of two registrars
> trying to register the same domain name at the same time. Though
> in practice such collisions should be extremely rare, the debris
> left over could be complicated to clean up. Therefore, it is
> worth expending a little effort to guard against them.
>
> The situation is complicated somewhat by the fact that in many if
> not all cases the registrars are mutually suspicious competing
> business entities. Therefore, strong authentication and trusted
> channels are required. Also important in a business context is
> support for non-repudiation.
>
> Another important factor that must be dealt with in the insecure
> internet is that vandals can attack or spoof the registry. Thus
> the dispersed registrars must have some secure and reliable means
> of authenticating themselves and their requests.
>
> The authentication in SRP is based on PGP, which is available
> worldwide. The underlying SRP data structure is an SRP
> certificate, which is composed of RFC822-like fields. In order to
> be useful, the certificates are signed with PGP. Note that PGP is
> only used for authenticating signatures, and not encryption, and
> thus this protocol can be used by registries distributed
> throughout the world.
>
> The fundamental architecture has two primary components -- a SRP
> client and a SRP master. The SRP master is trusted to be
> impartial, and is run by a Trusted Third Party. All transactions
> between the client and the master involve PGP signed SRP
> certificates, and transactions result in signed receipts or
> results that leave a trail that makes any attempt at cheating
> perfectly visible.
>
> Assumed Technical Environment
> -----------------------------
>
> It is assumed that there is a group of registrars that comprise a
> registry for a gTLD. Each of the registrars is assumed to run a
> nameserver for the gTLD. One of the registrars, chosen by lot,
> runs the primary nameserver, the others run secondary nameservers.
> All the registrars run the SRP client. One distinguished entity
> (the Master) runs the SRP master service.
>
> Logically, each registrar runs a nameserver with the entire gTLD
> zone. But if there are a great many registrars for the gTLD some
> subcontracting arrangements may be worked out such that one
> nameserver serves for more than one registrar. However, such
> arrangements are orthogonal to this proposal.
>
> It is assumed that each registrar keeps a Customer Database, and
> that each registrar provides a whois-compatible interface to this
> data. That is, the whois data for the registry is segmented
> across the registrars in disjoint sets. In DNS each SLD in the
> gTLD has three TXT records specifying 1) domain name of the whois
> server that contains contact data for that SLD, 2) the email contact
> for the registrar currently responsible for the SLD, and 3)
> the PGP key footprint of the public key of that registrar.
>
> Note that this model does not preclude maintaining whois data for
> the entire gTLD in a central database, possibly co-located with
> the SRP master server, but it does not require it, either.
>
> Note that a registrar is said to "represent" a SLD, for a
> customer. Sometimes the registrar that represents a SLD is is
> referred to as the "owner" of the SLD. This is merely a
> convenient colloquialism -- "ownership" of a SLD is, strictly
> speaking, undefined. What is defined is a series of rights and
> responsibilities within the various contracts that exist between
> registrars, any overseeing authority, and end customers.
>
> SRP Certificates
> ----------------
>
> SRP Certificates are either 1) a set of RFC-822 format records, 2)
> a SRP Certificate signed by PGP, or 3) a combination of 1 and 2.
> Only Certificates in format 2 are communicated, but formats 1 and
> 3 occur during processing. Notice that the definition is
> recursive. The client, and master ignore fields that they
> don't use. Thus, addition of new fields is trivial.
> Furthermore, the fields can be parsed out of signed
> certificates.
>
> Here is an example of a certificate in format 1. It is an abbreviated
> example of a RESERVE request:
>
> request: RESERVE
> tld: com
> dom: test
> contact_id: kc125
> client: songbird.com
> notary: songbird.com
> notary-port: 5555
> master: songbird.com
> master-port: 5556
>
> Here is an example of a certificate in format 2 -- it is a
> certificate signed by the client, in preparation for transmission
> to the master.
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> request: RESERVE
> tld: com
> dom: test
> contact_id: kc125
> client: songbird.com
> notary: songbird.com
> notary-port: 5555
> master: songbird.com
> master-port: 5556
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQBVAwUBMrgoX/TO/sqmpV8tAQEHcAH/Y+Smxd8O/Z0Bp3CK2UUrDsCmpVMgHZ//
> LJzad71JcEU5mhCI+3i7S1oYZvZVH01r8TCOWaA9K8XCgXCcTogDsw==
> =VhAh
> -----END PGP SIGNATURE-----
>
> SRP Requests
> ------------
>
> Following is a list of explicit functions supported. The name of
> the function follows in the "request:" field in a certificate.
> Items in angle brackets indicate further distinguished fields in
> the certificate that are used as parameters to the function.
> Items in square brackets indicate data not yet fully specified.
> Thus, the example notarized certificate above would be further
> signed by the client and sent to the master to reserve the domain
> "test.com". Note that some parameters, such as <client>, are
> implicit to all functions.
>
> The functions supported are as follows:
>
> RESERVE <dom>, <tld>: If <dom> already exists in the zone of
> <tld> in DNS, or has already been reserved, RESERVE returns
> failure. Otherwise it reserves the name for approximately
> MAX_RESERVATION_TIME, and sends back a certificate signed by
> the master to this effect. After MAX_RESERVATION_TIME
> elapses, the reservation is forgotten.
>
> Reservations are kept by the master on stable storage, and
> each registrar has a signed certificate verifying their
> reservation. Thus, in the event of catastrophic failure of
> the master the data can be completely rebuilt, either [easily]
> from current backups, or [with difficulty], by requesting that
> all registrars send in copies of their pending signed
> reservation certificates. A third alternative would be to
> declare all reservations invalid upon a crash. There are
> tradeoffs for all these approaches.
>
> CONFIRM <dom>, <tld>, [other DNS data]: If the registrar
> sending the CONFIRM request has a pending reservation for
> <dom> in <tld>, the reservation is "confirmed", and the
> associated [DNS data] is bundled into a DNS zone update
> record, which is used to update DNS. A signed certificate
> indicating this is sent back to the client. If all conditions
> are not met, a signed certificate is sent back to the client
> with some indication of the reason for the failure.
>
> CLEAR_RESERVATION <dom>,<tld>: removes a reservation, if one
> exists. Of course, only the owner of the reservation may
> CLEAR it.
>
> MODIFY <dom>, <tld>, [DNS data]: Generates a zone update
> record for the domain, and updates DNS. Only the registrar
> that currently represents the domain may MODIFY the DNS
> information in the zone.
>
> DELETE <dom>, <tld>: Generated a zone update record that
> deletes the domain and all associated information, and updates
> DNS. Only the registrar that currently represents the domain
> can DELETE it from the zone.
>
> TRANSFER <dom>,<tld>, [DNS data]: This is a request to
> transfer representation of the domain from one registrar [the
> "old" registrar] to another [the "new" registrar]. The
> TRANSFER request is first signed by the new registrar, then
> signed by the old registrar, and sent to the master. The
> master verifies the signatures, and generates zone update
> records for DNS to reflect the change.
>
> A transfer from one registrar to another is in total a fairly
> complex process, and involves more than merely updating the
> DNS information. It requires the involvement of both
> registrars -- the new registrar needs to accept the
> responsibility for representing the domain, set up billing and
> other business minutiae, and so on. The old registrar needs to
> update its business records, clear accounts, etc -- the
> customer may, for example, have an unpaid balance with the old
> registrar that must be cleared before the transfer takes
> place. Thus, a transfer is an operation that requires a
> certain amount of human intervention, and most of the work
> must be handled outside the scope of the SRP.
>
> At the new registrar the SRP client will generate a signed
> certificate for the new registrar, which may be emailed to the
> old registrar. The client at the old registrar will take the
> signed certificate from the new registrar as input, sign it,
> and send it to the master.
>
> The reason for the existence of the TRANSFER function is, of
> course, to allow a transfer without interruption of DNS
> service.
>
> The Master
> ----------
>
> The master receives certificates from a client, and verifies the
> clients signature. If the signature is OK, the master looks at
> the "request:" field in the certificate. Depending on the value
> of that field, the master will perhaps further process the
> certificate, perhaps change its local stable storage state,
> perhaps query DNS, and perhaps modify the zone files for DNS. The
> master guarantees, within limits, first-come-first-served
> semantics between registries desiring to add the same named
> second-level-domain, and several other functions for coordinating
> shared registries.
>
> The master keeps local state on stable storage to remember
> reservations for a fixed period of time (the lifetime of the
> reservation), and to remember pending DNS (and possibly other
> database) updates. But the master does not itself keep a
> database. DNS is the authoritative record of what names are in
> the zone. In other words, the master acts as a caching front end
> to other databases, specially designed to facilitate registrar
> operations.
>
> The Client
> ----------
>
> In most cases the SRP client collects the data necessary for one
> of the of the SRP requests, generates a certificate with that
> data, signs it, sends it to the master for action, receives a
> reply, and saves the reply certificate. This straightforward
> client-server relationship covers all the requests except the
> TRANSFER request. For the TRANSFER request the new registrar is
> contacted by customer who "owns" the domain name. The new
> registrar verifies the identity of this owner by means not
> described here, and runs the SRP client to generate a TRANSFER
> certificate. This certificate is signed by the client, and
> saved locally in a file. This file is transported to the old
> registrar by some means. The old registrar takes whatever
> measures necessary to guarantee the request is a valid one, and
> that the business relationship with the customer is clear, then
> runs the client to complete the transfer. The client takes the
> new-registrar signed transfer certificate, signs it with the old
> registrars key, and sends the request to the master.
>
> Key Management
> --------------
>
> All registrars and the Master have unique PGP key pairs, and each
> of these must have the public key of every other. Distribution
> of keys would seem, therefore, to be an n-squared problem.
> However, two factors mitigate this: first of all, most changes
> in the key set are incremental; and second, the master is in a
> distinguished, trusted position, and therefore can act as a
> key distribution center for the registry. The master has to know
> all the registrar public keys, and each registrar has to know the
> masters public key, and then the master's public key ring can be
> mailed securely to each of the registrars.
>
> Implementation
> --------------
>
> A C language implementation of the client and master will be
> available shortly. The client is a stand-alone utility program;
> the master is a daemon that runs under inetd. Included in the
> implementation is a DNS Update Daemon (DUD -- have at it boys :-)
> that allows secure update of DNS at a remote site. [Secure DNS
> Dynamic Update can be used instead, as soon as it is available.
> The code for DUD also serves a model for a daemon that securely
> updates any database.]
>
>
> Author's Address
> ----------------
>
> Kent Crispin L-61
> Lawrence Livermore National Laboratory
> PO Box 808
> Livermore, CA 94550
>
> kc@llnl.gov
> kent@songbird.com
>
> +1 510 422 4273
>
> --
> Kent Crispin "No reason to get excited",
> kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
> PGP fingerprint: 5A 16 DA 04 31 33 40 1E 87 DA 29 02 97 A3 46 2F
--
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group.
Phone :972-447-1878
E-Mail jwkckid1@ix.netcom.com