I see no reason why TLS ciphers/ciphersuites should not facilitate key exchange or key derivation based on traditional key stream lookups (e.g. an OTP algorithm). This is really no different architecturally to the use of UKMs, in NSA/DoD processes for govt-grade TLS ciphersuites, to vary the the mac/enc TEKs formulated by asymmetric processes byuser/bytime. Whereas a modern UKM modifies the process of TEK key derivation by moderating the asymmetric process generating the DerivedSessionToken, OTP streams could alternatively moderate external-time-synced tek generation(s) that do specifically to NOT rely on asymmetric algorithms.
I've already seen this happen in the TLS-like handshakes used in the OASIS ws-* family, when handling equivalent session token generation processes. I.e. time synced key derivation processes influencing the TEKs in the derivedSessionToken resulting from a SSL-like handshake based on prior _symmetric_ key distribution to endpoints, only. The linking of external time to the keys protecting security contexts of course impacts the evidentiary value of PDUs. This is arguably far more valuable in internal, (sub)layer 7 security contexts (the ssl-like xml handshake's flowing over ws-reliablemessaging or X.400 RTS in Nato nets), than layer 4 contexts (https/ssl flows over tcp on the public Internet).
> Date: Mon, 2 Oct 2006 11:51:23 +0200
> From: magnus <at> rsasecurity.com
> To: tls <at> ietf.org
> CC:
> Subject: [TLS] Follow-up to comments on draft-linn-otp-tls-00
>
> All,
>
> I would like to follow-up on some of the comments that John and I have
> received in the past and also received during the TLS session at the 66th
> IETF in Montreal. Firstly, I'd like to thank all the reviewers; we really
> appreciate you taking the time.
>
> Whether to layer on TLS-PSK or not
> ----------------------------------
> Several reviewers have suggested that it would be architecturally
> better if new ciphersuites would be defined rather than attempting to
> profile/extend TLS-PSK. There seems to be a few reasons why the
> current approach has not been seen as optimal:
>
> a) The term "key exchange" in TLS relates to the whole handshake as
> opposed to the actual cryptographic key exchange (Pasi Eronen). Since
> we're modifying the handshake (new extensions, new alerts, ...) it
> should follow that this is a new key exchange and hence should define
> a new ciphersuite (or -suites).
>
> b) Interpretation of certain data (e.g. the psk_identity field) will
> vary depending on whether "ordinary" TLS-PSK is performed or not; this
> is undesirable as servers will need to be prepared to interpret (and
> act upon) this field based on information in the Hello exchanges (Eric
> Rescorla).
>
> I don't quite understand a) above. I don't see that RFC4346 says that the
> key exchange defines the whole handshake. But even if this is the case,
> what about some of the extensions defined in RFC 4366, e.g. the
> truncated_hmac one? It seems to me that that extension also modifies the
> behavior of the parties, without introducing new ciphersuites?
>
> On b) above, I agree that this is undesirable. One way forward that I
> can see - besides defining new ciphersuites - would be to introduce
> (and require use of, when doing a handshake based on OTPs) a new
> extension, along the lines of (obviously the syntax needs to be
> corrected):
>
> OTPHandshakeParams otp_handshake_params<0..2^16-1>;>
> struct {
> OTPAlgorithm otp_algorithm;
> ChallengeData challenge_data<0..>;
> HardeningData hardening_data<0..>;
> KeyIdentifier key_identifier<0..>;
> UserIdentifier user_identifier<0..>;
> } OTPHandshakeParams;
>
> This approach would allow not only signaling of the intent of basing
> the exchange on OTPs, but also to negotiate the actual OTP algorithm
> as well as related parameters. I note that the above should also take
> away the need to change the meaning of the psk_identity field,
> something we anyway have been recommended not to do.
>
> What I'd like to ask is if this mandatory "signaling" of OTP use would
> be enough to resolve the concerns raised about the layering on top of
> the TLS-PSK ciphersuites?
>
> The strength of OTPs as a basis for TLS session keys
> ----------------------------------------------------
> There was a discussion about this in Montreal and I just want to
> clarify:
>
> A typical OTP is 6 - 8 decimal digits long, although alphanumerical OTPs
> are also in use. In addition, some OTP systems employ centralized PINs,
> meaning that the user provides a PIN in conjunction with the OTP.
> Typically this would therefore give in the order of 33 - 40 bits of
> entropy. Through hardening, one can increase the resistance. For example,
> hardening by iterative hashes, as suggested in the current draft, could
> complicate an attack as follows: With 100,000 iterations, the work load of
> the attacker will be about 17 bits more, in effect adding about 17 bits of
> strength (admittedly at a cost for the legit parties). For the example
> above, this would mean 50 - 57 bits of "entropy". Clearly this is less
> than even the 80-bit level offered through use of RSA 1024-bit keys, and I
> agree we could make this fact explicit (e.g. through some detailed
> examples) in the document and also add a recommendation to use the D-H-PSK
> (with normal caveats about MITM) or RSA-PSK variants in these situations.
> But I would not want to disallow the "direct" variant, for example since
> some connected OTP tokens may be able to emit considerably longer OTPs
> when in connected mode, and therefore would not need D-H (or the use of a
> PKI with RSA). (Longer OTPs in connected mode do not need to degrade the
> user experience since the user in these cases only enters the PIN, the OTP
> is programmatically retrieved. Long OTPs also eliminate or at least reduce
> the need for "hardening").
>
> -- Magnus
>
>
> _______________________________________________
> TLS mailing list
> TLS <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
Share your special moments by uploading 500 photos per month to Windows Live Spaces
Share it!
.
(Apologies for the time-warp reply, I've been travelling with no net access).
Peter.
RSS Feed