draft-cam-winget-eap-fast-provisioning-02.txt

linux 下通过802.1认证的安装包

  as a normal EAP-FAST exchange: with an anonymous Identity for a peer 
  and the server determining that EAP-FAST authentication is to occur, 
  the EAP server MUST respond with an EAP-FAST/Start packet.  Assuming 
  that the peer supports EAP-FAST and the peer has no PAC provisioned 
  on its device, the peer shall send an EAP-Response packet with EAP-
  Type=EAP-FAST.    
   
  On receipt of the EAP-FAST Start message, the peer determines it must 
  be provisioned with a fresh PAC.  Further, the peer determines 
  whether it must invoke a signed or anonymous DH exchange. 
   
  To provide best security practices, it is highly recommended that the 
  peer obtain the server抯 public key or trust anchor to enable server-
  side authentication.  However, as the provisioning of the public key 
  or trust anchor must also be secured to ensure the public key is to 
  be trusted, some deployments may be willing to trade off the security 
  risks for ease of deployment.   
   
  The peer and server establish the EAP-FAST tunnel for provisioning in 
  the same exchanges as that defined for EAP-FAST authentication [EAP-
  FAST].  With a successful EAP-FAST Phase 1 tunnel established, 
  subsequent messages exchanged between peer and authentication server 
  are protected using TLS cipher suites as defined by both [RFC 2246] 
  and [RFC 3268] to provide message confidentiality and integrity 
  respectively.   
   
  With a protected tunnel, the peer must now authenticate itself to the 
  server before the server can provision it with a PAC.  To ensure some 
  means for authentication and to protect such authentication from 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 6] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  exposure, the provisioning EAP-FAST exchange requires mutual 
  authentication.  For instance, [MSCHAPv2] may be used to achieve 
  mutual authentication before any credentials or information can be 
  provisioned.  If an anonymous DH exchange ensued to establish the 
  tunnel or if the peer was unable to validate the authenticated DH 
  exchange, the MSCHAPv2 exchange is susceptible to an active server-
  side dictionary attack.  However, as it enables in-band provisioning 
  at the cost of some loss in security strength, it is an option to 
  afford a means for facilitating a deployment with minimal to no 
  client (peer) configuration.  To minimize exposure of the active 
  dictionary attack, it is recommended that the anonymous DH 
  provisioning EAP-FAST conversation be used only once;  further 
  provisioning or updates of the PAC should be done by means of the 
  EAP-FAST PAC refreshing protocol or through some other (manual or 
  out-of-band) mechanisms.   
   
  The client authentication proceeds by the peer and authentication 
  server engaging in an MSCHAPv2 conversation using invoking the same 
  EAP-FAST Phase 2 MSCHAPv2 conversation.  To further mitigate man-in-
  the-middle attacks in the Server-Unauthenticated Provisioning Mode, 
  the challenges provided by the peer and authentication server are 
  generated as part of the TLS establishment in the EAP-FAST 
  provisioning exchange and conveyed as the Server and Client 
  Challenges requested by MSCHAPv2.  Further, the random challenges are 
  not conveyed in the actual MSCHAPv2 messages, the messages shall 
  replace the fields with zeroes to obscure the actual values used to 
  generate the challenge responses. 
   
  Following a successful MSCHAPv2 authentication exchange and 
  successful Intermediate Result TLV and Crypto-Binding TLV exchange, 
  the server can then provision the peer with a unique PAC.  The 
  provisioning is invoked through the same mechanism as in PAC 
  refreshment:  a PAC-TLV exchange is executed following the successful 
  MSCHAPv2 exchange including the Intermediate Result TLV and Crypto-
  Binding TLV exchange, with the server distributing the PAC in a 
  corresponding PAC TLV to the peer and the peer confirming its receipt 
  in a final PAC TLV Acknowledgement message. 
   
   
3.1 Network Access after EAP-FAST Provisioning 
   
  Depending on server policy, network access can be granted or denied 
  based on the EAP-FAST Provisioning mode, the credential(s) or other 
  information that have been provisioned, and the inner EAP methods 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 7] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  used. For example, in the Server-Authenticated Provisioning Mode, 
  access can be granted after the EAP server has authenticated the peer 
  and provisioned the peer with a Tunnel PAC (e.g. a PAC used to 
  mutually authenticate the EAP-FAST tunnel). 
 
 
  Additionally, peer policy may also be used to disconnect the current 
  provisioning connection and initiate a new EAP-FAST exchange for 
  authentication utilizing the newly provisioned information and ensure 
  the inner methods are conducted with the trusted server.  The peer 
  policy may be required as the peer determines whether it can 
  authenticate the EAP Server.  In the case where a peer lacks the 
  trust anchors to validate the server抯 certificate, the peer SHOULD 
  negotiate the TLS_DH_anon_WITH_AES_128_CBC_SHA to signal the EAP 
  server that it lacks the trust anchors to authenticate the server.  
 
  At the end of the Server-Unauthenticated Provisioning Mode, network 
  access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP 
  Failure to acknowledge that this conversation was intended for 
  provisioning only and thus no network access is authorized. Upon 
  completion of the exchange, the EAP Server SHALL NOT grant network 
  access or distribute any session keys to the NAS as this phase is not 
  intended to provide network access.  Even though provisioning mode 
  completes with a successful inner termination (e.g. successful Result 
  TLV), server policy defines whether the peer gains network access or 
  not.  Thus, it is feasible for the server, while providing a 
  successful Result TLV may conclude with an EAP Failure. 
   
  The EAP-FAST server, when denying network access after EAP-FAST 
  Provisioning, may choose to instead, immediately invoke another EAP-
  FAST Start and thus initiate the EAP-FAST Phase 1 conversation.  This 
  server based implementation policy may be chosen to avoid 
  applications such as wireless devices from being disrupted (e.g. in 
  802.11 devices, an EAP Failure may trigger a full 802.11 
  disassociation) and allow them to smoothly transit to the subsequent 
  EAP-FAST authentications to enable network access. 
 
  Similarly, if Server-Authenticated Provisioning Mode is used and the 
  server policy is to disallow network access, the EAP Server SHALL NOT 
  grant network access or distribute any session keys to the NAS as 
  this phase is not intended to provide network access.  Even though 
  provisioning mode completes with a successful inner termination (e.g. 
  successful Result TLV), the EAP-FAST Server-Authenticated 
  Provisioning Mode MUST conclude with an EAP Failure to acknowledge 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 8] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  that this conversation was intended for provisioning only and thus no 
  network access is authorized.  The EAP-FAST server may choose to 
  instead, immediately invoke another EAP authentication transaction.  
 
 
3.2 Authenticating Using EAP-MSCHAPv2 
   
  While other authentication methods exist to achieve mutual 
  authentication, when using an anonymous or unauthenticated TLS tunnel, 
  MSCHAPv2 was chosen for several reasons: 
   
    . Afford the ability of slowing an active attack by obscuring the 
      password through some hash 
   
    . Especially in the Server-Unauthenticated EAP-FAST Provisioning 
      conversation MSCHAPv2 affords the ability to detect, based on 
      the challenge responses, whether there is a possible attack. 
   
    . It is understood that a large deployed base is already able to 
      support MSCHAPv2 
   
    . MSCHAPv2 is picked in order to slow the active dictionary attack 
      relative to MSCHAPv1. 
   
    . Allow support for password change during the EAP-FAST 
      Provisioning protocol.  
   
  The MSCHAPv2 exchange forces the server to provide a valid 
  ServerChallengeResponse which must be a function of the server 
  challenge, client challenge and password as part of its response.  
  This reduces the window of vulnerability in the EAP-FAST for in-band 
  provisioning protocol to force the man-in-the-middle, acting as the 
  server, to successfully break the password within the client抯 
  challenge response time limit. 
   
  EAP-FAST for provisioning MUST support MSCHAPV2 as the inner method 
  when using an anonymous DH key agreement.  However, with support of 
  signed DH key agreement, the provisioning protocol of EAP-FAST may 
  support other methods such as EAP-GTC to enable peers (using other 
  password databases such as LDAP and OTP) to be provisioned in-band as 
  well.  However, the replacement may only be achieved when used with 
  the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite to ensure no loss 
  in security. 
   
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 9] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  When using an anonymous DH key agreement and MSCHAPv2, a binding 
  between the tunnel and the MSCHAPv2 exchanges is formed by using 
  keying material generated during the EAP-FAST tunnel establishment as 
  the MSCHAPv2 challenges.  A detailed description of the challenge 
  generation is described in Section 3.4. 
   
   
3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning 
 
  Once a protected tunnel is established, the peer must authenticate 
  itself to the server before the server can provision the peer. When 
  using TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite in the EAP-FAST 
  Phase 1 conversation, an EAP method providing both mutual 
  authentication and keying material MUST be employed.   
   
  EAP-MSCHAPv2 is an inner method that MUST be supported for Dynamic 
  Provisioning in EAP-FAST. The MSCHAPv2 exchange forces the server to 
  provide a valid ServerChallengeResponse which must be a function of 
  the server challenge, client challenge and password as part of its 
  response.  This reduces the window of vulnerability in this 
  provisioning mode to force the man-in-the-middle, acting as the 
  server, to successfully break the password within the client抯 
  challenge response time limit, or it raises the ability to detect if 
  an MitM attacker is capturing the MSCHAPv2 exchange without 
  responding for the purpose of affecting an off-line dictionary attack 
  on the password.  
   
  As a result of not authenticating the server in Phase 1 and potential 
  MITM attacks in the Server-Unauthenticated Provisioning Mode, an EAP 
  method with equal or better protection than EAP-MSCHAPv2 MUST be used 
  in Phase 2. 
 
  With the use of additional TLS cipher suites, especially when server 
  authenticity is verified as part of the TLS tunnel establishment, 
  other inner EAP methods with weaker protection than EAP-MSCHAPv2 can 
  be used safely inside tunnel. Hence, in addition to EAP-MSCHAPV2 as 
  the inner method, EAP-GTC MAY be used in Server-Authenticated 
  Provisioning Mode. This will enable peers using other user databases 
  such as LDAP and OTP to be provisioned in-band as well.  However, the 
  replacement may only be achieved when used with the TLS cipher suites 
  that ensure server authentication, such as 
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA, to ensure no loss in security.  
 

 
 
Cam-Winget, et al.   Expires September 5, 2006           [Page 10] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  Dynamic Provisioning EAP-FAST MUST support both EAP-GTC and EAP-MS-
  CHAPv2 within the tunnel in Server-Authenticated Provisioning Mode. 
 
  It should be noted that Server-Authenticated Provisioning Mode  
  provides significant security advantages over Server-Unauthenticated  
  Provisioning even when EAP-MSCHAPv2 is being used as inner method. It 
  protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by 
  verifying server抯 authenticity before exchanging MSCHAPv2. Thus 
  Server-Authenticated Provisioning Mode is the preferred provisioning 
  mode. The EAP-FAST peer MUST use the Server-Authenticated 
  Provisioning Mode whenever a certificate or (server抯) public key is 
  available to authenticate the server, in order to ensure best 
  security practices. 
   
   
   
   
   
 
3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange 
   
  When generating keys in the EAP-FAST Provisioning conversation, the 
  DH computation is used as the pre_master_secret and is converted into 
  the master_secret as specified by [RFC 2246]: 
   
  For the client: 
    pre_master_secret = (DH_Ys)^peer-private-DH-key mod DH_p   
     
  For the server: 
    pre_master_secret = (DH_Yc)^server-private-DH-key mod DH_ 
     
  master_secret = PRF(pre_master_secret, 搈aster secret