Internet DRAFT - draft-newman-pwchange
draft-newman-pwchange
Network Working Group C. Newman
Internet Draft: Internet Password Change Protocol Innosoft
Document: draft-newman-pwchange-00.txt R. Gellens
Qualcomm
July 1997
Expires in six months
Internet Password Change Protocol (IPCP)
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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Introduction
As the Internet continues to migrate from using centralized login
servers to distributed client/server technology, the need for a
protocol to remotely change passwords increases. Two protocols are
currently in use for this purpose. Kerberos includes its own
password change protocol, although client support is relatively
limited. A very simple ad-hoc protocol called "poppassd" has been
used in conjunction with POP [POP3] servers. This protocol is
supported by many popular POP3 servers and clients but it has the
unfortunate property of sending the old and new passwords in plain
text over the network.
This document specifies a new protocol for changing passwords or
passphrases. It is based on the SASL [SASL] framework and intended
to be as simple as possible while also being fully extensible.
This is designed to work well with the APOP [POP3] command and
Newman [Page 1]
Internet Draft Internet Password Change Protocol July 1997
similar simple mechanisms to avoid sending plaintext passwords over
the network whenever feasible.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"OPTIONAL" and "MAY" in this document are to be interpreted as
defined in "Key words for use in RFCs to Indicate Requirement
Levels" [KEYWORDS].
The formal grammar in this document uses Augmented BNF [ABNF].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If such lines are wrapped without a new "C:"
or "S:" label, then the wrapping is for editorial clarity and is
not part of the command. Non-text information in examples is hex-
encoded and shown in angle-brackets (e.g., "<5F601D>") for
readability, although the actual exchange involves binary data
transmission.
2. Protocol Overview
This protocol is a simple text-based protocol. The basic concept
is to use the SASL [SASL] framework with the addition of
special-purpose password-change mechanisms. A protocol-level
integrity service is optionally included to prevent active attacks
which alter the list of available mechanisms.
The protocol consists of a server greeting, followed by client
commands and server responses. Clients are permitted to send
multiple commands at once and will receive responses in order from
the server. Commands and responses are sent as CRLF terminated
lines.
The protocol is designed to be extensible so that more
sophisticated mechanisms can be added in the future.
A simple exchange involves a server greeting, a client AUTHCHANGE
command and associated SASL exchange, followed by a server
acknowledgement, and a client LOGOUT command.
3. IPCP Protocol Framework
This section contains the specification of the IPCP protocol. When
IPCP is used over TCP/IP the server runs on port 586. The SASL
Newman [Page 2]
Internet Draft Internet Password Change Protocol July 1997
service name for IPCP is "ipcp".
3.1. Protocol Elements
This section specifies basic components of the protocol.
3.1.1. Protocol keywords
Protocol keywords are short fixed strings used to describe client
commands and server responses. They have the following formal
grammar:
ALPHA = %x41-5A / %x61-7A
;; A US-ASCII letter
KCHAR = %x21 / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
;; All printable US-ASCII characters except SPACE,
;; <">, "(", ")", "\", and "{"
keyword = ALPHA *63KCHAR
3.1.2. Quoted Strings
Data sent between client and server may be represented as a quoted
string. Quoted strings are surrounded by double quotes, must not
exceed 1024 octets, and must not contain NUL, CR or LF. The
characters <"> and "\" may be included by preceding them with "\".
When quoted strings are used to represent human readable text, they
are in the form of a "utf8-quoted" string [UTF8]. All other quoted
strings are in the form of a regular "quoted-string" as follows:
QCHAR = US-ASCII-SAFE / %x80-FF
;; UTF8 is used for text
QCHAR-QUOTED = QCHAR / QUOTED
QUOTED = "\" QUOTED-SPECIAL
QUOTED-SPECIAL = "\" / <">
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-21
/ %x23-5B / %x5D-7F
;; US-ASCII except QUOTED-SPECIALs, CR, LF, NUL
UTF8-NON-NUL = UTF8-SAFE / CR / LF / QUOTED-SPECIAL
Newman [Page 3]
Internet Draft Internet Password Change Protocol July 1997
UTF8-QUOTED = UTF8-SAFE / QUOTED
UTF8-SAFE = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
quoted-string = <"> *QCHAR-QUOTED <">
;; limited to 1024 octets
utf8-qstring = <"> *UTF8-QUOTED <">
;; limited to 1024 octets
3.1.3. Literal/Binary Strings
Arbitrary data may be sent between the client and the server using
literal strings. Literal strings begin with an unsigned 32 bit
number enclosed in braces ("{", "}") representing the length,
followed by a CRLF, followed by length octets, followed by the
remainder of the command line. Note that non-text literal strings
MAY contain a 0 or NUL octet, so implementations MUST NOT use NUL-
terminated strings to store binary literal strings internally.
Text literal strings are interpreted according to UTF-8. Literals
have the following formal grammar:
DIGIT = "0" / "1" / "2" / "3" / "4" / "5"
/ "6" / "7" / "8" / "9"
OCTET = %x00-FF
OCTET-NZ = %x01-FF
number = 1*DIGIT
;; limited to 0 <= number < 4,294,967,296
Newman [Page 4]
Internet Draft Internet Password Change Protocol July 1997
literal = "{" number "}" CRLF *OCTET
;; number indicates the number of OCTETs.
;; UTF-8 is used for text
string = literal / quoted-string
Servers are required to skip client literals even if a command
contains a syntax error.
3.1.4. Groupings
Parentheses are used to group related strings and keywords
together.
3.2. Server responses
Each server response begins with a slash ("/") separated
hierarchical response code. The first component of the code is
"OK", "NO", "BAD", "CONT" or "GOODBYE". "OK" indicates successful
connection or successful completion of a client command. "NO"
indicates the command failed for some reason. "BAD" indicates a
protocol syntax error, usually the result of a client bug. "CONT"
indicates the successful receipt of a partial command and includes
server data which the client may use to continue the command. And
"GOODBYE" indicates some event forced the server to close the
connection. Clients MAY interpret only the first one or two
hierarchical components of the response code, but MUST ignore any
response detail beyond those components recognized.
For responses other than "CONT", the initial response code is
followed by an optional grouping of response-specific data. This
is followed by a UTF-8 quoted string describing any status or
errors as human readable text.
After a successful AUTHCHANGE command is received (see below), a
signature of the response line SHOULD be included with the response
if a shared secret is present. This prevents active attacks which
alter the initial greeting line or the response code. The
signature is computed by taking the AUTHCHANGE random number from
the client and appending the server greeting line and the current
response line up to and including the space before the signature,
then applying the requested signature mechanism using the original
shared secret. The resulting signature is then attached as a
literal to the end of the response.
Newman [Page 5]
Internet Draft Internet Password Change Protocol July 1997
The formal grammar for server responses follows:
response = resp-continue / resp-done
resp-continue = "CONT" SPACE string
response-data = resp-group
resp-detail = *("/" keyword)
;; MUST be registered with IANA
resp-done = resp-status resp-detail [SPACE response-data]
SPACE utf8-quoted [SPACE signature]
resp-group = "(" resp-extend *(SPACE resp-extend) ")"
resp-status = "OK" / "NO" / "BAD" / "GOODBYE"
resp-extend = keyword / number / string / resp-group
signature = literal
;; a signature computed over the response
;; using the algorithm specified in the AUTHCHANGE
;; command
3.3. Client Commands
Client commands consist of a keyword followed by arguments.
3.4. Signature Mechanisms
IPCP supports signature mechanisms for signing the server greeting
and protocol response lines. The mechanism HMAC-SHA1 [HMAC, SHA1]
MUST be supported and additional mechanisms can be registered with
IANA. The mechanism NONE MUST be supported if any mechanisms are
offered which don't involve a shared secret, but servers MAY reject
NONE in combination with any mechanism that includes a shared
secret.
4. Protocol Exchange
This section documents the protocol exchange.
Newman [Page 6]
Internet Draft Internet Password Change Protocol July 1997
4.1. Server Greeting
The server greeting takes the form of a response. A GOODBYE
greeting indicates the server is not available and MAY include
response detail indicating the reason. An OK greeting indicates
the server is ready.
4.1.1. Server Referral
If a server is unavailable, it may include a referral to a
different server. It may be useful to run a referral-only server
on a less secure system which refers to a more secure system. For
example, a POP3 [POP3] client should be able connect to the IPCP
port on a POP3 server and either change the password there or be
refered to a proper IPCP server. This way clients don't need to be
configured with an additional server. A referral is represented by
a NO/REFER response with one or more domain names for the
response-data.
Example:
S: NO/REFER ("ipcp.server.domain") "IPCP not available here"
4.1.2. Server Ready
A server ready greeting is an OK/IPCP response. The response-data
includes a server random string followed by capability information
for the server. The "SIG-MECH" capability MUST be included and is
followed by a list of signature mechanisms. The "SASL" capability
MUST be included and is followed by a list of supported SASL
mechanisms. Other capabilities MAY be defined by standards track
or IESG approved experimental extensions to this protocol.
Example:
S: OK/IPCP ((SIG-MECH "HMAC-SHA1" "NONE") (SASL "SHA1-CHANGE"))
"Joe's IPCP server v1.0 Ready"
4.1.3. Server Too Busy
The "GOODBYE/TOOBUSY" response indicates the server is too busy to
process the request at the current time. GOODBYE with no
additional detail may also be used to indicate other conditions
which prevent the server from accepting client commands.
Example:
S: GOODBYE/TOOBUSY "Server too busy at the present time"
Newman [Page 7]
Internet Draft Internet Password Change Protocol July 1997
4.2. AUTHCHANGE command
An AUTHCHANGE command selects the IPCP signature mechanism, a
random challenge for the signature mechanism, a SASL authentication
and passphrase change mechanism and an optional sasl-data argument
for SASL mechanisms where the client sends the first non-empty
message. The command is followed by a SASL exchange with server
data in the string following the "CONT" response, and client data
as a single string followed by a CRLF. The authorization identity
included in the SASL exchange indicates the user whose passphrase
should be changed, the authentication identity indicates the user
whose credentials are being used to initiate the change. This
allows IPCP to be used by an administrator to set passwords for
other users.
The client MUST wait at least one minute for the server to issue
the final success or failure response. This permits the server
limited time to perform a dictionary attack on the passphrase
verifier for those mechanisms which pass a one-way function applied
to the passphrase.
AUTHCHANGE has the following syntax:
command-authchg = "AUTHCHANGE" SPACE sig-mech SPACE random
SPACE sasl-mech [SPACE sasl-data] CRLF
*(string CRLF)
random = literal
;; client-generated random data
sasl-data = string
;; A mechanism based client initial string.
sasl-mech = "PLAIN-CHANGE" / "SHA1-CHANGE" / keyword
;; MUST be registered with IANA according to
;; procedures in SASL and listed in server greeting
sig-mech = "HMAC-SHA1" / "NONE" / keyword
;; MUST be registered with IANA
Example:
[TODO - use change mechanism]
S: OK/IPCP ((SIG-MECH "HMAC-SHA1" "NONE") (SASL "SHA1-CHANGE"))
"Joe's IPCP server v1.0 Ready"
C: AUTHCHANGE HMAC-SHA1 {20}
C: <A745B67893026BC125397D4F6980D12B0402BB78> CRAM-MD5
S: CONT "<1896.697170952@postoffice.reston.mci.net>"
C: "tim b913a602c7eda7a495b4e6e7334d3890"
Newman [Page 8]
Internet Draft Internet Password Change Protocol July 1997
S: OK "Welcome, tim" {20}
S: <TODO>
4.3. Responses to AUTHCHANGE command
An OK response indicates successful authentication and password
change, a NO response indicates a failure at some point in the
process. The response line SHOULD be signed by the server as
requested by the client. The client SHOULD verify the signature on
the server's response. An initial set of failure responses are
listed in this section. Not all responses are appropriate for all
change mechanisms.
4.3.1. NO/AUTH/FAILED response
This indicates that no secret could be found for the specified user
or the client's authentication did not verify correctly. There is
no response to indicate unknown user in order to avoid attacks
which probe for users on the system.
4.3.2. NO/AUTH/EXPIRED response
This indicates that the passphrase has expired and the account
owner needs to contact the system administrator for new
credentials. The human readable string MAY contain contact
information.
4.3.3. NO/AUTH/SUSPENDED response
This indicates the account has been suspended until further notice
and no access to that account of any sort is permitted.
4.3.4. NO/AUTH/ENCRYPT response
This indicates the requested mechanism is not permitted unless an
external encryption layer is applied.
4.3.5. NO/AUTH/TRANSITION-NEEDED response
This indicates that the server has an entry for the user in a
legacy authentication database from which the secret can not be
recovered. It also indicates that a one-time use of the SASL PLAIN
Newman [Page 9]
Internet Draft Internet Password Change Protocol July 1997
[SASL-PLAIN] mechanism MAY be used by the client to initialize an
entry in a newer authentication database so that future connections
and password change requests can be secure.
4.3.6. NO/AUTH/SECURE-TRANSITION-NEEDED response
This indicates that the server has an entry for the user in a
legacy authentication database from which the secret can not be
recovered. The client is required to use some secure mechanism to
change the passphrase (e.g., secure remote login, or an encryption
extension to this protocol) before future changes can be made.
4.3.7. NO/AUTH/UTF-8 response
This indicates that the authentication or authorization user name
specified did not meet UTF-8 syntax. Servers are encouraged to
enforce UTF-8 syntax as this is likely to prevent non-interoperable
use of non-US-ASCII characters in user names. The "NO/AUTH/FAILED"
response MUST be used if the user name has valid syntax but does
not exist.
4.3.8. NO/SIG/WEAK response
This indicates the signature mechanism requested was too weak to
meet server requirements for the specified SASL mechanism.
4.3.9. NO/SIG/NONE response
This indicates the SASL mechanism specified does not support
signatures and that the NONE signature mechanism has to be used
instead.
4.3.9. NO/REFER response
A server referral as defined in section 4.1.1. can occur in
response to an AUTHCHANGE command.
4.3.10. NO/NEWPASS response
This indicates that the new password does not meet site policy,
syntax or authorization rules.
Newman [Page 10]
Internet Draft Internet Password Change Protocol July 1997
4.3.11. NO/NEWPASS/AUTHORIZE response
This indicates the authenticated user does not have permission to
change the password for the authorization user name specified.
4.3.12. NO/NEWPASS/UTF-8 response
This indicates the new passphrase does not meet the syntax
requirements for UTF-8. Servers are encouraged to enforce UTF-8
syntax as this is likely to prevent non-interoperable use of non-
US-ASCII characters in passwords.
4.3.13. NO/NEWPASS/SHORT response
This indicates the passphrase is too short for server requirements.
The minimum length is a number at the beginning of the included
response-data.
4.3.14. NO/NEWPASS/LONG response
This indicates the passphrase is too long for server requirements.
The maximum length is a number at the beginning of the included
response-data. Maximum lengths below 64 characters are strongly
discouraged.
4.3.15. NO/NEWPASS/SIMPLE response
This indicates the new passphrase is too easy to guess. For
example, entirely lower-case letters.
4.3.16. NO/NEWPASS/COMPLEX response
This indicates the new passphrase is too complex. Specifically, it
contains a character which is inappropriate for use with the
supported authentication mechanisms. For example, use of the CR
and LF characters in a passphrase are usually not permitted in
plaintext mechanisms.
4.3.17. NO/NEWPASS/SAME response
This indicates that the new passphrase is the same as the old
passphrase. There is deliberately no failure error code to
Newman [Page 11]
Internet Draft Internet Password Change Protocol July 1997
indicate that an older passphrase is being reused. Although this
may seem like a security measure, it has the effect of encouraging
users to write down a series of passphrases and thus reduces the
overall security of the system.
4.3.18. NO/NEWPASS/DICT response
This indicates that the new passphrase was found in a server
dictionary and is therefore likely to be found by a dictionary
attack. The dictionary MAY include static files such as
/usr/dict/words on Unix in addition to algorithms applied to the
username or personal information associated with the user.
4.4. LOGOUT command
The LOGOUT command indicates the client is completed. The client
MAY disconnect any time after LOGOUT is successfully sent, and the
server will disconnect immediately upon receipt of a LOGOUT command
after any other outstanding responses have been successfully sent.
The formal grammar is as follows:
command-logout = "LOGOUT" CRLF
4.5. AUTH command
The AUTH command is syntactically identical to the AUTHCHANGE
command. It is used with regular SASL mechanisms which activate an
encryption layer. For the client, the encryption layer takes
effect on the first octet of the command immediately following a
successful AUTH command. For the server, the encryption layer
takes effect immediately after the last octet of an OK response
line to the AUTH command. The AUTH command fails with a
NO/AUTH/ENCRYPT error if negotiation of an encryption layer fails.
The authorization identity is ignored by the AUTH command. Once an
encryption layer is active clients and servers MUST NOT request
another encryption layer.
5. Initial SASL mechanisms for IPCP
The section defines some initial SASL change mechanisms for IPCP.
All implementations of IPCP MAY support the PLAIN-CHANGE mechanism,
but if supported, there MUST be a way to disable the mechanism.
All server implementations which support PLAIN-CHANGE SHOULD have a
way to disable the mechanism on a per-user basis in favor of
Newman [Page 12]
Internet Draft Internet Password Change Protocol July 1997
stronger mechanisms. All server implementations of IPCP with
access to an authentication database which stores the plaintext
password itself (e.g., after applying invertible encryption) MUST
support the SHA1-CHANGE mechanism. All client implementations of
IPCP MUST support the SHA1-CHANGE mechanism.
5.1. PLAIN-CHANGE SASL mechanism
Support for the PLAIN-CHANGE mechanism is included only to support
legacy authentication systems. Its use is strongly discouraged
since it exposes both the old and new passphrase to a network
evesdropper. This mechanism has no shared secret because the
primary use of plaintext passwords is only when the server stores
the plaintext password after applying a one-way function. For this
reason, the NONE signature mechanism is used with the PLAIN-CHANGE
SASL mechanism.
The mechanism consists of a single message from the client to the
server including the user whose password is to be changed, the
authentication id, the passphrase for the authentication id and the
new passphrase for the user, separated by US-ASCII NUL characters.
The formal grammar for this mechanism is as follows:
plain-change = change-user NUL auth-user NUL auth-pass NUL new-pass
change-user = *UTF8-SAFE
;; if empty, then is same as auth-user
auth-user = 1*UTF8-SAFE
auth-pass = 1*256UTF8-SAFE
new-pass = 1*256UTF8-SAFE
NUL = %x00
;; zero octet, US-ASCII NUL
5.2. SHA1-CHANGE SASL mechanism
This mechanism is suitable for changing the passphrase for any
mechanism which stores the passphrase on the server without
applying a one-way function; such as APOP [POP3] or some
implementations of CRAM-MD5 [CRAM-MD5]. Note that this mechanism
is susceptible to offline dictionary attacks. Specifically, if an
evesdropper records a session, that evesdropper may run values for
the old password through the HMAC-SHA1 process until matching
Newman [Page 13]
Internet Draft Internet Password Change Protocol July 1997
output results. For this reason, it is vital to use longer and
more complex passphrases. The shared secret for use with the
signature mechanism is the old plaintext passphrase unencrypted.
This mechanism begins with an initial server challenge. The client
responds with the user whose password is to be changed, the
authentication user name, a client challenge and an HMAC-SHA1
[HMAC] signature computed over the server challenge using the old
passphrase. If the client's signature verifies, the server signs a
string consisting of the client's challenge appended to the
server's initial challenge, using the old passphrase. If the
server's signature verifies, the client transmits the new
passphrase using the following algorithm:
(1) First, an octet representing the length of the new passphrase
is pre-pended to the passphrase and this is placed in a buffer
rounded up to a 20 octet boundary with arbitrary padding octets.
(2) Apply HMAC-SHA1 to the server's signature using the old
passphrase.
(3) The output of step (2) is exclusive-ored with the first 20
octets of the buffer. If the passphrase is less than 20 octets the
process completes.
(4) If the buffer is longer than 20 octets, then the 20 octet
output of step (3) is re-signed with the old passphrase using
HMAC-SHA1.
(5) The output of step (4) is exclusive ored with the next 20 octet
segment of the buffer. Repeat steps (4) and (5) until done.
The formal grammar for the exchange follows:
server-message-1 = challenge
client-message-1 = change-user NUL auth-user NUL
challenge NUL signature
server-message-2 = signature
client-message-2 = sha1-new-pass
signature = 20OCTET
;; 20 octet output of HMAC-SHA1
Newman [Page 14]
Internet Draft Internet Password Change Protocol July 1997
challenge = 20*OCTET-NZ
;; randomly generated challenge with no NUL
;; octets. MUST be at least 20 octets long
sha1-new-pass = 1*13xor-sig-block
xor-sig-block = 20OCTET
;; signature exclusive ored with new passphrase
;; buffer as described above
6. Examples
TODO
7. Security Considerations
Security considerations are discussed throughout this document.
Clients are encouraged to record the occurance of a successful
authentication for a given user and server combination and refuse
to use plain text passwords for that user and that server in the
future. This will prevent a man in the middle or a spoof server
from aquiring the user's password by pretending a transition is
needed.
Use of password change SASL mechanisms with protocols other than
this one is discouraged, since general purpose application servers
may not be treated with the same level of security analysis a
system administrator is likely to apply to a server running a
password change protocol.
8. References
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt
[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", RFC 2095, MCI, January 1997.
<ftp://ds.internic.net/rfc/rfc2095.txt>
[HMAC] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, IBM, UCSD, February 1997.
<ftp://ds.internic.net/rfc/rfc2104.txt>
Newman [Page 15]
Internet Draft Internet Password Change Protocol July 1997
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt>
[POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
<ftp://ds.internic.net/rfc/rfc1939.txt>
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", Work in progress: draft-myers-auth-sasl-xx.txt
[SASL-PLAIN] Newman, "Plaintext Password SASL Mechanism and
Transition Strategy", Work in progress: draft-newman-sasl-
plaintrans-xx.txt.
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
ISO 10646", RFC 2044, Alis Technologies, October 1996.
<ftp://ds.internic.net/rfc/rfc2044.txt>
9. Authors' Addresses
Chris Newman
Innosoft International, Inc.
1050 East Garvey Ave. South
West Covina, CA 91790 USA
Email: chris.newman@innosoft.com
Randall Gellens
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, CA 92121-2779 USA
Email: Randy@Qualcomm.Com
Newman [Page 16]
