Integrated Authentication for Windows VPN clients ================================================== Proposal -------- To leverage existing software to form an integrated VPN authentication solution, allowing Windows clients to connect to the VPN using existing Microsoft software on the client, and allowing the users to connect with their existing, centrally managed user-name and password. To do this using free software, without per-client licensing. And to do this on a Unix platform. VPN Technologies ---------------- The world is full of different VPN technologies. Microsoft's chosen implementation is PPTP, the Point to Point Tunneling Protocol, but there are many others - from simple hacks PPP over SSH to much more elegant (and secure) systems like CIPE. MSCHAPv2, and where it fits in. ------------------------------- Microsoft has implemented extensions to PPP - the basis behind PPTP to use their own authentication system, with characteristics suitable for their NT Domain architecture. MSCHAP stands for 'MicroSoft Challenge Handshake Authentication Protocol' and is an authentication extension to PPP. MSCHAP comes in two flavors - v1 and v2. Both are designed so that they may operate on servers in a Windows NT4 domain, and forward the actual authentication question to that 'domain controller', the logical center of an MS network. In particular, these protocols use the existing passwords stored on the DC - no per-user intervention is required. Currently, software exists for Linux that will use this protocol to authenticate users. However, no way to authenticate against an NT Domain exists. Primary Task ------------ The primary task of this project is to take existing software, each part already able to complete one part of the chain, and link them in such a way that this integrated authentication becomes possible. Requirements ============ As this is a Software Engineering project, there are a number requirements: A final report will describe the operation of the MSCHAPv2 authentication sub-protocol, the integration of the software components, the unit testing of the components and the integration testing of the complete chain. Software Deliverables -------------------- The software deliverables shall be: - A patch to Samba 3.0alpha that implements the required interface changes. - A patch to Linux pppd to use the new interface in it's MSCHAPv2 internals. The software delivered should not only be operable as per comparative testing with the equivalent Microsoft product, it should be written securely (ie, with a mind to buffer overflows and other privilege elevation issues) and be no more difficult to configure than the existing components. Testing ------- The report will detail the testing process undertaken, both in informal exploratory testing, and in more formal regression testing. Particular care will need to be taken in the testing of the various client implementations, and the various types of PDC (Primary Domain Controller, the logical center of a Microsoft network) that we might authenticate against. Incompatibilities - both already known and newly discovered - will be detailed in the administrator's reference. An automated test framework will be constructed to cover some simple cases (primarily Linux-Linux), and the manual testing process will be detailed in such a way that others can verify the operation of the software in the future. It is intended that the resultant software will be unit-tested with Samba 3.0, NT4, Win2k and Win2003 RC2 domain controllers, and Linux, Win98, Win2k and Win2003 clients. Integration testing will be done between a reasonable subset of the above. Documentation ------------- Protocols and Interfaces ------------------------ The operation of the MSCHAPv2 authentication sub-protocol will be described in the style of 'Implementing CIFS'. That is, I will prepare a tutorial describing how to build a basic MSCHAPv2 client and server. The formalized specification of the protocol is already available as an RFC, and will not be repeated. The context of NTLM authentication will be explained, to give the reader an understanding of 'why we need another authentication protocol'. The ntlm_auth interface will be documented, in such a way that other programmers will be able to use it for their own integration problems, and that system's administrators will understand it's role on their servers. The interactions of the various components will be described, both in terms of each interface, and in terms of the integrated whole. However, the operation of the protocols behind each interface will not be described in this document. Further Documentation --------------------- Tutorial on the installation and operation of this software ----------------------------------------------------------- I will provide adequate documentation to allow a competent administrator to correctly configure the 3 pieces of software required to make this system function - that being 'PoPToP', the modified 'pppd' and the appropriate release of Samba 3.0 alpha. I will also provide documentation on the steps required to configure a Windows client to use this service. Both these documents will also form the background for the testing methodology. Other documentation ------------------- Further documentation may be provided, looking into the problems caused by a Denial Of Service attack, and considering ways in which this might be sensibly minimized. Thought should be given to the problem of 'is this just a heavy user, or an attack' Likewise, a survey of other integration projects and opportunities will be conducted, primarily looking at NTLMSSP. (Which will also be described briefly). Project Plan -------------------------------- In order to for-fill the requirements for this unit, I intend to do the following: - Obtain the existing software intended to be used for this project, including copies of various Microsoft Operating Systems (I can provide this via my MSDN subscription) - Setup a test servers, at uni and at home. (1 week) - Document the existing free-software efforts in this area - Not only MSCHAP implementations, but also NTLMSSP users. (1 week) - Initially, test the existing software involved. - confirm the state of the pppd, ntlm_auth and winbind components - Confirm client compatibility with pppd 2.4.2's MSCHAPv2. (1 week initial testing with various clients) - Develop the links between the software components, as described above, and as far as possible in line with the existing design. - Document the ntlm_auth interface, and the interactions it performs. - Including the NTLMSSP interface, but not NTLMSSP itself. (1 week combined) - Maintain the patch to the various peices of software, until accepted, or the conclusion of the project (negligable) - Include a detailed description of how MSCHAPv2 functions, in line with the similar descriptions in 'Implementing CIFS' (www.ubiqx.org/cifs). (1 week) - Perform unit testing on the individual components. (1 week) - Perform integration testing on the resultant software chain, using this process to prepare the client documentation. (2 weeks) - Where possible (primarily for Linux-Linux situations) script this testing. (1 week) - Final report (2 weeks) Risk Assessment --------------- There are a number of risks involved in this project - as there are in any project. Those that have already been identified are: - Ethereal may not correctly parse PPPTP, or all the sub-protocols (2 weeks for worst-case for the construction of a solid protocol dissector, given an existing pppoe dissector) - The extensions to Linux pppd may not be complete - In particular, there is concern that error returns, the 'must change password' return in particular, might not be implemented. - It is expected that the 'change password' packets are not implemented at all. - The risk here is that we might actually need it. (2 weeks for worse-case protocol re-implementation) - The cryptographic code in pppd may not be complete, or may not be amenable to outsourcing the appropriate parts of the computation. (1/2 week worst-case to implement the hooks) - That Samba may not correctly contact the domain controller, or may not be able to recover the 'session key' correctly. - These are considered to be low probability, but if they occur, they could be very hard to work around, or may require changes to the domain controller. (3-4 weeks if existing 'schannel' code in Samba TNG is appropriate, abandon if this won't fix it) - That Samba or pppd might change significantly during developemnt, and require that the work performed be redone. (1 week worse-case) - That components of the system may not be reliable in operation - Winbindd is considered solid at this stage, as is pppd and PoPToP in general, but the specific MSCHAPv2 code is much less likely to be tested. (this vague risk is very hard to judge in terms of cost)