smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (03/22/89)
The New York Times reported today that the Internet has decided to adopt RSA as the basis for an authentication scheme. This was done after appropriate negotiations with RSA, Inc., concerning licensing. Can someone post the details, both technical and administrative? (It's odd to learn something significant about the Internet from the mundane media...) --Steve Bellovin att!ulysses!smb, smb@ulysses.att.com
sean@ms.uky.edu (Sean Casey) (03/22/89)
Jim Bidzos of RSA Data Security told me that there should be an RFC out
by early April describing the implementation of the standard.
He outlined it to me, but I don't remember it that well. It mostly
concerns the transmission of DES keys for encrypted email by using the
RSA scheme.
As far as using the RSA scheme, they are pretty liberal about granting
no-cost licenses for noncommercial use. The trick is that anyone who
uses RSA must first register their personal key with them. It costs $25
for two years. They then encode their key in yours, and send it back.
Anyone who is granted a license for an RSA application program then has
to check any user's public key and verify that they are registered and
up to date. This is easily done by encrypting with RSA Corp's public
key. Out pops a string (I guess - he didn't say explicitly) and a date
code.
Thus it's likely that once you've registered a personal key, you can
use Internet RSA facilities at no additional cost for two years.
Hopefully, once the RFC is out, we'll have some heavy math types
writing a a really fast freely redistributable implementation.
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean
*** U of K, Lexington Kentucky, USA ..where Christian movies are banned.
*** ``You talk the talk. Do you walk the walk?''paul@kuhub.cc.ukans.edu (Craig Paul) (03/22/89)
> The New York Times reported today that the Internet has decided to > adopt RSA as the basis for an authentication scheme. This was done > after appropriate negotiations with RSA, Inc., concerning licensing. > Can someone post the details, both technical and administrative? > (It's odd to learn something significant about the Internet from the > mundane media...) Look up this reference.... From: KUHUB::PAUL "Craig Paul" 14-FEB-1989 15:06:04.87 To: PAUL,PAUL CC: Subj: Internet Endorses RSA E-mail. PC Week, 2/13/89, p. c/6
braden@VENERA.ISI.EDU (03/23/89)
The New York Times reported today that the Internet has decided to
adopt RSA as the basis for an authentication scheme. This was done
after appropriate negotiations with RSA, Inc., concerning licensing.
Can someone post the details, both technical and administrative?
(It's odd to learn something significant about the Internet from the
mundane media...)
--Steve Bellovin
att!ulysses!smb, smb@ulysses.att.com
Steve,
Yes, it certainly is odd. We (the IAB) are trying to improve the info
flow, but we obviously have a distance to go. The general info was
published in the Internet Monthly Report recently, but that is pretty
much limited to the research community. I appending that announcement.
The details will be covered in future (we hope not too distant future!)
RFC's being prepared by the Privace and Security Task Force, Steve Kent,
proprietor.
Bob Braden (for the IAB).
____________________________________________________
____________________________________________________
IAB REPORT -- February 1, 1989
This is the first of a series of reports on those decisions and actions taken
by the Internet Activities Board that should be of general interest to the
Internet community.
The following items are decisions made at the January 1989 meeting of the
IAB.
A. Private Mail
For several years, the Privacy&Security Task Force chaired by Steve
Kent of BBN has been developing a scheme to add privacy to SMTP-based
electronic mail. RFC's to be published soon will contain the final
details of the plan for encapsulating encrypted text within SMTP
messages (see RFC-1040 for an earlier draft) and the plan for key
distribution. This scheme will (optionally) provide data
confidentiality, origin authentication, per-message integrity, and
non-repudiation by the originator, and is based upon public-key
encryption using the RSA algorithm. Public keys will be bound to
individuals by means of "user certificates", which will be issued
by a private company, RSA Data Security Inc. The expected cost will
be $25 for a user certificate valid for two years.
The IAB reviewed this plan and gave the go-ahead to proceed with
implementation in the Internet. Not everyone needs private mail, of
course, but for those that do, this feature should allow Internet
email to take on a new importance.
B. The Worm Incident
The IAB joined others in the community in expressing its deep concern
about the recent Internet worm incident and the resulting public
reaction. The IAB released a policy statement that has been published
in RFC-1087, entitled "Ethics and the Internet."
The IAB plans to take future steps to make the gateway protocols more
secure against subversion and to improve the facilities for network
managers to selectively isolate pieces of the Internet should such
problems recur.
C. Draft Documents
The IAB believes that the Internet community is best served if there
continues to be only one archival series of documents, the RFC's. To
help prevent the erosion of this singularity, the IAB has decided that
the IDEA series of draft documents maintained by the IETF will be
replaced by a series of "Internet drafts". The new series is crafted
to minimize inappropriate citations and to ensure that these drafts
move forward into RFC's as quickly as possible. Details were
announced by Phill Gross, chair of the Internet Engineering Task
Force, at its January 1989 meeting.
D. IP Security Option
A vendor requested an IP Option for commercial security, where the
contents of this option would be unstandardized and vendor-specific.
The IAB felt strongly that IP options must be publically defined and
documented, while that proprietary or privately-structured options
are a bad idea. The IAB will initiate a broad-based effort to
define a (commercial) security option for IP. Interested parties
may contact Steve Kent (Kent@BBN.COM (617) 873 3988).
SAC.PRC@E.ISI.EDU (Steve Sidner) (03/23/89)
Bob, I found the IAB Monthly report informative, particular regarding mail security and the status of IDEAs. Is it possible to get on the distribution list for this report?
braden@VENERA.ISI.EDU (03/24/89)
Steve, There is no distribution list for the IAB report at present. It should be called a "bulletin", implying publication on an irregular basis as the need arises (after an IAB meeting, generally). We will distribute all future IAB reports/bulletins to the TCP-IP list. Bob Braden
dla@athena.mit.edu (Don Alvarez) (03/24/89)
The most important part of any public-key system is the key distribution
method. I can "break" any public key encryption scheme, no matter how
robust the algorithm, if you aren't sufficiently careful about distributing
the public keys.
Consider the case of secure communications between your workstation and a
file server which is located on another machine. Suppose that you have
never used this file server before (not a critical assumption, but it makes
the argument simpler). You call up some kind of directory service to get
the public key for that file server. Lets assume that it is a perfect
world, and that you are rightly confident that only one machine on the net
knows the private counterpart to that key, and also rightly confident that
the algorithm is unbreakable. You now enter into a communication with the
file server using the public key that the directory service has told you
belongs to the file server to get your private data. No other machine can
read what you and the file server say to each other, so you are "safe", right?
Wrong. All you know is that only one machine can read what you say. You
don't as yet have any way to know that you are really talking to *your* file
server. You don't even know that you are talking to a file server at all.
Suppose I got on the net and started masquerading as the directory service.
You say "what's the public key of FOOBAR fileserver?" My fraudulent directory
server intercepts the request and gives you a different public key. The private
counterpart to the public key you just received is known to a confederate of
mine. You send your request to (what you believe to be) the file server
encrypted in that public key, along with any info needed to authenticate
yourself to the file server. The confederate then calls the "real" directory
server, gets the "real" public key of the "real" file server, and passes the
request on to it.
The file server then calls the "directory service" to find *your* public key,
so that it can encrypt any files it needs to send to you. That request gets
intercepted too, and now the file server sends your data out encrypted in a
key which no one but my confederate can read. The confederate decrypts
whatever the real fileserver sends back, copies it, and then sends it on to
you reencrypted this time in your true private key.
Your communications have just been completely penetrated, and I never broke a
single code.
The info posted to this group has implied that keys need to be registered
with some central body. Presumably what happens is that the central body
encrypts your name into the public half of your key in some way when it is
created. Then whenever someone gives you a public key, you can run the
key through a black box and out will pop the name of the party registered
as owning the private component of the key. I would argue that if that is
what is done, it is probably not as effective a solution as I would have
liked (a large organization will probably end up with zillions of keys whose
owners have names like FOOBAR_INC:this_machine and FOOBAR_INC:that_machine.
If you don't know what machine your service resides on (suppose many machines
can offer the service, or something similar), I could misappropriate
any valid FOOBAR_INC key any publish it as the key for the other server I want
to penetrate). As I say, I don't know if that is how it works or not. If
it is, I'd argue that it is very much not the final solution, but it is at
least a decent starting point.
One thing I will say is that I am VERY heartened to discover that the
committee which picked this scheme is chaired by Stephen Kent. I've never
met him, but anybody interested in topics like this should DEFINITELY check
out the article he and Victor Voydock wrote in Computing Surveys, Vol. 15,
No. 2, June 1983 (Computing Surveys may be filed under Assoc. of Computing
Machinery in your library). The article is about forty pages long, readable
by the layman, and in my opinion is probably the best thing ever written on
the subject of network security. It's a survey article, and the title is
"Security Mechanisms in High-Level Network Protocols".
So, in short, I'd say that the most important technical question to be asked
is how do you know that you can trust the public key you are given. I don't
know the answer, but the presence of Mr. Kent's name on the committee makes
me think that there will probably be some good way to do so.
- Don Alvarez
+ ----------------------------------------------------------- +
| Don Alvarez MIT Center For Space Research |
| boomer@SPACE.MIT.EDU 77 Massachusetts Ave 37-618 |
| (617) 253-7457 Cambridge, MA 02139 |
+ ----------------------------------------------------------- +bernsten@phoenix.Princeton.EDU (Dan Bernstein) (03/28/89)
In article <10061@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: > The most important part of any public-key system is the key distribution > method. I can "break" any public key encryption scheme, no matter how > robust the algorithm, if you aren't sufficiently careful about distributing > the public keys. Your argument is mostly based on a fake directory service providing false encryption keys. As most discussions of public-key systems point out, the solution to this is easy. (See, e.g., volume 2 of Knuth.) Let's say X wants to send a message to Y. Given that unencrypted data and encrypted data come from the same alphabet, X *decrypts* a message by his encryption function, signs it, encrypts it by Y's function, and sends it to Y. Y then receives it, decrypts it by Y, checks the signature to find out X's identity, and then *encrypts* it by X. X can be confident that only Y can read the message since only Y knows Y's decryption function. Y can be confident that only X could have sent the message since only X knows X's decryption function---otherwise the final message would be garbage. Thus public-key systems (with the same set of unencrypted and encrypted data) naturally provide sender authentication as well as privacy. How does this apply to the directory service D? There is only a single encryption function, ED, that must be distributed widely. This single key becomes common, public knowledge; the average sysadmin will know the number by heart. Assuming only that this single key can be distributed safely at the beginning of time, the directory can then send out *signed* messages containing further keys. (The messages should contain recognizable format information, or at least a few checksums, to prevent complete screwups.) Of course, that encryption function will become the world's most carefully scrutinized. If someone could find out the directory's decryption, they could indeed begin masquerading as the directory, thus posing the security risks you bring up. Thus that directory encryption function must be chosen very carefully---if RSA, it should probably be several hundred digits long where three hundred is usually considered safe, and should probably involve quadruple application of the key choice method in Knuth rather than double. The decryption must also be protected very carefully, with a paranoia previously unheard of. > The info posted to this group has implied that keys need to be registered > with some central body. Presumably what happens is that the central body > encrypts your name into the public half of your key in some way when it is > created. Why? This seems to me to imply an unnecessary security risk. You want a mapping from user to key, not from key to user. The latter wouldn't prevent any security problems; if you claim a key is yours, it can be checked with the directory service, and I don't think there would be any reason that ``we have to find out who owns this key!'' > So, in short, I'd say that the most important technical question to be asked > is how do you know that you can trust the public key you are given. This reduces to the question of how secure we can make a carefully chosen single example of a single encryption method: the directory's encryption function. ---Dan Bernstein, bernsten@phoenix.princeton.edu
rsalz@bbn.com (Rich Salz) (03/28/89)
The shortest way to ask this question is to be somewhat flip about it, but I don't mean to be -- it's something I really would like to know: What steps are being taken to ensure that the one group that holds the keys to secure Internet mail won't be selling them to the Russians? Reply to me, I'll summarize. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
dla@athena.mit.edu (Don Alvarez) (03/29/89)
In article <7432@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU (Dan Bernstein) writes: >In article <10061@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: >Let's say X wants to send a message to Y. [...] X [uses his private key >to encrypt a message], signs it, encrypts it by Y's public function, and >sends it to Y. Y then receives it, decrypts it by Y[-private], checks the >signature to find out X's identity, and then [decrypts the message using >X's public key]. > >X can be confident that only Y can read the message since only Y knows >Y's decryption function. Y can be confident that only X could have sent >the message _since_only_X_knows_X's_decryption_function_ ---otherwise the >final message would be garbage. Thus public-key systems [...] provide sender >authentication as well as privacy. > (emphasis added) It is true that only X knows X's decryption function, but only X and the public key directory know X's PUBLIC key for certain. Everyone else has to look up the public key in the directory service. >How does this apply to the directory service D? There is only a single >encryption function, ED, that must be distributed widely. This single >key becomes common, public knowledge; [...] the directory service can then >send out *signed* messages containing further keys. I agree that if you only have one single directory service you can handle things as you suggest. On a network the size of the internet, with 10^5 or so people and many more companies, organizations, services, etc., each needing their own keys, no one machine could possibly handle all the traffic needed to dispense all the keys for everyones mailer and fileserver even if keys have extended lifespans and caching is allowed. You would kill the network with the volume of packets needed to handle the requests. Directory services need to be local and hierarchical, exactly the way nameservers work on the net today. That means if you want one single directory service key, you have to give the private part to every nameserver manager everywhere in the country. Guess how long that will stay secret. You can't give different local nameservers different keys without losing the generality of your single key. Also, consider what happens if somebody *leaks* your single key. Every operating system on every computer on the net has to be recompiled for the new server key. You can *perhaps* assume that there is a single directory service for looking up local directory services, as in "who is the directory server for .FOOU.EDU", but I'll bet even that traffic will kill the net, and you still run into the problem of how do you change that single password without bringing the entire net to a grinding halt. >> So, in short, I'd say that the most important technical question to be asked >> is how do you know that you can trust the public key you are given. > >This reduces to the question of how secure we can make a carefully >chosen single example of a single encryption method: the directory's >encryption function. Nope, you can't do it with just one directory server. You still need something additional to provide trustability of the public key someone hands you, and that something can not be just a simple public-key-signed handshake, because any such handshake assumes you already know the other guys' key. There is no point in worrying about security of encryption algorithms until you can solve the distribution problem. >>--Don Alvarez, boomer@space.mit.edu >---Dan Bernstein, bernsten@phoenix.princeton.edu ----Don Alvarez, boomer@space.mit.edu
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (03/30/89)
In article <10159@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: > >Nope, you can't do it with just one directory server. You still need >something additional to provide trustability of the public key someone >hands you, and that something can not be just a simple >public-key-signed handshake, because any such handshake assumes you >already know the other guys' key. There is no point in worrying about >security of encryption algorithms until you can solve the distribution >problem. > >----Don Alvarez, boomer@space.mit.edu I'm not an expert on Kerberos, but I have been reading up on it and it seems to me that it addresses this particular problem. Kerberos uses DES keys, but conceptually I think that this model could be used with RSA algorithms. You first have to authenticate yourself to Kerberos by sending your username to a Kerberos authentication server. This creates a "ticket" [Kerberos terminology] that is encrypted so the user cannot alter it. This ticket is used by the user to gain further tickets from the ticket-granting server (step two). This ticket and some other information is further encrypted with a key derived from your password. This is sent back to the user. The user then enters his password into the workstation and a decryption key is derived and the ticket-granting-server ticket is produced. Further transactions are conducted without user intervention or re-entering of password with the ticket-granting server for session keys for use of networks services. There are time-outs on session keys and the ticket-granting-server ticket to limit exposure. The user password is only required in the system for the time it takes to decrypt the authentication response. I think this addresses most of the issues that have been raised in this thread. Following all these Kerberos tickets around can give you brain-pain, but everything is transparent to the user. In fact, you only login to Kerberos, not every machine on the net, so user perception of service is improved over rlogin w/o .rhosts. Kerberos can be used only for authenticating the start of a connection, like Athena uses for Kerberos NFS, or it can be used to authenticate every message, or it can be used to encrypt messages. You choose your level of security and performance hit. Neat stuff in other words.
ggm@brolga.cc.uq.oz (George Michaelson) (04/06/89)
> The shortest way to ask this question is to be somewhat flip about > it, but I don't mean to be -- it's something I really would like to > know: > What steps are being taken to ensure that the one group > that holds the keys to secure Internet mail won't be > selling them to the Russians? as a tangential question, What steps are being taken to ensure the USA governmental agencies don't restrict access to this facility and prevent non-US access? if you institute secure SMTP and don't let the rest of the world use it you can kiss goodbye to a lot of connectivity. note#1: the above question posits the *holders* of the keying info selling it to <bad-guy> I'm positing the *providers* of keying info not being allowed to distribute keys to <non-USA-guy> which is not the same thing. note#2: couldn't you have chosen a better <bad-guy>? If the russians want to read my e-mail, they'll have to join the queue behind the NSA, GCHQ, and my mother. -Come to think of it, GCHQ will probably be *selling* the keys to the highest bidder if Maggie privatizes them... avanti popolo! -george -- ACSnet: ggm@brolga.cc.uq.oz Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre Queensland University, St Lucia, QLD 4067