preauth mechanism functioning at the client-side

[Tim Alsop]

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

________________________________

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


Hi,
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
server. 
---->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.
 
-gopal 

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

	Gopal
	
	You may remember that I replied to your last email, showing you
the
	output from our software, which already supports RSA SecurID,
VASCO 
	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
the
	information from the token + pin (if applicable). Without any
client 
	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. 
	
	Regards,
	Tim
	
	-----Original Message-----
	From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On
Behalf
	Of Gopal Paliwal
	Sent: 13 August 2007 18:23
	To: krbdev at mit.edu
	Subject: preauth mechanism functioning at the client-side
	
	hi,
	
	I am implementing a OTP support mechanism in existing kerberos
1.6.1.
	Till now, i have done the server changes and the AS_REP contains
one
	more
	required timestamp as OTP one. I wish to know, will the existing
client
	be
	able to send 2 preauth sequences (one is pa_enc_timestamp) and
the other 
	one
	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
preauth-type
	sent
	by the client by making it verify each preauth type in a loop
but i am 
	not
	sure about how the client behaves in sending multi-preauth
types.
	
	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 
	a
	default one to reply back. The number I chose for my preauth
type is 32.
	
	
	Regards,
	-Gopal Paliwal
	_______________________________________________
	krbdev mailing list             krbdev at mit.edu
	https://mailman.mit.edu/mailman/listinfo/krbdev