Steffen Schulz wrote: > I'm currently implementing draft-ietf-tls-srp-13 in NSS/SSL. > > I did not find suitable test programs.
NSS has many test programs. See http://lxr.mozilla.org/security/source/security/nss/cmd/ > I mean something like "openssl" or "gnutls-cli". If you're looking for a command line SSL client, NSS has tstclnt and strsclnt "test client" and "stress client"). > My primary goal was to get a working implementation of Firefox+SRP. > That's why I have been working with the latest mozilla/firefox from CVS > until now. All proposed ciphersuites are currently working with > OpenSSL+SRP as server and hardcoded login/passwd. Now I have to > implement a new callback function that provides the user login to > NSS/SSL. NSS already defines a callback API for requesting user passwords. It's already used by NSS test programs and by mozilla browsers. It's designed to request passwords for PKCS#11 tokens, but could be used for other password purposes also. Perhaps you could create a fake "slot" for this purpose. For documentation, see http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128 See http://lxr.mozilla.org/security/source/security/nss/cmd/lib/secutil.c#248 for an implementation used in NSS command line tools. The password callback function is registered with a call to PK11_SetPasswordFunc() and is invoked by calling pk11_GetPassword() (which is not public, but that could be fixed. :) > And I think it might be better to be able to test it inside > the NSS distribution only(input validation, better control over SSL > states). Yes, its much easier to debug code in CLI tools than in the browser. > I also have a question concerning the implementation. > > As far as I can see, the PKCS11 interface is only useful if there is > cryptographic hardware installed? I can not see an advantage to the > SRP protocol, as it does not need certificates or secret keys. In Mozilla clients all cryptographic functions are done in PKCS#11 "tokens, which reside in "slots" managed by "modules" (which are shared libraries). Not all PKCS#11 tokens & slots are hardware. Mozilla comes with a PKCS#11 module that implements pure-software virtual tokens. NSS is able to use multiple modules, slots and tokens, so that it is able to use hardware tokens as well as software, and use them all side-by-side. But again, all crypto done by Mozilla clients is done in PKCS#11 modules. > My problem is that the PK11-stuff looks rather complex. I was not able > to compute the pre-master secret using PK11, so currently only the > bypass-path is working. Mozilla clients never use the bypass feature. All mozilla crypto is done in PKCS#11 modules. (Think of that as a mantra :) It appears to me that the client's computation of "A" is essentially an ephemeral DH public value, and that the computations of A, u, k and x can be done with existing PKCS#11 mechanisms (algorithms). But it appears that derivation of the pre-master secret requires computations that are not part of any PKCS#11 mechanism (known to me, but I might have forgotten some). So, I'd say that a new PKCS#11 mechanism would need to be implemented in NSS's software virtual tokens, and if that mechanisms is not yet defined in any version of PKCS#11 or amendments thereto, the mechanism would need to be defined first. > And even with opt.bypass set, the cipher-suite > lookup fails due to missing PK11 support. I suppose, this is a problem? The bypass feature avoids PKCS#11 for all but public/private key operations such as RSA, DSA, DH, ECDH, ECDSA. Those operations are always done in PKCS#11 modules. Mozilla browsers never use the bypass feature. > How are these PK11 slots supposed to work? I think you're asking for an overview of PKCS#11, which is beyond the realm of an email reply such as this. Basically, all the cryptographic engines ("mechanisms", in PKCS#11 jargon) and all the keys are kept inside the token. Only the "public" values (the ones that cross the wire) typically ever come out of it. It may help you to know that NSS provides "PKCS11 wrapper" functions that isolate higher level code such as applications, or even the SSL library, from having to know all about PKCS#11. Look for functions whose names begin with PK11_ in the list of public NSS functions, at http://lxr.mozilla.org/security/source/security/nss/lib/nss/nss.def#106 You can find those functions quickly by pasting their names into the "Identifier Search" box on this page: http://lxr.mozilla.org/security/ and bonking the "Find" button. Given that the pre-master secret derivation requires numerous values not used by other mechanisms (e.g. B, k, a, u, x), a new PKCS#11 wrapper function might need to be written. > I've also left out the server support, as it is not part of the > university project. But I don't think it would be much work, now that I > know how everything is supposed to work. If you would consider the > project to be included into NSS, I will do what I can to improve the > patch so it can be included. We once accepted a contribution that implemented the DHE cipher suites on the client side only, and not on the server. The server side implementation has never been completed (because the feature was not high priority), with the consequence that we cannot test our client side DHE code with our own test servers. In retrospect, some of us think it was a mistake to accept the client-side-only patch. If you were to submit a client-side-only implementation for SRP, we would have to do some serious consideration about whether we'd accept it. Also, ISTR that there are unresolved patent issues with SRP. (This was recently the focus of MUCH discussion on the IETF TLS mailing list.) Mozilla can only accept source code provided that anyone anywhere is entitled to use it without obtaining a patent license first. This could be solved with a public "blanket" license statement from the patent holders granting all users of NSS a free license to use SRP in products that use NSS. > I can provide diffs to firefox cvs head, but the code still needs work > and cleanup. When & if you reach the point where you think your patch is ready for submission (or for a first review), file an enhancement request "bug" in bugzilla.mozilla.org against product=NSS, component=libraries, and attach your patch to it. patches need to be the output of the command cvs diff -Npu5 > My first larger project, any comments appreciated. > > Regards, > Steffen > > > SRP project: http://srp.stanford.edu/ > TLS-SRP draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.txt -- 00000000011111111112222222222333333333344444444445555555555666666666677777777778 12345678901234567890123456789012345678901234567890123456789012345678901234567890 _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
