About site: Internet/RFCs/0601 - 0700 - RFC 0644
Return to Computers also Computers
  About site: http://www.faqs.org/rfcs/rfc644.html

Title: Internet/RFCs/0601 - 0700 - RFC 0644 On the Problem of Signature Authentication for Network Mail. R. Thomas. July 1974.
Introduction_to_Genetic_Algorithms_with_Java Introductory pages with interactive Java applets, useful tips for your own genetic algorithm

Boldata_Systems Offers custom configuration of personal computers, notebooks and servers.

CPAN The Comprehensive Perl Archive Network, the gateway to all things Perl. The canonical location for Perl code and modules.

The_GradeNetwork [Web-based] A program which enables instructors to manage their class grades and provides students with capabilities to follow their progress.

DotDigital Domain registration, hosting, web design, e-commerce, search engine submissions, and online reservation software.

Cascading_Style_Sheets_Alive Features a free Windows self-extracting demo and tutorial demonstrating the benefits of Cascading Style Sheets techniques.

  Alexa statistic for http://www.faqs.org/rfcs/rfc644.html





Get your Google PageRank






Please visit: http://www.faqs.org/rfcs/rfc644.html
  Related sites for http://www.faqs.org/rfcs/rfc644.html
    Network_Protection_Monitor Network protection monitoring is provided in Sessionwall by integrating network usage reporting with network security including content scanning.
    SGML_and_XML_News Short articles on new projects and current issues with relevant links to the originating sites.
    MacTalent_com Worldwide database of Macintosh talent. People of all disciplines seeking contract, part-time and full-time assignments.
    Optical_Mark_Readers_in_Hong_Kong Optical Mark Reader - data of yourselves, by yourselves and from yourselves. OMA optical mark readers are being used in over 30 secondary schools in Hong Kong.
    Active@_Kill_Disk Secure data eraser for hard and floppy drives.
    Cresotech_Photoscreen Build a screensaver in a few seconds by pointing images to the program and then press the build button. Program will generate a screensaver with 150 different image transition effects. [Win 95/98/NT/2
    Indian_Registry Site offers domain name registration, transfer, but does not offer credit card ordering.
    NotationMachine Sheet music software to search and create your own sheet music from MIDI files.
    RFC_0879 TCP Maximum Segment Size and Related Topics. J. Postel. November 1983.
    RFC_1134 Point-to-Point Protocol: a Proposal for Multi-Protocol Transmission of Datagrams over Point-to-Point Links. D. Perkins. November 1989.
    Programming_Class A series of interactive programming tutorials for beginners, focusing on C++, Java, and C#.
    Knife Mail and news client, with support for SMTP, IMAP, POP3, Unix Mailbox, and NNTP. [Open Source, GPL]
    TVstats_com Internet solutions for Television stations, including database-driven and dynamic web content.
    Nagi,_Aatif Offers design, graphics, and flash services.
    Optimizing_Away_C++_Exception_Handling Describes an optimization that produces modest but useful gains on some existing C++ code, but produces very significant size and speed gains on code that uses empty exception specifications, avoiding
    Simulating_Polymorphic_Operators_in_C++ Presents three different techniques for making operators polymorphic. (July 2, 2007)
    Virtually_Canadian Offering design, hosting and promotion. Locations include: Vancouver, British Columbia, Montreal, Quebec. and Herne, Germany.
    Windy\'s_Design_Studio Provides web design, logo design, search engine placement.
    AlphaSelect_2000 Specialise in website creation, maintenance, design and programming services for independent businesses.
    IPv6_Links Has many links to IPv6 resources. Some resources are in German.
This is websites2007.org cache of m/ as retrieved on 2008.08.28 websites2007.org's cache is the snapshot that we took of the page as we crawled the web. The page may have changed since that time.
RFC 644 (rfc644) - On the problem of signature authentication for network@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc644.txt | rfc644.txt.pdfRFC 644 - On the problem of signature authentication for network mailSearch the Archives Display RFC by number     

RFC644 - On the problem of signature authentication for network

Network Working Group Bob ThomasRequest for Comments: 644 BBN-TENEX Jul 1974 On the Problem of Signature Authentication for Network MailThis note describes the problem of signature authentication for networkmail, presents a general approach to the problem and proposes a specific implementation of that approach.1. The Problem The problem we wish to consider is: How can the recipient of a network mail message be "certain" that the signature (e.g., the name in the "FROM" field) is authentic; that is, that the message is really from whom it claims to be?We are interested in the problem of signature authenticity in the networkcontext. For purposes of this note we shall assume a solution to thesignature authentication problem for local mail (i.e., messages from oneuser to another within a single host). That is, we assume that for anyhost, either the host regards the problem as important and has a mechanismfor guaranteeing signatures on local mail or that the host does not regard theproblem as important and does not guarantee signature authentication. Itshould become clear how this assumption relates to our approach to the networksignature problem.We shall discuss our approach using the following simple model for networkmail: To send net mail a user invokes a mail sending process (SP) on his local host (SH). The process SP acts on behalf of the user to deliver the message to an appropriate mailbox at the receiving host (RH). It does that by interacting with a receiving process (RP) that runs on host RH. RP accepts the message from SP and deposits it in the appropriate mailbox.In the current implementation of network mail, the receiving process RP is typically an FTP server process. For the current TENEX implementation the mail sending process SP is either a process running SNDMSG or a "background" MAILER process which sends "queued" (previously posted but undelivered) mail.2. An ApproachWe seek a solution which will allow RP, the receiving process, to markthe signature on messages it receives as authenticated or not withrespect to SH, the sending host. If RP can so mark incoming messages,a user reading his mail at RH would be able to see the signature on eachmessage as authenticated or not with respect to the host of origin. Theauthenticity of the signature on a piece of mail is understood to be responsibility of the originating host. The credibility a user gives aparticular message which is marked as authentic can be based on the user'sown estimate of the source host's user authentication and access controlmechanisms. -1- The success of this approach depends upon two things: a. Users develop estimates of the security of various host user authentication and access control mechanisms. We have seen that users who are concerned about data privacy and security are already doing this within the ARPANET. b. The existence of a mechanism which RP, the receiving process, can use to distinguish mail authenticated with respect to the sending host from mail that has not been authenticated by the sending host. That is, a mechanism is required which will allow a properly authorized (by the sending host) mail sending process to identify itself as such to the mail receiving process. The receiving process can then mark mail from such an authenticated process as authentic. Nonauthorized processes (e.g., a user process attempting to pose as an authorized mail sending process) may try to send mail to mailboxes at RH; in such a case the receiving process has the option of refusing to accept the message or accepting them marking them as unauthenticated.3. Proposed Implementation of ApproachThe use of passwords is one possible way to accomplish sending processauthentication. Only an authorized sending process would know the passwordand thus be able to properly identify itself to a mail receiving process.We reject the password mechanism as operationally impractical for the followingreasons: a. Use of a password requires that the password be stored in the sending program or be accessible to it in some way thereby increasing the likelihood that the privacy of such a password will be compromised. b. If a password is compromised, it must be changed at both sending and receiving hosts; a synchronization problem. c. Truly secure mail would probably require passwords for each pair of hosts; this requires N*N passwords for an N host network.As an alternative to the use of passwords as a means for processauthentication, we propose that authentication be based on thecommunication path itself between the sending and receiving process.In the ARPANET, a communication path is uniquely identified by its twoends: the send host-socket pair and the receive host-socket pair. Aprocess can accurately determine the host-socket pair at the remote endof a communication path. We propose that the receiving processconsider the sending process to be a properly authorized (by thesending host) sender of mail only if the sending end of thecommunication path is (one of) the socket(s) reserved for transmissionof authenticated mail. The mail sending socket(s) would be reservedby prior host agreement. -2- The responsibility of the sending host is to allow only authorizedmail sending processes to access the mail sending socket(s). Theresponsibility of the user concerned about the authenticity of hismail is to understand that mail marked as authentic means that thesending host has determined the identity of the sender and that thesignature on such mail is only as good or bad as the user authenticationand access control procedures of the sending host.4. Additional Remarks a. The use of sockets for process authentication is not a new concept within the ARPANET. By host agreement, the TELNET logger process responds to connections to socket #1, the FTP logger process to socket #3, etc. In fact, the privacy of net mail depends upon how well the host controls access to the FTP logger socket; that is, the authenticity of the mail receiving process is based upon that fact that it is the process reached by ICP'ing to socket #3. This note proposes that the same mechanism be used to provide authentication of mail sending processes. b. Planned TENEX Experiment A set of sockets has been assigned for mail transmission. They are (all numbers are decimal) ICP "from" socket - 232 FTP user command sockets: receive, send = 234, 235 Default data transfer (user, send) socket = 237 We intend to modify the TENEX mail sending, receiving and reading software as suggested above. Mail sent by TENEX to remote hosts which is authentic (with respect to TENEX) will be sent by initiating the ICP to the remote FTP server socket 232. Mail received from remote hosts will be marked as authentic only if the ICP to the TENEX FTP server was initiated from remote socket 232. The TENEX mail reading software will indicate for each message whether or not the signature on the message was source authenticated. c. Contention for the Mail Sending Socket Depending upon the implementation of the sending host's NCP and its mail net sending software, it may be the case that several users concurrently sending network mail may be competing for the single ICP "from" socket. If socket contention turns out to be a serious problem in practice, a set of ICP "from" sockets could be reserved for authenticated network mail. d. The local mail signature authentication problem is nearly independent of the network mail signature authentication problem as we have discussed it. For example, the following observations can be made: -3- 1. The local users of a host which does not authenticate local mail probably should not expect the host to reliably deliver authenticated network mail to them. Because local mail is not authenticated, it is likely that a malicious local user could add to other users' mail boxes forged messages which are formatted identically to net mail and are marked as authentic in the way the host's mail receiving process marks mail. 2. A host that has strong user authentication procedures and authenticates local mail is not necessarily a reliable source of authenticated network mail. In order to be a reliable source, it must limit access to the net mail transmission socket(s) to authorized mail sending processes. 3. A host which does not support local authentic mail could be a reliable source of authentic net mail. -4- Previous: RFC 0643 - Network Debugging Protocol Next: RFC 0651 - Revised Telnet status option [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. 
 

On

the

Problem

of

Signature

Authentication

for

Network

Mail.

R.

Thomas.

July

1974.

http://www.faqs.org/rfcs/rfc644.html

RFC 0644 2008 August

dvd rental

dvd


On the Problem of Signature Authentication for Network Mail. R. Thomas. July 1974.

Rules

© 2008 Internet Explorer 5+ or Netscape 6+
Recommended Sites: 1. Arts - Business - Computers - Games - Health - Home - Kids and Teens - News - Recreation - Reference - Regional - Science - Shopping - Society - Sports - World Miss Gallery - Top Anime Hentai - DVD rental by mail - Mobile Phones - Bad Credit Mortgages - Gift Ideas - Loans - Homeowner Loans
2008-08-28 12:35:39

Copyright 2005, 2006 by Webmaster
Websites is cool :) 216Bursztyn Pierscionki Gold - Albergo Lisbona - Hotel Hamburg - Hotel Frankfurt - Albergo Milano