Subject: [Ietf-krb-wg] Client Key and Reply Key generation using first supported PA-OTP-CHALLENGE.etype

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 8 Jul 2009 10:53:22 +0530

Gareth,

>From the draft, the first supported etype from PA-OTP-CHALLENGE.etype should
be used to encrypt the nonce in PA-OTP-REQUEST and the key used is Client
Key.

The client key is

1.       same as Armor Key when adding otp value to the PA-OTP-REQUEST.

2.       generated using KRB-FX-CF2(K1, K2, O1, O2), where K1 is the Armor
Key.

The function KRB-FX-CF2() generates Client key with the encryption type
(from FAST draft section 6.1) same as that of K1 (unless otherwise etype
specified) which is nothing but the encryption type of Armor Key.

I have few questions on this:

1.       Do we need to use etype in PA-OTP-CHALLENGE - as we can still
generate the Client and Reply Key based on the Armor Key and the encryption
type of these two generated keys will generally be the same as that of Armor
Key.

2.       If you want to specify the PA-OTP-CHALLENGE.etype while generating
keys, so that the first supported etype is used :

a.       There are chances that the first supported etype in
PA-OTP-CHALLENGE.etype maynot be same as the encryption type of Armor Key
and we use Armor Key for encrypting the nonce when OTP value is added to
PA-OTP-CHALLENGE.

So, maybe removing PA-OTP-CHALLENGE.etype maynot be a bad idea?

Thanks,
Srini

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Wed, 8 Jul 2009 05:14:56 -0400

Srini,
 
I think that you are right.  Thanks for pointing this out.
 
>From what I understand, the etype of the Armor Key will be that selected
by the client from the PA-ETYPE-INFO2 and as you point out, that of the
Client Key will be the same as the Armor Key due to the use of
KRB-FX-CF2.  It seems as if the etype of the Client Key will essentially
follow the same rules as that of the challenge key used by the Encrypted
Challenge FAST factor (section 6.5.6) of the FAST ID.
 
If this is the case then it seems as if the etype is not needed in the
PA-OTP-CHALLENGE or the PA-OTP-REQUEST.
 
Thanks
 
--Gareth

________________________________

	From: Srinivas Cheruku [mailto:[email-masked]] 
	Sent: 08 July 2009 10:53
	To: Richards, Gareth; [email-masked]
	Subject: Client Key and Reply Key generation using first
supported PA-OTP-CHALLENGE.etype

	Gareth,

	From the draft, the first supported etype from
PA-OTP-CHALLENGE.etype should be used to encrypt the nonce in
PA-OTP-REQUEST and the key used is Client Key.

	The client key is
	1.       same as Armor Key when adding otp value to the
PA-OTP-REQUEST.
	2.       generated using KRB-FX-CF2(K1, K2, O1, O2), where K1 is
the Armor Key.

	The function KRB-FX-CF2() generates Client key with the
encryption type (from FAST draft section 6.1) same as that of K1 (unless
otherwise etype specified) which is nothing but the encryption type of
Armor Key.

	I have few questions on this:
	1.       Do we need to use etype in PA-OTP-CHALLENGE - as we can
still generate the Client and Reply Key based on the Armor Key and the
encryption type of these two generated keys will generally be the same
as that of Armor Key.
	2.       If you want to specify the PA-OTP-CHALLENGE.etype while
generating keys, so that the first supported etype is used :
		a.       There are chances that the first supported
etype in PA-OTP-CHALLENGE.etype maynot be same as the encryption type of
Armor Key and we use Armor Key for encrypting the nonce when OTP value
is added to PA-OTP-CHALLENGE.

	Thanks,
	Srini