| [Top] | [Contents] | [Index] | [ ? ] |
Footnotes
(1)
http://www.gnu.org/software/libtasn1/
(2)
http://www.lysator.liu.se/~nisse/nettle/
(3)
The first message in a TLS handshake
(4)
IETF, or Internet Engineering Task Force, is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.
(5)
MAC stands for Message Authentication Code. It can be described as a keyed hash algorithm. See RFC2104.
(6)
To avoid collisions in order to specify a compression algorithm in this string you have to prefix it with "COMP-", protocol versions with "VERS-", signature algorithms with "SIGN-" and certificate types with "CTYPE-". All other algorithms don’t need a prefix.
(7)
It really depends on the group used. Primes with lesser bits are always faster, but also easier to break. See Selecting cryptographic key sizes for the acceptable security levels.
(8)
SRP is described in [RFC2945] is supported. The SRP key exchange is an extension to the TLS protocol, and it is a password based authentication (unlike X.509 or OpenPGP that use certificates). The two peers can be identified using a single password, or there can be combinations where the client is authenticated using SRP and the server using a certificate.
The advantage of SRP authentication, over other proposed secure password authentication schemes, is that SRP does not require the server to hold the user’s password. This kind of protection is similar to the one used traditionally in the UNIX ‘/etc/passwd’ file, where the contents of this file did not cause harm to the system security if they were revealed. The SRP needs instead of the plain password something called a verifier, which is calculated using the user’s password, and if stolen cannot be used to impersonate the user. Check [TOMSRP] description of the SRP protocol and the Stanford SRP libraries, which includes a PAM module that synchronizes the system’s users passwords with the SRP password files. That way SRP authentication could be used for all the system’s users.
The implementation in GnuTLS is based on [TLSSRP] The supported SRP key exchange methods are:
-
SRP: Authentication using the SRP protocol.
-
SRP_DSS: Client authentication using the SRP protocol. Server is authenticated using a certificate with DSA parameters.
-
SRP_RSA: Client authentication using the SRP protocol. Server is authenticated using a certificate with RSA parameters.
If clients supporting SRP know the username and password before the connection, should initialize client credentials and call gnutls_srp_set_client_credentials. Alternatively gnutls_srp_set_client_credentials_function may be used to specify a callback function. The callback will be called once during the TLS handshake.
In server side the default behavior of GnuTLS is to read the usernames and SRP verifiers from password files. These password files are the ones used by the Stanford srp libraries and gnutls_srp_set_server_credentials_file can be used to specify them. If a different password file format is to be used, then gnutls_srp_set_server_credentials_function should be called, to set an appropriate callback.
Helper functions are included in GnuTLS, and can be used to generate and maintain SRP verifiers and password files. A program to manipulate the required parameters for SRP authentication is also included. See srptool, for more information.
(9)
http://www.gnupg.org/related_software/gpgme/
(10)
http://p11-glue.freedesktop.org/
(11)
See also the Server Name Indication extension on serverind.
(12)
See LDAP, IMAP etc.
(13)
in SRP authentication
(14)
such as the
gnutls_certificate_credentials_t structures
(15)
Check http://home.gna.org/cryptodev-linux/
for the Linux kernel implementation of /dev/crypto.
| [Top] | [Contents] | [Index] | [ ? ] |