A problem of EAP-TTLS

[Du-lumos]

Recently,I need to write EAP-TTLS's server, my company used BounyCastle to implement PEAP'server、TLS's server. During the development of TTLS, i find that i back a accept packet, but ac show the "authentication fail". I checked packet 、username、password，but nothing exception.
I doubt material key has some of problems.
E is there any special difference between TTLS and PEAP in the handshake phase when using Bouncy Castle, except for generating the label of the key material and the client_random and server_random's order.,
This my implement: in notifyHandshakeComplete()

public static MPPEKeys deriveMPPEKeysByTlsContext(TlsContext tlsContext , AccessRequest accessRequest) { MPPEKeys derivedMPPEKeys = new MPPEKeys(); byte[] keyMaterial = null; if (TLS_VER_10.equals(tlsContext.getClientVersion().getName())) { keyMaterial = exportKeyingMaterial(ExporterLabel.ttls_keying_material, null, 64, tlsContext.getSecurityParametersConnection() , null); } else { keyMaterial = tlsContext.exportKeyingMaterial(ExporterLabel.ttls_keying_material, null, 128); } byte[] recvKey = new byte[32]; byte[] sendKey = new byte[32]; System.arraycopy(keyMaterial, 0, recvKey, 0, 32); System.arraycopy(keyMaterial, 32, sendKey, 0, 32); derivedMPPEKeys.setRecvKey(recvKey); derivedMPPEKeys.setSendKey(sendKey); return derivedMPPEKeys; }

[peterdettman]

Not sure on your actual question, but if you are trying to use different code when TLS 1.0 is negotiatied, then:

if (TLS_VER_10.equals(tlsContext.getClientVersion().getName()))

should probably be:

if (!TlsUtils.isTLSv11(tlsContext))

[Du-lumos]

Not sure on your actual question, but if you are trying to use different code when TLS 1.0 is negotiatied, then:

if (TLS_VER_10.equals(tlsContext.getClientVersion().getName()))

should probably be:

if (!TlsUtils.isTLSv11(tlsContext))

Hello , I hope you've enjoyed a good day.
We were coded that 'if (TLS_VER_10.equals(tlsContext.getClientVersion().getName()))' , because we find a bug of BC's TLS handshake in TLS authentication. But i'm so sorry, i forget the context. And just now, i solve my problem.
In TTLS authentication,the client_random and server_random should draw in BC Handshake Process's notifySecureRenegotiation(). But But I don't know exactly why.
The code:
byte[] clientRandom;
byte[] serverRandom;
@Override public void notifySecureRenegotiation(boolean secureRenegotiation) { clientRandom = getTlsContext().getSecurityParametersHandshake().getClientRandom(); serverRandom = getTlsContext().getSecurityParametersHandshake().getServerRandom(); }

@OverRide
public void notifyHandshakeComplete() {
try {
byte[] seed = calculateExporterSeed(clientRandom, serverRandom, null);
derivedMPPEKeys = MPPEUtils.deriveMPPEKeysByTlsContext(getTlsContext(), seed);
} catch (Exception e) {
e.printStackTrace();
}
}

[peterdettman]

I am happy you got this working, but it is a very strange fix. The calculation should not give a different result from doing it all in notifyHandshakeComplete.

[Du-lumos]

Yeah,it's strange fix. I doubt that TTLS is called 'tunnel tls', and them client_random and server_random should be draw in the tunnel handshake process, rather than the tunnel handshake complele.
A significate difference in the BouncyCastle, In handshake process, we want to get the server/client random from 'getTlsContext().getSecurityParametersHandshake().getClientRandom();',but after the handshake complete,we want to get the server/client random from tlsContext.getSecurityParametersConnection().getClientRandom().

[peterdettman]

If you check the values of clientRandom/serverRandom you should see that the value is the same for both ways.

[Du-lumos]

If you check the values of clientRandom/serverRandom you should see that the value is the same for both ways.

Yeah, it's different

[winfriedgerlach]

@peterdettman @Du-lumos can this ticket be closed?