draft-ietf-opsawg-tacacs-10.txt   draft-ietf-opsawg-tacacs-11.txt 
Operations T. Dahm Operations T. Dahm
Internet-Draft A. Ota Internet-Draft A. Ota
Intended status: Informational Google Inc Intended status: Informational Google Inc
Expires: October 17, 2018 D. Medway Gash Expires: March 16, 2019 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
April 15, 2018 September 12, 2018
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-10 draft-ietf-opsawg-tacacs-11
Abstract Abstract
TACACS+ provides Device Administration for routers, network access TACACS+ provides Device Administration for routers, network access
servers and other networked computing devices via one or more servers and other networked computing devices via one or more
centralized servers. This document describes the protocol that is centralized servers. This document describes the protocol that is
used by TACACS+. used by TACACS+.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2018. This Internet-Draft will expire on March 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30
7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31
7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31
7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35
9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36
9.1. General Security of The Protocol . . . . . . . . . . . . 36 9.1. General Security of the Protocol . . . . . . . . . . . . 36
9.2. Security of Authentication Sessions . . . . . . . . . . . 38 9.2. Security of Authentication Sessions . . . . . . . . . . . 38
9.3. Security of Authorization Sessions . . . . . . . . . . . 38 9.3. Security of Authorization Sessions . . . . . . . . . . . 38
9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39 9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39
9.5. TACACS+ Client Implementation Recommendations . . . . . . 39 9.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39
9.6. TACACS+ Server Implementation Recommendations . . . . . . 39 9.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39
9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40 9.5.2. Connections and Obfuscation . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 9.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 9.5.4. Authorization . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 9.5.5. Redirection Mechanism . . . . . . . . . . . . . . . . 42
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Terminal Access Controller Access-Control System Plus (TACACS+) was Terminal Access Controller Access-Control System Plus (TACACS+) was
conceived initially as a general Authentication, Authorization and conceived initially as a general Authentication, Authorization and
Accounting protocol. It is primarily used today for Device Accounting protocol. It is primarily used today for Device
Administration: authenticating access to network devices, providing Administration: authenticating access to network devices, providing
central authorization of operations, and audit of those operations. central authorization of operations, and audit of those operations.
A wide range of TACACS+ clients and servers are already deployed in A wide range of TACACS+ clients and servers are already deployed in
skipping to change at page 19, line 26 skipping to change at page 19, line 26
The length of the challenge value can be determined from the length The length of the challenge value can be determined from the length
of the data field minus the length of the id (always 1 octet) and the of the data field minus the length of the id (always 1 octet) and the
length of the response field (always 16 octets). length of the response field (always 16 octets).
To perform the authentication, the server calculates the PPP hash as To perform the authentication, the server calculates the PPP hash as
defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then
compare that value with the response. The MD5 algorithm option is compare that value with the response. The MD5 algorithm option is
always used. The REPLY from the server MUST be a PASS, FAIL or always used. The REPLY from the server MUST be a PASS, FAIL or
ERROR. ERROR.
In cases where the client conducts the exchange with the endstation The selection of the challenge and its length are not an aspect of
and then sends the resulting materials (challenge and response) to the TACACS+ protocol. However, it is strongly recommended that the
the server, the selection of the challenge and its length are not an client/endstation interaction is configured with a secure challenge.
aspect of the TACACS+ protocol. However, it is strongly recommended The TACACS+ server can help by rejecting authentications where the
that the client/endstation interaction is configured with a secure challenge is below a minimum length (Minimum recommended is 8 bytes).
challenge. The TACACS+ server can help by rejecting authentications
where the challenge is below a minimum length (Minimum recommended is
8 bytes).
In cases where the TACACS+ Server generates the challenge then it
MUST change for every request and MUST be derived from a strong
cryptographic source.
4.4.2.4. MS-CHAP v1 login 4.4.2.4. MS-CHAP v1 login
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
minor_version = 0x1 minor_version = 0x1
The entire exchange MUST consist of a single START packet and a The entire exchange MUST consist of a single START packet and a
single REPLY. The START packet MUST contain the username in the user single REPLY. The START packet MUST contain the username in the user
field and the data field will be a concatenation of the PPP id, the field and the data field will be a concatenation of the PPP id, the
skipping to change at page 36, line 47 skipping to change at page 36, line 47
which will impact overall security of the protocol and systems where which will impact overall security of the protocol and systems where
this protocol is deployed to manage central authentication, this protocol is deployed to manage central authentication,
authorization or accounting for network device administration. authorization or accounting for network device administration.
Multiple implementations of the protocol described in the draft[1] Multiple implementations of the protocol described in the draft[1]
have been deployed. As the protocol was never standardized, current have been deployed. As the protocol was never standardized, current
implementations may be incompatible in non-obvious ways, giving rise implementations may be incompatible in non-obvious ways, giving rise
to additional security risks. This section does not claim to to additional security risks. This section does not claim to
enumerate all possible security vulnerabilities. enumerate all possible security vulnerabilities.
9.1. General Security of The Protocol 9.1. General Security of the Protocol
TACACS+ protocol does not include a security mechanism that would TACACS+ protocol does not include a security mechanism that would
meet modern-day requirements. Support for MD5-based crypto pad meet modern-day requirements. Support for MD5-based crypto pad
encryption fails to provide any kind of transport integrity, which encryption fails to provide any kind of transport integrity, which
presents at least the following risks: presents at least the following risks:
Accounting information may be modified by the man-in-the-middle Accounting information may be modified by the man-in-the-middle
attacker, making such logs unsuitable and untrustable for auditing attacker, making such logs unsuitable and untrustable for auditing
purposes. purposes.
Only the body of the request is encrypted which leaves all header Only the body of the request is obfuscated which leaves all header
fields open to trivial modification by the man-in-the-middle fields open to trivial modification by the man-in-the-middle
attacker. For this reason, connections with attacker. For this reason, deployments SHOULD NOT use connections
TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the
recommendations section. recommendations section.
Invalid or misleading values may be inserted by the man-in-the- Invalid or misleading values may be inserted by the man-in-the-
middle attacker in various fields at known offsets to try and middle attacker in various fields at known offsets to try and
circumvent the authentication or authorization checks even inside circumvent the authentication or authorization checks even inside
the encrypted body. the obfuscated body.
While the protocol provides some measure of transport privacy, it is While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks: vulnerable to at least the following attacks:
Brute force attacks exploiting increased efficiency of MD5 digest Brute force attacks exploiting increased efficiency of MD5 digest
computation. computation.
Known plaintext attacks which may decrease the cost of brute force Known plaintext attacks which may decrease the cost of brute force
attack. attack.
skipping to change at page 37, line 40 skipping to change at page 37, line 40
force attack. force attack.
No forward secrecy. No forward secrecy.
Even though, to the best knowledge of authors, this method of Even though, to the best knowledge of authors, this method of
encryption wasn't rigorously tested, enough information is available encryption wasn't rigorously tested, enough information is available
that it is best referred to as "obfuscation" and not "encryption". that it is best referred to as "obfuscation" and not "encryption".
For these reasons, users deploying TACACS+ protocol in their For these reasons, users deploying TACACS+ protocol in their
environments MUST limit access to known clients and MUST control the environments MUST limit access to known clients and MUST control the
security of the entire transmission path. Attacks who can guess the security of the entire transmission path. Attackers who can guess
key or otherwise break the obfuscation will gain unrestricted and the key or otherwise break the obfuscation will gain unrestricted and
undetected access to all TACACS+ traffic. Ensuring that a undetected access to all TACACS+ traffic. Ensuring that a
centralized AAA system like TACACS+ is deployed on a secured centralized AAA system like TACACS+ is deployed on a secured
transport is essential to managing security risk of such an attack. transport is essential to managing the security risk of such an
attack.
The following parts of this section enumerate only the session- The following parts of this section enumerate only the session-
specific risks which are in addition to general risk associated with specific risks which are in addition to general risk associated with
bare obfuscation and lack of integrity checking. bare obfuscation and lack of integrity checking.
9.2. Security of Authentication Sessions 9.2. Security of Authentication Sessions
Authentication sessions SHOULD NOT be used via insecure transport as Authentication sessions SHOULD be used via a secure transport as the
the man-in-the-middle attack may completely subvert them. Even CHAP, man-in-the-middle attack may completely subvert them. Even CHAP,
which may be considered resistant to password interception, is unsafe which may be considered resistant to password interception, is unsafe
as it does not protect the username from a trivial man-in-the-middle as it does not protect the username from a trivial man-in-the-middle
attack. attack.
This document deprecates the redirection mechanism using the This document deprecates the redirection mechanism using the
TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
original draft. As part of this process, the secret key for a new original draft. As part of this process, the secret key for a new
server was sent to the client. This public exchange of secret keys server was sent to the client. This public exchange of secret keys
means that once one session is broken, it may be possible to leverage means that once one session is broken, it may be possible to leverage
that key to attacking connections to other servers. This mechanism that key to attacking connections to other servers. This mechanism
SHOULD NOT be used in modern deployments. It MUST NOT be used SHOULD NOT be used in modern deployments. It MUST NOT be used
outside a secured deployment. outside a secured deployment.
9.3. Security of Authorization Sessions 9.3. Security of Authorization Sessions
Authorization sessions MUST be used via secure transport only as it's Authorization sessions SHOULD be used via a secure transport as it's
trivial to execute a successful man-in-the-middle attacks that trivial to execute a successful man-in-the-middle attacks that
changes well-known plaintext in either requests or responses. changes well-known plaintext in either requests or responses.
As an example, take the field "authen_method". It's not unusual in As an example, take the field "authen_method". It's not unusual in
actual deployments to authorize all commands received via the device actual deployments to authorize all commands received via the device
local serial port (a console port) as that one is usually considered local serial port (a console port) as that one is usually considered
secure by virtue of the device located in a physically secure secure by virtue of the device located in a physically secure
location. If an administrator would configure the authorization location. If an administrator would configure the authorization
system to allow all commands entered by the user on a local console system to allow all commands entered by the user on a local console
to aid in troubleshooting, that would give all access to all commands to aid in troubleshooting, that would give all access to all commands
skipping to change at page 39, line 26 skipping to change at page 39, line 26
systems behave in unintended ways (which includes TACACS+ server systems behave in unintended ways (which includes TACACS+ server
and any other systems that would manage accounting entries). and any other systems that would manage accounting entries).
In addition to these direct manipulations, different client In addition to these direct manipulations, different client
implementations pass different fidelity of accounting data. Some implementations pass different fidelity of accounting data. Some
vendors have been observed in the wild that pass sensitive data like vendors have been observed in the wild that pass sensitive data like
passwords, encryption keys and similar as part of the accounting log. passwords, encryption keys and similar as part of the accounting log.
Due to lack of strong encryption with perfect forward secrecy, this Due to lack of strong encryption with perfect forward secrecy, this
data may be revealed in future, leading to a security incident. data may be revealed in future, leading to a security incident.
9.5. TACACS+ Client Implementation Recommendations 9.5. TACACS+ Best Practices
The following recommendations are made when implementing a TACACS+ With respect to the observations about the security issues described
client: above, a network administrator MUST NOT rely on the obfuscation of
the TACACS+ protocol and TACACS+ MUST be deployed over networks which
ensure privacy and integrity of the communication. TACACS+ MUST be
used within a secure deployment. Failure to do so will impact
overall network security.
Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks The following recommendations impose restrictions on how the protocol
that are considered secure. is applied. These restrictions were not imposed in the original
draft. New implementations, and upgrades of current implementations,
MUST implement these recommendations.
Treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 9.5.1. Shared Secrets
TAC_PLUS_AUTHEN_STATUS_FAIL.
If receiving an unknown mandatory authorization attribute, behave TACACS+ servers and clients MUST treat shared secrets as sensitive
as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. data to be managed securely, as would be expected for other sensitive
data such as identity credential information. TACACS+ servers MUST
not leak sensitive data. For example, TACACS+ servers should not
expose shared secrets in logs.
9.6. TACACS+ Server Implementation Recommendations TACACS+ servers MUST allow a dedicated secret key to be defined for
each client.
The following recommendations are made when implementing a TACACS+ TACACS+ servers SHOULD warn administrators if secret keys are not
server: unique per client.
The Server SHOULD NOT accept any connections which have the TACACS+ server administrators SHOULD always define a secret for each
TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with client.
applicable ERROR response for type of packet.
The configuration of dedicated secret keys per individual client MUST TACACS+ servers and clients MUST support shared keys that are at
be supported by the Server implementation. It is also recommended least 32 characters long.
that Servers SHOULD warn administrators if secret keys are not unique
per client.
If an invalid shared secret is detected, Servers MUST NOT accept any TACACS+ clients SHOULD NOT allow servers to be configured without
new sessions on a connection, and terminate the connection on shared secret key, or shared key that is less than 16 characters
completion of any sessions previously established with a valid shared long.
secret.
The Server implementation must allow the administrator to mandate: TACACS+ server administrators SHOULD configure secret keys of minimum
16 characters length.
TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type TACACS+ server administrators SHOULD change secret keys at regular
intervals.
TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization 9.5.2. Connections and Obfuscation
Minimum length for shared secrets. TACACS+ servers MUST allow the definition of individual clients. The
servers MUST only accept network connection attempts from these
defined, known clients.
9.7. TACACS+ Deployment Best Practices TACACS+ servers MUST reject connections with
TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on
the server for the client requesting the connection.
Due to above observations about the TACACS+ protocol, it is critical If an invalid shared secret is detected when processing packets for a
to only deploy it using secure transport. A secure transport for client, TACACS+ servers MUST NOT accept any new sessions on that
TACACS+ is defined as any means that ensure privacy and integrity of connection. TACACS+ servers MUST terminate the connection on
all data passed between clients and servers. There are multiple completion of any sessions that were previously established with a
means of achieving this, all of them beyond the scope of this valid shared secret on that connection.
document.
Symmetric encryption key represents a possible attack vector at the TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret
protocol itself. For this reason, servers SHOULD accept only those is defined. Clients MUST be implemented in a way that requires
network connection attempts that arrive from known clients. This explicit configuration to enable the use of
limits the exposure and prevents remote brute force attacks from TAC_PLUS_UNENCRYPTED_FLAG.
unknown clients.
Due to the security deficiencies of the protocol, it is critical that When a TACACS+ client receives responses from servers where:
it be deployed in a secure manner. The following recommendations are
made for those deploying and configuring TACACS+ as a solution for
device administration:
Secure the Deployment: TACACS+ MUST BE deployed over networks the response packet was received from the server configured with
which ensure an appropriate privacy and integrity of the shared key, but the packet jas TAC_PLUS_UNENCRYPTED_FLAG set.
communication. The way this is ensured will depend upon the
organizational means: a dedicated and secure management network
where available in enterprise deployments, or IPsec where
dedicated networks are not available.
Do not use the TAC_PLUS_UNENCRYPTED_FLAG option. the response packet was received from the server configured not to
use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not
set.
Always configure a secret key (recommended minimum 16 characters) then the TACACS+ client MUST close TCP session, and process the
on the server for each client. response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL
(authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL
(authorization sessions) was received.
Consider shared secrets to be sensitive data, and manage securely 9.5.3. Authentication
on server and client.
Change secret keys at regular intervals. To allow TACACS+ administraots to select the stronger authentication
options, TACACS+ servers MUST allow the administrator to configure
the server to only accept challenge/response options for
authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type).
Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS TACACS+ server administrators SHOULD enable the option mentioned in
options. the previous paragraph. TACACS+ Server deployments SHOULD ONLY
enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or
TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of
identity/password systems.
Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type TACACS+ server administrators SHOULD NOT allow the same credentials
where possible. Use other options only when unavoidable due to to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or
requirements of identity/password systems. TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non
challenge-based authen_type options as the insecurity of the latter
will compromise the security of the former.
Require TACACS+ authentication for authorization requests (i.e. TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options
TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). mentioned in the original draft SHOULD not be used, due to their
security implications. TACACS+ servers SHOULD NOT implement them.
If they must be implemented, the servers MUST default to the options
being disabled and MUST warn the administrator that these options are
not secure.
Do not use the redirection mechanism 9.5.4. Authorization
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). Specifically avoid the option to
send secret keys in the server list.
Take case when applying extensions to the dictionary of The authorization and accounting features are intended to provide
authorization/accounting arguments. Ensure that the client and extensibility and flexibility. There is a base dictionary defined in
server use of new argument names are consistent. this document, but it may be extended in deployments by using new
attribute names. The cost of the flexibility is that administrators
and implementors MUST ensure that the attribute and value pairs
shared between the clients and servers have consistent
interpretation.
In summary: It is strongly advised that TACACS+ MUST be used within a TACACS+ clients that receive an unrecognised mandatory attribute MUST
secure deployment. Failure to do so may impact overall network evaluate server response as if they received
security. TAC_PLUS_AUTHOR_STATUS_FAIL.
9.5.5. Redirection Mechanism
The original draft described a redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to
secure. The option to send secret keys in the server list is
particularly insecure, as it can reveal client shared secrets.
TACACS+ servers SHOULD deprecate the redirection mechanism.
If the redirection mechanism is implemented then TACACS+ servers MUST
disable it by default, and MUST warn TACACS+ server administrators
that it must only be enabled within a secure deployment due to the
risks of revealing shared secrets.
TACACS+ clients SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank the following reviewers whose The authors would like to thank the following reviewers whose
comments and contributions made considerable improvements to the comments and contributions made considerable improvements to the
document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch,
Robert Drake, among many others. Robert Drake, among many others.
The authors would particularly like to thank Alan DeKok, who provided The authors would particularly like to thank Alan DeKok, who provided
significant insights and recommendations on all aspects of the significant insights and recommendations on all aspects of the
document and the protocol. Alan DeKok has dedicated considerable document and the protocol. Alan DeKok has dedicated considerable
effort to identify weaknesses and provide remedies to help improve time and effort to help improve the document, identifying weaknesses
the document. and providing remediation.
The authors would also like to thanks the support from the OPSAWG The authors would also like to thanks the support from the OPSAWG
Chairs and advisors. Chairs and advisors.
11. References 11. References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
skipping to change at page 42, line 39 skipping to change at page 43, line 34
US US
EMail: thorstendlux@google.com EMail: thorstendlux@google.com
Andrej Ota Andrej Ota
Google Inc Google Inc
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
EMail: aota@google.com EMail: andrej@ota.si
Douglas C. Medway Gash Douglas C. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +44 0208 8244508
EMail: dcmgash@cisco.com EMail: dcmgash@cisco.com
David Carrel David Carrel
vIPtela, Inc. vIPtela, Inc.
1732 North First St. 1732 North First St.
San Jose, CA 95112 San Jose, CA 95112
US US
EMail: dcarrel@viptela.com EMail: dcarrel@viptela.com
Lol Grant Lol Grant
 End of changes. 47 change blocks. 
109 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/