Re: [TLS] Comments on TLS identity protection

[<home_pw@xxxxxxx>]

> <home_pw@xxxxxxx> wrote:
> > TLS does indeed forbid the _negotiation_ of this defined
> > ciphersuite. (This is
> > why I phrased my claim in terms of SSLv3, which allows it.
>
> Another way of looking at this is that it's a bug in the
> SSLv3 spec that was fixed in TLS. Are you aware of any
> implementation that in fact allows you to negotiate this
> cipher suite?

I see no reason to see why one should not evaluate EAP-TLS as being
other containing a valid TLS protocol run. While RFC 2716 is marked
experimental, I see no non-standard uses of TLS. The custom
key derivation is in the EAP-TLS layer, assumes access
to the master_secret and nonces in much the same way as NSA/Eric are
proposing in current standards work on PRFs, here. The derivation
is not part of the SSL security state.

So, upon change cipher spec selecting the null ciphersuite, 
we know this has no impact on the EAP-TLS key derivation
for the per-connection keys/ivs/secrets. It does
however set the mechanism requirements for the PPP 
peer, when then negotiating ECP - if required.

So, when EAP-TLS simply do mutual auth, not requiring
any ECP SA session keys, do folks negotiate the NULL ciphersuite, or
do they negotiate the RSA ciphersuite and then just ignore the rule
carrying forward the TLS Connection state to the ECP state?


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls