733 lines
24 KiB
Text
733 lines
24 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group W. Simpson
|
||
Request for Comments: 1994 DayDreamer
|
||
Obsoletes: 1334 August 1996
|
||
Category: Standards Track
|
||
|
||
|
||
PPP Challenge Handshake Authentication Protocol (CHAP)
|
||
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
The Point-to-Point Protocol (PPP) [1] provides a standard method for
|
||
transporting multi-protocol datagrams over point-to-point links.
|
||
|
||
PPP also defines an extensible Link Control Protocol, which allows
|
||
negotiation of an Authentication Protocol for authenticating its peer
|
||
before allowing Network Layer protocols to transmit over the link.
|
||
|
||
This document defines a method for Authentication using PPP, which
|
||
uses a random Challenge, with a cryptographically hashed Response
|
||
which depends upon the Challenge and a secret key.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction .......................................... 1
|
||
1.1 Specification of Requirements ................... 1
|
||
1.2 Terminology ..................................... 2
|
||
2. Challenge-Handshake Authentication Protocol ........... 2
|
||
2.1 Advantages ...................................... 3
|
||
2.2 Disadvantages ................................... 3
|
||
2.3 Design Requirements ............................. 4
|
||
3. Configuration Option Format ........................... 5
|
||
4. Packet Format ......................................... 6
|
||
4.1 Challenge and Response .......................... 7
|
||
4.2 Success and Failure ............................. 9
|
||
SECURITY CONSIDERATIONS ...................................... 10
|
||
ACKNOWLEDGEMENTS ............................................. 11
|
||
REFERENCES ................................................... 12
|
||
CONTACTS ..................................................... 12
|
||
|
||
|
||
|
||
|
||
Simpson [Page i]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
1. Introduction
|
||
|
||
In order to establish communications over a point-to-point link, each
|
||
end of the PPP link must first send LCP packets to configure the data
|
||
link during Link Establishment phase. After the link has been
|
||
established, PPP provides for an optional Authentication phase before
|
||
proceeding to the Network-Layer Protocol phase.
|
||
|
||
By default, authentication is not mandatory. If authentication of
|
||
the link is desired, an implementation MUST specify the
|
||
Authentication-Protocol Configuration Option during Link
|
||
Establishment phase.
|
||
|
||
These authentication protocols are intended for use primarily by
|
||
hosts and routers that connect to a PPP network server via switched
|
||
circuits or dial-up lines, but might be applied to dedicated links as
|
||
well. The server can use the identification of the connecting host
|
||
or router in the selection of options for network layer negotiations.
|
||
|
||
This document defines a PPP authentication protocol. The Link
|
||
Establishment and Authentication phases, and the Authentication-
|
||
Protocol Configuration Option, are defined in The Point-to-Point
|
||
Protocol (PPP) [1].
|
||
|
||
|
||
1.1. Specification of Requirements
|
||
|
||
In this document, several words are used to signify the requirements
|
||
of the specification. These words are often capitalized.
|
||
|
||
MUST This word, or the adjective "required", means that the
|
||
definition is an absolute requirement of the specification.
|
||
|
||
MUST NOT This phrase means that the definition is an absolute
|
||
prohibition of the specification.
|
||
|
||
SHOULD This word, or the adjective "recommended", means that there
|
||
may exist valid reasons in particular circumstances to
|
||
ignore this item, but the full implications must be
|
||
understood and carefully weighed before choosing a
|
||
different course.
|
||
|
||
MAY This word, or the adjective "optional", means that this
|
||
item is one of an allowed set of alternatives. An
|
||
implementation which does not include this option MUST be
|
||
prepared to interoperate with another implementation which
|
||
does include the option.
|
||
|
||
|
||
|
||
|
||
Simpson [Page 1]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
1.2. Terminology
|
||
|
||
This document frequently uses the following terms:
|
||
|
||
authenticator
|
||
The end of the link requiring the authentication. The
|
||
authenticator specifies the authentication protocol to be
|
||
used in the Configure-Request during Link Establishment
|
||
phase.
|
||
|
||
peer The other end of the point-to-point link; the end which is
|
||
being authenticated by the authenticator.
|
||
|
||
silently discard
|
||
This means the implementation discards the packet without
|
||
further processing. The implementation SHOULD provide the
|
||
capability of logging the error, including the contents of
|
||
the silently discarded packet, and SHOULD record the event
|
||
in a statistics counter.
|
||
|
||
|
||
|
||
|
||
2. Challenge-Handshake Authentication Protocol
|
||
|
||
The Challenge-Handshake Authentication Protocol (CHAP) is used to
|
||
periodically verify the identity of the peer using a 3-way handshake.
|
||
This is done upon initial link establishment, and MAY be repeated
|
||
anytime after the link has been established.
|
||
|
||
1. After the Link Establishment phase is complete, the
|
||
authenticator sends a "challenge" message to the peer.
|
||
|
||
2. The peer responds with a value calculated using a "one-way
|
||
hash" function.
|
||
|
||
3. The authenticator checks the response against its own
|
||
calculation of the expected hash value. If the values match,
|
||
the authentication is acknowledged; otherwise the connection
|
||
SHOULD be terminated.
|
||
|
||
4. At random intervals, the authenticator sends a new challenge to
|
||
the peer, and repeats steps 1 to 3.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 2]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
2.1. Advantages
|
||
|
||
CHAP provides protection against playback attack by the peer through
|
||
the use of an incrementally changing identifier and a variable
|
||
challenge value. The use of repeated challenges is intended to limit
|
||
the time of exposure to any single attack. The authenticator is in
|
||
control of the frequency and timing of the challenges.
|
||
|
||
This authentication method depends upon a "secret" known only to the
|
||
authenticator and that peer. The secret is not sent over the link.
|
||
|
||
Although the authentication is only one-way, by negotiating CHAP in
|
||
both directions the same secret set may easily be used for mutual
|
||
authentication.
|
||
|
||
Since CHAP may be used to authenticate many different systems, name
|
||
fields may be used as an index to locate the proper secret in a large
|
||
table of secrets. This also makes it possible to support more than
|
||
one name/secret pair per system, and to change the secret in use at
|
||
any time during the session.
|
||
|
||
|
||
2.2. Disadvantages
|
||
|
||
CHAP requires that the secret be available in plaintext form.
|
||
Irreversably encrypted password databases commonly available cannot
|
||
be used.
|
||
|
||
It is not as useful for large installations, since every possible
|
||
secret is maintained at both ends of the link.
|
||
|
||
Implementation Note: To avoid sending the secret over other links
|
||
in the network, it is recommended that the challenge and response
|
||
values be examined at a central server, rather than each network
|
||
access server. Otherwise, the secret SHOULD be sent to such
|
||
servers in a reversably encrypted form. Either case requires a
|
||
trusted relationship, which is outside the scope of this
|
||
specification.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 3]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
2.3. Design Requirements
|
||
|
||
The CHAP algorithm requires that the length of the secret MUST be at
|
||
least 1 octet. The secret SHOULD be at least as large and
|
||
unguessable as a well-chosen password. It is preferred that the
|
||
secret be at least the length of the hash value for the hashing
|
||
algorithm chosen (16 octets for MD5). This is to ensure a
|
||
sufficiently large range for the secret to provide protection against
|
||
exhaustive search attacks.
|
||
|
||
The one-way hash algorithm is chosen such that it is computationally
|
||
infeasible to determine the secret from the known challenge and
|
||
response values.
|
||
|
||
Each challenge value SHOULD be unique, since repetition of a
|
||
challenge value in conjunction with the same secret would permit an
|
||
attacker to reply with a previously intercepted response. Since it
|
||
is expected that the same secret MAY be used to authenticate with
|
||
servers in disparate geographic regions, the challenge SHOULD exhibit
|
||
global and temporal uniqueness.
|
||
|
||
Each challenge value SHOULD also be unpredictable, least an attacker
|
||
trick a peer into responding to a predicted future challenge, and
|
||
then use the response to masquerade as that peer to an authenticator.
|
||
|
||
Although protocols such as CHAP are incapable of protecting against
|
||
realtime active wiretapping attacks, generation of unique
|
||
unpredictable challenges can protect against a wide range of active
|
||
attacks.
|
||
|
||
A discussion of sources of uniqueness and probability of divergence
|
||
is included in the Magic-Number Configuration Option [1].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 4]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
3. Configuration Option Format
|
||
|
||
A summary of the Authentication-Protocol Configuration Option format
|
||
to negotiate the Challenge-Handshake Authentication Protocol is shown
|
||
below. The fields are transmitted from left to right.
|
||
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Type | Length | Authentication-Protocol |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Algorithm |
|
||
+-+-+-+-+-+-+-+-+
|
||
|
||
Type
|
||
|
||
3
|
||
|
||
Length
|
||
|
||
5
|
||
|
||
Authentication-Protocol
|
||
|
||
c223 (hex) for Challenge-Handshake Authentication Protocol.
|
||
|
||
Algorithm
|
||
|
||
The Algorithm field is one octet and indicates the authentication
|
||
method to be used. Up-to-date values are specified in the most
|
||
recent "Assigned Numbers" [2]. One value is required to be
|
||
implemented:
|
||
|
||
5 CHAP with MD5 [3]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 5]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
4. Packet Format
|
||
|
||
Exactly one Challenge-Handshake Authentication Protocol packet is
|
||
encapsulated in the Information field of a PPP Data Link Layer frame
|
||
where the protocol field indicates type hex c223 (Challenge-Handshake
|
||
Authentication Protocol). A summary of the CHAP packet format is
|
||
shown below. The fields are transmitted from left to right.
|
||
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Code | Identifier | Length |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Data ...
|
||
+-+-+-+-+
|
||
|
||
Code
|
||
|
||
The Code field is one octet and identifies the type of CHAP
|
||
packet. CHAP Codes are assigned as follows:
|
||
|
||
1 Challenge
|
||
2 Response
|
||
3 Success
|
||
4 Failure
|
||
|
||
Identifier
|
||
|
||
The Identifier field is one octet and aids in matching challenges,
|
||
responses and replies.
|
||
|
||
Length
|
||
|
||
The Length field is two octets and indicates the length of the
|
||
CHAP packet including the Code, Identifier, Length and Data
|
||
fields. Octets outside the range of the Length field should be
|
||
treated as Data Link Layer padding and should be ignored on
|
||
reception.
|
||
|
||
Data
|
||
|
||
The Data field is zero or more octets. The format of the Data
|
||
field is determined by the Code field.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 6]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
4.1. Challenge and Response
|
||
|
||
Description
|
||
|
||
The Challenge packet is used to begin the Challenge-Handshake
|
||
Authentication Protocol. The authenticator MUST transmit a CHAP
|
||
packet with the Code field set to 1 (Challenge). Additional
|
||
Challenge packets MUST be sent until a valid Response packet is
|
||
received, or an optional retry counter expires.
|
||
|
||
A Challenge packet MAY also be transmitted at any time during the
|
||
Network-Layer Protocol phase to ensure that the connection has not
|
||
been altered.
|
||
|
||
The peer SHOULD expect Challenge packets during the Authentication
|
||
phase and the Network-Layer Protocol phase. Whenever a Challenge
|
||
packet is received, the peer MUST transmit a CHAP packet with the
|
||
Code field set to 2 (Response).
|
||
|
||
Whenever a Response packet is received, the authenticator compares
|
||
the Response Value with its own calculation of the expected value.
|
||
Based on this comparison, the authenticator MUST send a Success or
|
||
Failure packet (described below).
|
||
|
||
Implementation Notes: Because the Success might be lost, the
|
||
authenticator MUST allow repeated Response packets during the
|
||
Network-Layer Protocol phase after completing the
|
||
Authentication phase. To prevent discovery of alternative
|
||
Names and Secrets, any Response packets received having the
|
||
current Challenge Identifier MUST return the same reply Code
|
||
previously returned for that specific Challenge (the message
|
||
portion MAY be different). Any Response packets received
|
||
during any other phase MUST be silently discarded.
|
||
|
||
When the Failure is lost, and the authenticator terminates the
|
||
link, the LCP Terminate-Request and Terminate-Ack provide an
|
||
alternative indication that authentication failed.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 7]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
A summary of the Challenge and Response packet format is shown below.
|
||
The fields are transmitted from left to right.
|
||
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Code | Identifier | Length |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Value-Size | Value ...
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Name ...
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
Code
|
||
|
||
1 for Challenge;
|
||
|
||
2 for Response.
|
||
|
||
Identifier
|
||
|
||
The Identifier field is one octet. The Identifier field MUST be
|
||
changed each time a Challenge is sent.
|
||
|
||
The Response Identifier MUST be copied from the Identifier field
|
||
of the Challenge which caused the Response.
|
||
|
||
Value-Size
|
||
|
||
This field is one octet and indicates the length of the Value
|
||
field.
|
||
|
||
Value
|
||
|
||
The Value field is one or more octets. The most significant octet
|
||
is transmitted first.
|
||
|
||
The Challenge Value is a variable stream of octets. The
|
||
importance of the uniqueness of the Challenge Value and its
|
||
relationship to the secret is described above. The Challenge
|
||
Value MUST be changed each time a Challenge is sent. The length
|
||
of the Challenge Value depends upon the method used to generate
|
||
the octets, and is independent of the hash algorithm used.
|
||
|
||
The Response Value is the one-way hash calculated over a stream of
|
||
octets consisting of the Identifier, followed by (concatenated
|
||
with) the "secret", followed by (concatenated with) the Challenge
|
||
Value. The length of the Response Value depends upon the hash
|
||
algorithm used (16 octets for MD5).
|
||
|
||
|
||
|
||
|
||
Simpson [Page 8]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
Name
|
||
|
||
The Name field is one or more octets representing the
|
||
identification of the system transmitting the packet. There are
|
||
no limitations on the content of this field. For example, it MAY
|
||
contain ASCII character strings or globally unique identifiers in
|
||
ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
|
||
The size is determined from the Length field.
|
||
|
||
|
||
4.2. Success and Failure
|
||
|
||
Description
|
||
|
||
If the Value received in a Response is equal to the expected
|
||
value, then the implementation MUST transmit a CHAP packet with
|
||
the Code field set to 3 (Success).
|
||
|
||
If the Value received in a Response is not equal to the expected
|
||
value, then the implementation MUST transmit a CHAP packet with
|
||
the Code field set to 4 (Failure), and SHOULD take action to
|
||
terminate the link.
|
||
|
||
A summary of the Success and Failure packet format is shown below.
|
||
The fields are transmitted from left to right.
|
||
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Code | Identifier | Length |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Message ...
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-
|
||
|
||
Code
|
||
|
||
3 for Success;
|
||
|
||
4 for Failure.
|
||
|
||
Identifier
|
||
|
||
The Identifier field is one octet and aids in matching requests
|
||
and replies. The Identifier field MUST be copied from the
|
||
Identifier field of the Response which caused this reply.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 9]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
Message
|
||
|
||
The Message field is zero or more octets, and its contents are
|
||
implementation dependent. It is intended to be human readable,
|
||
and MUST NOT affect operation of the protocol. It is recommended
|
||
that the message contain displayable ASCII characters 32 through
|
||
126 decimal. Mechanisms for extension to other character sets are
|
||
the topic of future research. The size is determined from the
|
||
Length field.
|
||
|
||
|
||
|
||
Security Considerations
|
||
|
||
Security issues are the primary topic of this RFC.
|
||
|
||
The interaction of the authentication protocols within PPP are highly
|
||
implementation dependent. This is indicated by the use of SHOULD
|
||
throughout the document.
|
||
|
||
For example, upon failure of authentication, some implementations do
|
||
not terminate the link. Instead, the implementation limits the kind
|
||
of traffic in the Network-Layer Protocols to a filtered subset, which
|
||
in turn allows the user opportunity to update secrets or send mail to
|
||
the network administrator indicating a problem.
|
||
|
||
There is no provision for re-tries of failed authentication.
|
||
However, the LCP state machine can renegotiate the authentication
|
||
protocol at any time, thus allowing a new attempt. It is recommended
|
||
that any counters used for authentication failure not be reset until
|
||
after successful authentication, or subsequent termination of the
|
||
failed link.
|
||
|
||
There is no requirement that authentication be full duplex or that
|
||
the same protocol be used in both directions. It is perfectly
|
||
acceptable for different protocols to be used in each direction.
|
||
This will, of course, depend on the specific protocols negotiated.
|
||
|
||
The secret SHOULD NOT be the same in both directions. This allows an
|
||
attacker to replay the peer's challenge, accept the computed
|
||
response, and use that response to authenticate.
|
||
|
||
In practice, within or associated with each PPP server, there is a
|
||
database which associates "user" names with authentication
|
||
information ("secrets"). It is not anticipated that a particular
|
||
named user would be authenticated by multiple methods. This would
|
||
make the user vulnerable to attacks which negotiate the least secure
|
||
method from among a set (such as PAP rather than CHAP). If the same
|
||
|
||
|
||
|
||
Simpson [Page 10]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
secret was used, PAP would reveal the secret to be used later with
|
||
CHAP.
|
||
|
||
Instead, for each user name there should be an indication of exactly
|
||
one method used to authenticate that user name. If a user needs to
|
||
make use of different authentication methods under different
|
||
circumstances, then distinct user names SHOULD be employed, each of
|
||
which identifies exactly one authentication method.
|
||
|
||
Passwords and other secrets should be stored at the respective ends
|
||
such that access to them is as limited as possible. Ideally, the
|
||
secrets should only be accessible to the process requiring access in
|
||
order to perform the authentication.
|
||
|
||
The secrets should be distributed with a mechanism that limits the
|
||
number of entities that handle (and thus gain knowledge of) the
|
||
secret. Ideally, no unauthorized person should ever gain knowledge
|
||
of the secrets. Such a mechanism is outside the scope of this
|
||
specification.
|
||
|
||
|
||
Acknowledgements
|
||
|
||
David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
|
||
handshake at SDC when designing one of the protocols for a "secure"
|
||
network in the mid-1970s. Tom Bearson built a prototype Sytek
|
||
product ("Poloneous"?) on the challenge-response notion in the 1982-
|
||
83 timeframe. Another variant is documented in the various IBM SNA
|
||
manuals. Yet another variant was implemented by Karl Auerbach in the
|
||
Telebit NetBlazer circa 1991.
|
||
|
||
Kim Toms and Barney Wolff provided useful critiques of earlier
|
||
versions of this document.
|
||
|
||
Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
|
||
Steve Kent, for their extensive explanations and suggestions. Now,
|
||
if only we could get them to agree with each other.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 11]
|
||
|
||
RFC 1994 PPP CHAP August 1996
|
||
|
||
|
||
References
|
||
|
||
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
|
||
51, RFC 1661, DayDreamer, July 1994.
|
||
|
||
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
|
||
1700, USC/Information Sciences Institute, October 1994.
|
||
|
||
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
|
||
MIT Laboratory for Computer Science and RSA Data Security,
|
||
Inc., RFC 1321, April 1992.
|
||
|
||
|
||
|
||
Contacts
|
||
|
||
Comments should be submitted to the ietf-ppp@merit.edu mailing list.
|
||
|
||
This document was reviewed by the Point-to-Point Protocol Working
|
||
Group of the Internet Engineering Task Force (IETF). The working
|
||
group can be contacted via the current chair:
|
||
|
||
Karl Fox
|
||
Ascend Communications
|
||
3518 Riverside Drive, Suite 101
|
||
Columbus, Ohio 43221
|
||
|
||
karl@MorningStar.com
|
||
karl@Ascend.com
|
||
|
||
|
||
Questions about this memo can also be directed to:
|
||
|
||
William Allen Simpson
|
||
DayDreamer
|
||
Computer Systems Consulting Services
|
||
1384 Fontaine
|
||
Madison Heights, Michigan 48071
|
||
|
||
wsimpson@UMich.edu
|
||
wsimpson@GreenDragon.com (preferred)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Simpson [Page 12]
|
||
|
||
|