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]