The DIGEST-MD5 mechanism is based on repeated hashing using MD5, which after the MD5 break may be argued to be weaker than HMAC-MD5, but supports more features. For example, authorization identities and data integrity and privacy protection are supported. Like CRAM-MD5, only a hashed password is transferred. Consequently, DIGEST-MD5 needs access to the correct password (although it may be hashed, another improvement compared to CRAM-MD5) to verify the client response. Alas, this makes it impossible to use, e.g., PAM on the server side.
In the client, this mechanism is always enabled, and it requires the
GSASL_AUTHID
, GSASL_PASSWORD
, GSASL_SERVICE
, and
GSASL_HOSTNAME
properties. If set, GSASL_AUTHZID
and
GSASL_REALM
will also be used.
In the server, the mechanism will first request the
GSASL_DIGEST_MD5_HASHED_PASSWORD
callback property to get the
user's hashed password. If the callback doesn't supply a hashed
password, the GSASL_PASSWORD
callback property will be
requested. Both callbacks may use the GSASL_AUTHID
,
GSASL_AUTHZID
and GSASL_REALM
properties to determine
which users' password should be used. The server will then compare
the client response with a computed correct response, and accept the
user accordingly.
The server uses the GSASL_QOPS
callback to get the set of
quality of protection values to use. By default, it advertises
support for authentication (qop-auth
) only. You can use the
callback, for example, to make the server advertise support for
authentication with integrity layers.
The client uses the GSASL_QOP
callback to get the quality of
protection value to request. The client must choose one of the QOP
values offered by the server (which may be inspected through the
GSASL_QOPS
property). If the client does not return a value,
qop-auth
is used by default.