[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
PGPticket                                             Vinnie Moscaritolo
INTERNET-DRAFT                                      Apple Computer Corp.
Expires: 14-Jan-1999                                   Antonino N. Mione
                                     Rutgers University Network Services


                               PGPticket
            <draft-ietf-pgpticket-moscaritolo-mione-00.txt>


Status of this Memo

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "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 ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   OpenPGP specifies message formats and certificate formats used for
   exchange of encrypted and/or authenticated objects. This document
   discusses methods of extending OpenPGP's message formats to support
   an authorization system. This system would use public key
   cryptography to authenticate a user to a server and establish the
   user's access permissions. The concept is that the user acquires a
   ticket signed by some issuer that specifies what they are entitled to
   do. That ticket is then submitted to a server. The server uses a
   challenge/response method to verify that the holder really has the
   matching private key. The server then allows the access specified.

















Moscaritolo, Mione                                              [Page 1]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

Table of Contents

      Status of This Document....................................1
      Abstract...................................................1

      Table of Contents..........................................2

      1.  Introduction...........................................3
      1.1  Target Audience.......................................3
      1.2   Purpose and Motivation...............................3
      1.3   Related Formats and Protocols........................3
      1.4   Attribute Certificates...............................4
      2.  Security Considerations................................4
      2.1   Public Key Cryptography Limitations..................4
      2.1.1   Public Key Exchange and Key Trust..................4
      2.1.2   Key ID vs. FingerPrint.............................5
      2.2   Expiration Dates.....................................5
      2.3   Security Risks When Signing a Challenge..............5
      3.  Protocol Description...................................6
      3.1   PGPticket Format.....................................6
      3.1.1   Overview of Ticket Structure.......................6
      3.2   PGPticket Field Descriptions.........................7
      3.2.1   Packet Tag.........................................7
      3.2.2   Hashed Subpacket Length............................7
      3.2.3   Certificate Validity Information [Part 1]..........8
      3.2.4   Certificate Issuer Information.....................8
      3.2.5   Certificate Validity Information [Part 2]..........8
      3.2.6   Certificate Authorization Information..............8
      3.2.7   Certificate Subject Information....................8
      3.2.8   Unhashed Subpacket Length..........................9
      3.2.9   Signature Verification Check.......................9
      3.2.10  Signature..........................................9
      3.3   RADIX-64 Encoded PGPticket...........................9
      3.4   Ticket Acquisition..................................10
      3.4.1   Out-of-band.......................................10
      3.4.2   Possible Inband Ticket Requests...................10
      3.5   Ticket Use..........................................10
      3.5.1   Ticket Presentation...............................11
      3.5.2   Ticket Verification...............................11
      3.5.3   Issue of the Challenge............................11
      3.5.4   The Response......................................11
      3.5.5   Acceptance........................................12
      3.5.6   Rejection.........................................12
      4.   Examples.............................................13
      4.1   Remote Login........................................13
      4.2   Non-anonymous FTP with no remote account............13
      5.   References...........................................14
      6.   Authors' Addresses...................................14







Moscaritolo, Mione                                              [Page 2]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

1.  Introduction

1.1  Target Audience

   This document is intended for implementors of systems that will issue
   or verify a PGPticket. The document should also be reviewed by
   service administrators to help them determine reasonable and secure
   policies for the use of PGPticket.

1.2   Purpose and Motivation

   There is an enormous need for secure but flexible authentication
   technologies. This is illustrated by many of the standardization
   efforts under way dealing with authentication, authorization, and
   Public Key Infrastructures. The complexity of these schemes grows
   exponentially when they are extended to a world-wide community.

   The motivation for this document is to specify a method of creating
   PGP authorization certificates that may be used to grant various
   types of access to services. These methods are based on proven,
   secure cryptographic technology. The tickets defined in this
   documente a compatible variant of the OpenPGP self-signature
   packet. They provide access to resources in a fashion similar to
   existing token card methods but without the drawback of requiring
   extra hardware.

1.3   Related Formats and Protocols

   Several existing and developing standards incorporate similar
   concepts. The SPKI group is attempting to design an infrastructure
   based totally on attribute certificates. The primary purpose is to
   grant access or privileges to the holder of a private key regardless
   of knowing that holder's human readable name. The key (or hash of the
   key) is the identity. Its design focuses on use in electronic
   commerce (i.e. bank transactions, stock transactions, purchasing,
   etc.) There is insufficient experiential evidence to know of all the
   drawbacks that may be present in this system.

   Kerberos authentication may be used to authenticate a user to a
   service (and vice-versa). Each principal's (user or server) secret
   key is kept in a database. This is used by the key distribution
   center to issue tickets when requested for a user to access a
   service. These tickets contain a random secret key for use between
   user and service. The user's key is based on a password known by the
   user. The user must type the password to a client program in order
   for that program to decrypt and use the ticket issued by the kdc. The
   main drawback in this system is that everyone must trust a single
   secure system. That system is a prime target for attack whether that
   attack is to access secret keys or to deny service to legitimate
   users.

   OpenPGP uses strong public key and symmetric cryptography to
   exchange encrypted and/or signed (authenticated) objects. It uses
   a web-of-trust system to determine if a specific public key is

Moscaritolo, Mione                                              [Page 3]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

   trusted (believed to belong to the named entity.) This differs from
   the typical hierarchy of certification authorities (CAs) in a
   traditional public key infrastructure (i.e. PKIX) although PGP's
   network model of trust can be reshaped to form a hierarchy as
   well. The network (web-of-trust) model has its own set of advantages
   and disadvantages. However, additionally, OpenPGP does not address a
   way use its objects or cryptographic facilities to determine access
   rights to a system or other resource.

   PGPticket combines elements of the above technologies to specify an
   authentication mechanism free of some of the above mentioned
   drawbacks. Since the use of the tickets is intended for local
   operations, we are avoiding (i.e. not specifically addressing) the
   global naming issue nor the world-wide PKI issue.

1.4   Attribute Certificates

   Attribute certificates provide a method of binding access
   information to a public key. The purpose of such a certificate is to
   assert that the entity holding the corresponding private key is
   assigned the attributes listed in the certificate and hence any named
   access permissions.

   Attribute certificates may include an identity but many times do
   not. SPKI centers around attribute certificates.

2.  Security Considerations

   The following sections discuss some of the security issues involved
   with generating and using Public Keys (in general) and PGPticket
   specifically) for authentication.

2.1   Public Key Cryptography Limitations

2.1.1   Public Key Exchange and Key Trust

   Although powerful, public key technologies have some limitations. The
   largest problem concerns key trust. Distribution of the keys is not a
   problem since public keys require no secrecy. However, one must have
   a reasonable assurance that a specific key belongs to the expected
   entity.

   Public Key Infrastructures set up key trust based on statements made
   by a trusted certification authority (CA). The CA signs electronic
   documents called certificates in order to bind names and other
   attributes (access permissions, validity dates, etc) to public
   keys. Of course, the signature is made with the CA's public key. So
   that they must be verified by checking a different certificate and so
   forth. The entire process involves the user collecting a chain of
   certificates from his/her trusted CA to the CA of the target
   certificate. They then check the signature and validity in each
   certificate in the chain. These trusted CAs are set up in a type of
   hierarchy where parent CAs certify child CAs and sometimes
   vice-versa. Problems with these techniques include certificate path

Moscaritolo, Mione                                              [Page 4]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

   discovery, certificate path validation, and how to handle the
   compromise of a root CA key. This does not take into account the fact
   that not everyone will trust every CA to be competent in ascertaining
   identity before certifying public keys.

   This process easily becomes long and complex. The Less complex but
   more reliable method to establish public key ownership is to use
   out-of-band methods.  This means that you must use the phone or an
   in-person meeting to acquire and/or verify a key.

   A PGPticket will be issued by a service administrator or
   administration application. The method of acquiring and verifying the
   requester's key is up to that person or application.

2.1.2   Key ID vs. FingerPrint

   In general, keys are hashed to generate a summary called a
   fingerprint. Practice has included abbreviating that fingerprint to
   form a key id that is easy to index for searches.

   Unfortunately, although the hashes used are 'collision proof'
   (i.e. it is computationally infeasible to derive a usable key with
   the same fingerprint), the shorter key ids are not. It has been
   shown that it is easy to generate an RSA key pair that produces a
   specific key id. This was called the 0xDEADBEEF attack.

   Being able to produce a key with the same key id as someone else's
   key means that an attacker can masquerade as that user and trick
   others into encrypting for them. Thus, the key id should only be used
   for fast lookup. Verification of a key MUST depend on comparing full
   key fingerprints.

2.2   Expiration Dates

   The longer a key or certificate exists, the more likely it is that a
   private key may be discovered (either by technical means or through
   social engineering.) Policies controlling dates in a PGPticket should
   be determined by the issuing authority. A good idea is for the
   service administrator to decide on a reasonable maximum life. They can
   then use the lesser of that lifetime or the lifetime given by the
   requester.

2.3   Security Risks When Signing a Challenge

   There is a known attack involving acquiring a signature on a
   challenge. A bogus server can present a challenge which is a
   pre-computed message digest of some text. The response from the user
   is that message digest encrypted with their private key. This
   response would give the server a valid signature from the user on
   text they had never seen. The bogus server could then send the text
   with the valid signature to another party and the original user can
   not prove that they did not originate the message.



Moscaritolo, Mione                                              [Page 5]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

   PGPticket avoids this attack by having the user build another
   standalone signature packet. This packet will contain one hashed
   subpacket. That subpacket is a Notation field with the datatype
   'CHALLENGE' and the data value being the random number issued by the
   server. Since the signature is made on a hash of the notation packet
   (not on the challenge itself), this circumvents the attack noted
   above. See section 3.5.4 for a complete description of the response.

3.  Protocol Description

   This section specifies PGPticket formats and the protocol for
   generating and verifying a PGPticket.

3.1   PGPticket Format

3.1.1   Overview of Ticket Structure

   A PGPticket are simply OpenPGP V4 signature packets with several
   required Notation subpackets and a couple of constraints.
   The format is as follows:

        Packet Tag
         - One-octet version number (4)
         - One-octet signature type [Standalone] (2)
         - One-octet public key algorithm id
         - One-octet hash algorithm id
        Hashed Subpacket Length
         - Two-octet scalar octet count for following hashed subpackets
        Certificate Validity Information
         - One-octet subpacket length (5)
         - One-octet subpacket type
                [Signature Creation Time, Critical] (82)
         - Four-octet time field
        Certificate Issuer Information
         - One-octet subpacket length (9)
         - One-octet subpacket type
                [Creation Issuer key ID, Critical] (90)
         - Eight-octet key ID
        Certificate Validity Information
         - One-octet subpacket length (5)
         - One-octet subpacket type
                [Signature Expiration Time, Critical] (83)
         - Four-octet time field
        Certificate Authorization Information
         - Two-octet or Five-octet subpacket length (N+13)
         - One-octet subpacket type
                [Notation, Critical] (94)
         - Four-octet flag field (0)
         - Two-octet name length (4)
         - Two-octet value length (N)
         - Four-octet name value ('AUTH')
         - N-octet authorization string



Moscaritolo, Mione                                              [Page 6]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

        Certificate Subject Information
         - Two-octet or Five-octet subpacket length (N+13)
         - One-octet subpacket type
                [Notation, critical] (94)
         - Four-octet flag field (0)
         - Two-octet name length (4)
         - Two-octet value length (N)
         - Four-octet name data ('SUBJ')
         - N-octet subject string data.
           For each subject, data includes:
            - Eight-octet key ID
            - One-octet public key algorithm
            - One-octet scalar octet count (M)
            - M-octet public key fingerprint data
        Unhashed Subpacket Length
         - Two-octet scalar octet count for unhashed subpackets (0)
        Hash Value Check
         - Two-octet integer holding left 16 bits of signed hash value
        Signature Value
         - One or more Multi-Precision Integers
                [Depends on Signature Algorithm]

   The following sections detail the meaning of each field and
   subpacket. Since these tickets are implemented as OpenPGP V4
   Standalone signature packets, the format of the various fields will
   match the definitions in [OpenPGP].

   The various fields and subpackets of a PGPticket are
   positional. Thus, they MUST be in the order specified
   above. Additionally, most or all fields use the 'Critical' bit of the
   Packet Type tag. In the OpenPGP specification, this normally means
   that if the application does not understand the subpacket type, it
   SHOULD consider it an error. This specification requires that the
   application MUST consider it an error.

3.2   PGPticket Field Descriptions

3.2.1   Packet Tag

   The Packet Tag field contains four one-octet subfields. The first is
   the version number and must be 4 since these are OpenPGP V4
   packets. The second is the Packet Type and must be the value for
   Standalone signature (2). The next octet is the Public Key Algorithm
   id. The last octet is the hash algorithm id. These represent the hash
   and public key signature algorithms used to produce the issuer's
   signature at the end of the packet. The various id values are listed
   in [OpenPGP].

3.2.2   Hashed Subpacket Length

   This field is a two-octet length. It represents the total number of
   octets in the following four (4) subpackets.



Moscaritolo, Mione                                              [Page 7]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

3.2.3   Certificate Validity Information [Part 1]

   This packet is the first of two validity packets. Its contents
   indicate the time the ticket was created. Its packet length field
   must be 5. Its packet type must be 'signature creation time' with the
   critical bit on (0x82). The remaining field is a four-octet time
   field compatible with time fields from the OpenPGP Specification.

3.2.4   Certificate Issuer Information

   This packet contains information about the issuer or signer's
   key. Its packet length field must be 9. Its packet type field is
   'issuer key ID' with the critical bit on (90). The last field holds
   the eight-octet key ID of the issuer.

3.2.5   Certificate Validity Information [Part 2]

   This packet is the second of two validity packets. Its packet length
   field must be 5. Its packet type must be 'signature expiration time'
   with the critical bit on (0x83). The remaining field is a four-octet
   time field compatible with time fields from [OpenPGP].

3.2.6   Certificate Authorization Information

   This packet is a Notation subpacket. It's length is 13 more than the
   length of the enclosed authorization string. If this packet length is
   less than or equal to 8383 octets, then a two-octet length field is
   used. If it is more, than a five octet length field is used.

   The subpacket type is 'notation' with the critical bit on (94).
   The flag field MUST be zero (0) for this version of the spec. The
   following field is a two-octet name length which must be 4. Next is a
   two-octet value length that holds the actual length of the
   authorization string data. The following field is the name of the
   notation data. It must be 'AUTH'.

   The last field is the authorization data string. The authorization
   string data itself is present for use by application level
   software. It is not specified or interpreted by PGPticket code.

3.2.7   Certificate Subject Information

   This packet is a Notation subpacket. It's length is 13 more than the
   length of the enclosed subject data.  If this packet length is less
   than or equal to 8383 octets, then a two-octet length field is
   used. If it is more, than a five octet length field is used.

   The subpacket type is 'notation' with the critical bit on (94).
   The flag field MUST be zero (0) for this version of the spec. The
   following field is a two-octet name length which must be 4. Next is a
   two-octet value length that holds the actual length of the subject
   data. The following field is the name of the notation data. It must
   be 'SUBJ'.


Moscaritolo, Mione                                              [Page 8]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

   The last field is the subject data. The subject data may hold
   information on one or more subjects. The ticket grants the
   authorization from the above notation packet to each subject
   contained in this notation packet. For each subject mentioned in this
   packet, the following information MUST be present:

        - An eight-octet key id for the subject's key
        - one-octet public key algorithm id. This represents the
          algorithm used when encrypting or signing using the associated
          key.
        - one-octet scalar octet count. This count gives the length of
          the key's full fingerprint.
        - The fingerprint of the subject's key

3.2.8   Unhashed Subpacket Length

   This contains a two-octet scalar octet count for any unhashed
   subpackets that follow. This field MUST be zero (0) for this version
   of the specification. There must be no unhashed subpackets.

3.2.9   Signature Verification Check

   This is a two-octet field that holds the high-order 16 bits of the
   hashed packet data. It is present as an additional integrity
   check. After the below signature data is decrypted with the issuer's
   public key, the two high-order octets may be compared with this
   field. The two values SHOULD match. If they do not, the software
   SHOULD consider the ticket to be corrupted or altered.

3.2.10  Signature

   This field holds one or more Multi-Precision Integers (MPIs). See
   [OpenPGP] for the format of MPIs. The precise format will depend on
   the needs of the specific signature algorithm. Refer to [OpenPGP].

3.3   RADIX-64 Encoded PGPticket

   The below protocol specifies the delivery of tickets using email,
   bulletin boards, or web servers. This requires ASCII encoded tickets.
   To convert a PGPticket to an ASCII string, use the RADIX-64 Armor
   conversion described in [OpenPGP]. The encoded ticket will read:

   -----BEGIN PGP TICKET-----
   Version: Fred's PGPticket 1.0
   [Optional headers]

   {RADIX-64 encoded PGPticket}
   -----END PGP TICKET-----

   This format matches that of PGP messages and keys given in [OpenPGP]
   with the addition of the new Armor Header/Tail Line pair (BEGIN,END
   PGP TICKET).



Moscaritolo, Mione                                              [Page 9]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

3.4   Ticket Acquisition

   It is recommended that each PGPticket be generated and delivered
   out-of-band. This allows service administrators to apply as many or
   as few checks as desired to meet the demands of whatever security
   policies are in place. This method of acquisition is described here.

3.4.1   Out-of-band

   Typically, the person asking for access should simply send their
   public key (or server location of their public key) and the access
   they are requesting to the service administrator. The administrator
   then generates the PGPticket and signs it with the service
   administration private key. The resulting ticket is returned to the
   requester by any of the following:

        - Private cleartext email
        - Posting it to a bulletin board or news group.
        - Placing it on a web server and returning the URL to the
          requester.

   Other means may also be used providing they are known and well
   understood by both parties.

   It is not a security risk to expose the contents of the PGPticket to
   any other party. This is true since anyone trying to use the ticket
   will be required to encrypt a challenge with the corresponding
   private key in order to use the ticket.

3.4.2   Possible Inband Ticket Requests

   It is possible to develop some automated methods for requesting,
   generating and delivering tickets. Specifying such protocols are
   beyond the scope of this document.

3.5   Ticket Use

   Once the ticket is retrieved, the client application may use it to
   gain access to the service. Here is an overview of the procedure:

        - The client sends the ticket to the server along with a request
          for some service.
        - The server checks that the current date is in the range of
          validity dates in the ticket.
        - The server uses its private key to verify the ticket signature
          field.
        - The server verifies that the ticket contains permissions for
          the access requested.
        - If the above checks show the ticket as valid, the server sends
          a random challenge string to the client.
        - The client generates and sends a response. The response is
          created by appending a random nonce to the challenge string.
          It then generates a signature on a new V4 standalone signature
          packet with the resulting sting in a hashed notation packet.

Moscaritolo, Mione                                             [Page 10]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

        - The server checks the signature in this packet. If the leading
          characters of the notation subpacket's data field match the
          sent challenge, it grants access to the client.

   The following sections look at the protocol in more detail.

3.5.1   Ticket Presentation

   Tickets may be sent to the service daemon as part of the service
   request or as part of some additional exchange after the initial
   request is made.

   The method used to deliver the ticket will vary from one application
   protocol to another. These methods are beyond the scope of this
   document.

3.5.2   Ticket Verification

   The server must perform a number of validity checks:

        - The current time must be between the UTC times in the first
          and second Certificate Validity Information subpackets.
        - The issuer's signature must be verified using the issuer's
          public key.
        - The requested access sent with the ticket must be covered by
          the access in the ticket's AUTH notation subpacket.

   If these conditions are met, the server issues a challenge string to
   the client.

3.5.3   Issue of the Challenge

   The challenge string is a series of characters (binary or ASCII),
   that must be signed with the user's matching private key before
   access is granted. There are no constraints on this string, however
   there are security considerations concerning its length.

3.5.4   The Response

   The response is composed of another V4 standalone signature
   packet. The signature in this packet is generated by hashing and
   encrypting the one hashed notation subpacket. The entire packet looks
   like the following:

        Packet Tag
         - One-octet version number (4)
         - One-octet signature type [Standalone] (2)
         - One-octet public key algorithm id
         - One-octet hash algorithm id
        Hashed Subpacket Length
         - Two-octet scalar octet count for following hashed subpackets
        Certificate Authorization Information
         - Two-octet or Five-octet subpacket length (N+18)


Moscaritolo, Mione                                             [Page 11]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

         - One-octet subpacket type
                [Notation, Critical] (94)
         - Four-octet flag field (0)
         - Two-octet name length (4)
         - Two-octet value length (N)
         - Four-octet name value ('CHALLENGE')
         - N-octet challenge string
        Unhashed Subpacket Length
         - Two-octet scalar octet count for unhashed subpackets
           (N+(15 or 18))
        Certificate Subject Information
         - Two-octet or Five-octet subpacket length (N+13)
         - One-octet subpacket type
                [Notation, critical] (94)
         - Four-octet flag field (0)
         - Two-octet name length (4)
         - Two-octet value length (N)
         - Four-octet name data ('SUBJ')
         - N-octet subject string data.
            - Eight-octet key ID
            - One-octet public key algorithm
            - One-octet scalar octet count (M)
            - M-octet public key fingerprint data
        Hash Value Check
         - Two-octet integer holding left 16 bits of signed hash value
        Signature Value
         - One or more Multi-Precision Integers
                [Depends on Signature Algorithm]

   By generating a signature on a hash of a complete notation subpacket,
   we avoid the attack described above in the security section.

   The subject notation sub packet contains information only on the
   subject attempting to respond to the challenge given by the
   server. This subpacket SHOULD be in the unhashed subpacket section
   for efficiency.

3.5.5   Acceptance

   Once the ticket is accepted, an informational message is returned to
   the client. The exact form of this message depends on the application
   protocol (FTP, Telnet, etc.)

   After the client receives this message, the application protocol
   continues with the standard client request/server response cycle.

3.5.6   Rejection

   One of a number of conditions can cause a PGPticket to fail
   verification. This standard minimally supports the reasons listed here:

        - PGPTICKET_ISSUER_SIGNATURE_FAILED_VERIFY - This could occur
          because the packet was tampered with, or the issuer's key has
          expired.

Moscaritolo, Mione                                             [Page 12]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

        - PGPTICKET_TIME_NOT_VALID - The current UTC time does not fall
          in the range of dates in the Certificate Validity Information
          subpackets.
        - PGPTICKET_RESPONSE_SIGNATURE_FAILED_VERIFY - The signature in
          the V4 standalone signature response packet could not be
          verified. This could mean that the subject's public key was
          not available or the response packet was corrupted or altered
          in transit.
        - PGPTICKET_CORRUPTED_TICKET - This error should be issued if
          the hash check bytes do not match the decrypted signature.
        - PGPTICKET_UNKNOWN_ERROR - This error occurs if some other
          problem was encountered when checking the ticket or the
          response.

   The precise form in which an error is reported is not given
   here. That is up to the application protocol implementation. The
   errors should at least enable a client to distinguish between the
   above listed causes.

4.   Examples

   Following are a couple of examples of the use of the PGPticket
   message format and protocol.

4.1   Remote Login

   Remote login could be secured with a modified rlogin/rlogind
   protocol. Using such a scheme and extending it to other forms of
   login (perhaps using a PAM module) could allow passwords to be
   entirely removed from a system.  The rlogin program would send the
   PGPticket as part of the password response to the server. The server
   then issues the challenge and rlogin returns the response.

   The AUTH notation subpacket would contain a simple rlogin command to
   indicate the login name.

   Here is an example ticket, challenge and response sequence:
   [To Be Written]

4.2   Non-anonymous FTP with no remote account

   There are cases where you may wish to give someone temporary FTP
   access to a machine you run. Additionally, you may not trust or run
   anonymous FTP.

   Using an FTP server modified to handle PGPticket access, you can
   issue a ticket to the person that is good only between a specific
   range of dates and to access a specific FTP directory or directories.

   The AUTH notation subpacket would contain information on which
   directories the key holder has access to as well as the type of
   access. Log entries could be created showing the key id of the user
   and the time they accessed the server. This provides the auditing
   needed for site security requirements.

Moscaritolo, Mione                                             [Page 13]


INTERNET-DRAFT                 PGPticket                     14-Jul-1998

   Here is an example ticket, challenge and response sequence:
   [To Be Written]

5.   References

   [OpenPGP] Callas, J. et. al., "OpenPGP Message Format",
   Network Associates, 1998.

6.   Authors' Addresses

Vinnie Moscaritolo
Worldwide Developer Technical Support
N&C/Hardware
Apple Computer, Inc.
3 Infinite Loop, MS: 303-2T
Cupertino, CA 95014

vinnie@apple.com
+1 408/974-5560

Antonino N. Mione
Rutgers University Computing Services
Hill Center for the Mathematical Sciences
110 Frelinghuysen Rd.
Piscataway, NJ 08854

mione@nbcs-ns.rutgers.edu
+1 732/445-0650



























Moscaritolo, Mione                                             [Page 14]