preauth mechanism functioning at the client-side

Tim Alsop Tim.Alsop at CyberSafe.Com
Mon Aug 13 14:03:28 EDT 2007

Thankyou for the explanation. I am sorry, but I cannot help you on this
question. I hope somebody else can.
Take care,


From: Gopal Paliwal [mailto:gopalpaliwal at] 
Sent: 13 August 2007 18:58
To: Tim Alsop; jaltman at
Cc: krbdev at
Subject: Re: preauth mechanism functioning at the client-side

Thanks for the reply.
Currently the number 32 which I assigned for the new-preauth type is'nt
having conflict with the existing ones as I did go thru RFC's & relevant
code for this change.
The problem I am facing is AS_RES does contain this preauth-type as a
hint (i captured it on etheral and could see the number 32 as a
type/value pair). 
Also the client is able to get this hint. THis hint preauth goes in
sort_padata_seq() code at the client side but client somehow selects
preauth value 2 (pa_enc_timestamp) to fill preauth data & sends that to
---->When I avoid just send my required preauth(32) to the client and
dont send pa_enc_timestamp(2) to the client as a edata hint, client
gives me an error like "LOOP detacted at the in krb5_get_in_tkt". This
is due to the fact that client doesn't get preauth type(2) from the
client side. 
I wish to know specifically, why client is not accepting any other
preauth apart from type-2 in my case. And whether client can send
2-preauth types back to the server.

On 8/13/07, Tim Alsop <Tim.Alsop at> wrote: 

	You may remember that I replied to your last email, showing you
	output from our software, which already supports RSA SecurID,
	Digipass and Secure Computing SafeWord tokens. To implement this
we have
	support in our client software to handle hardware authentication
	pre-auth type. This is so that the client can ask the user for
	information from the token + pin (if applicable). Without any
	code changes the client is only aware of how to ask for a
principal name
	and password.
	Also, when you select a pre-auth type, please check the RFCs in
case of
	a conflict with other pre-auth types that are known. 
	-----Original Message-----
	From: krbdev-bounces at [mailto:krbdev-bounces at] On
	Of Gopal Paliwal
	Sent: 13 August 2007 18:23
	To: krbdev at
	Subject: preauth mechanism functioning at the client-side
	I am implementing a OTP support mechanism in existing kerberos
	Till now, i have done the server changes and the AS_REP contains
	required timestamp as OTP one. I wish to know, will the existing
	able to send 2 preauth sequences (one is pa_enc_timestamp) and
the other 
	is my declared preauth-using OTP.
	Or the client just sends any-one of the asked preauth type.
	I see that the server would able to support more than one
	by the client by making it verify each preauth type in a loop
but i am 
	sure about how the client behaves in sending multi-preauth
	I debugged the client code and I could make out that the client
gets my
	created preauth mechanism as hint but still it selects
enc_time-stamp as 
	default one to reply back. The number I chose for my preauth
type is 32.
	-Gopal Paliwal
	krbdev mailing list             krbdev at

More information about the krbdev mailing list