BASIC - FORM - DIGEST - CLIENT CERT In Deployment Descriptor

Hi...
I am still confuse about the implementation
of BASIC / DIGEST / FORM / CLIENT-CERT in
deployment - descriptor.
Here is my opinion :
BASIC
=====
....
<user-data-constraint>
<transport-guarantee>
NONE // In Basic, transport- // guarantee shoule be
// none, or ?
</transport-guarantee>
</user-data-constraint>
....
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>My Basic</realm-name>
</login-config>
....
FORM
=====
....
<user-data-constraint>
<transport-guarantee>
NONE // In FORM, transport- // guarantee shoule be
// none, or ?
</transport-guarantee>
</user-data-constraint>
....
<login-config>
<auth-method>FORM<auth-method>
<form-login-config>
<form-login-page>
/LoginForm.html
</form-login-page>
<form-error-page>
/LoginError.html
</form-error-page>
</form-login-config>
</login-config>
....

And How about DIGEST & CLIENT CERT
What should we fill in <transport-guarantee>
and <login-config> ??

Originally posted by Alexander Mark:
BASIC
=====
....
<user-data-constraint>
<transport-guarantee>
NONE // In Basic, transport- // guarantee shoule be
// none, or ?
</transport-guarantee>

My understanding is that it can be any of NONE, INTEGRAL or CONFIDENTIAL and is independent of the authentication method. In a real life situation, if you need half-serious security with basic or form-based login you would certainly want to use CONFIDENTIAL to force a secure connection such as SSL - you don't want plaintext passwords flitting about the net do you?

And How about DIGEST & CLIENT CERT
What should we fill in <transport-guarantee>
and <login-config> ??

In DIGEST authentication, the server sends a challenge (the nonce) to the browser. After prompting the user for the password, the browser will put both password and nonce through a cryptographically secure meat grinder to produce the "digest". This digest is then sent back to the server and verified. Other than with BASIC authentication, a DIGEST can (more or less) safely be sent in the clear because

It cannot be used again as it is very, very unlikely that the server will ever use the same nonce for the same user

Grinding meat is a one-way process; it is impossible to reconstruct the password from the digest.

The conclusion is that with DIGEST authentication there is no pressing need for a fancy transport guarantee. Insisting on INTEGRAL or CONFIDENTIAL won't hurt but it is not necessary to guarantee the safety of the password. You may well want to specify one of these to protect the remainder of the session from attack though!
CLIENT-CERT authentication takes the art of cryptographic meat grinding to new culinary heights. It requires the client to send a certificate - a proof of your identity signed by a Cerficate Authority (CA) such as VeriSign. Certificates are based on public-key cryptography, a subject you could write entire books about

A third party can safely intercept the certificate as it is worthless without the matching private key which is kept safely on the client. So in theory here, too, there is no need for a specific transport guarantee to safeguard the authentication data. But you will need a transport that supports the use of certificates! In practice this means that you need SSL, which would correspond to an INTEGRAL or CONFIDENTIAL guarantee (SSL supports both). The specification is silent on what happens if you ask for a CLIENT-CERT over a transport guarantee NONE; in all likelihood the application server simply ignores you and requires an SSL connection regardless.
Does this help?
- Peter
[ April 08, 2002: Message edited by: Peter den Haan ]

Thank you...
It really helps and your explaination is clear... you already wrote a lot and spend ur time.
Thank you once more.
Alexander

Welcome. I just edited the article to clarify a few points...
- Peter