Subject: [Ietf-krb-wg] FW: New Version Notification for draft-ietf-krb-wg-otp-preauth-08

From: [email-masked]
Date: Mon, 15 Sep 2008 07:16:11 -0400

I have just submitted a new version of the OTP pre-auth ID that should
address the last issues that were reaised during the recent review.

1. I extended the PA-OTP-CHALLENGE so that it contains a sequence of
etypes.
        etype              SEQUENCE OF Int32,

The KDC will include the etypes in order of preference and the client
will select the first one it supports.

2. I clarified in section 3.5 that the client MUST NOT continue with the
authentication exchange if it cannot confirm the reply key change.  The
use of the word fail was causing confusion.

Please ignore version 07, I accidentally submitted a version that didn't
have all the changes.

--Gareth

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 15 September 2008 12:11
To: Richards, Gareth
Subject: New Version Notification for draft-ietf-krb-wg-otp-preauth-08 

A new version of I-D, draft-ietf-krb-wg-otp-preauth-08.txt has been
successfuly submitted by Gareth Richards and posted to the IETF
repository.

Filename:	 draft-ietf-krb-wg-otp-preauth
Revision:	 08
Title:		 OTP Pre-authentication
Creation_date:	 2008-09-15
WG ID:		 krb-wg
Number_of_pages: 35

Abstract:
The Kerberos protocol provides a framework authenticating a client using
the exchange of pre-authentication data.  This document describes the
use of this framework to carry out One Time Password
(OTP) authentication.

The IETF Secretariat.

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

---

From: Tim Alsop <[email-masked]>
Date: Mon, 15 Sep 2008 12:24:02 +0100

Gareth,

[Tim Alsop] What happens if there is more than one etype which client and KDC support ? Is the one found first whilst scanning the list, the one which is used ? Surely the decision on which etype is preferred should be made by KDC, not by client ? Normally, a client sends list of etypes to KDC, and KDC checks which one is supported, and via a policy decision determines which one will be used (if there is more than one that both client and KDC support). I think this approach is better, since it is not good to have client make a decision on which etype to use, but to allow KDC to determine this and if there is no etype which both support, it can reject the authentication attempt.

Thanks,
Tim

---

From: [email-masked]
Date: Mon, 15 Sep 2008 07:32:08 -0400

This change was made at a request of Srinivas Cheruku of CyberSafe.

The idea was to allow negotiation of supported etypes in the same way as
the ID allows negotiation of one-way hash functions.  The KDC would
include a list of identifiers in order of preference that its policy
allows it to use and the client selects the first one from the list that
it supports and is allowed to use by policy.  This would still allow
local KDC policy to restrict the algorithms that can be used.

--Gareth

> 
> 1. I extended the PA-OTP-CHALLENGE so that it contains a 
> sequence of etypes.
>         etype              SEQUENCE OF Int32,
> 
> The KDC will include the etypes in order of preference and 
> the client will select the first one it supports.
> 
> [Tim Alsop] What happens if there is more than one etype 
> which client and KDC support ? Is the one found first whilst 
> scanning the list, the one which is used ? Surely the 
> decision on which etype is preferred should be made by KDC, 
> not by client ? Normally, a client sends list of etypes to 
> KDC, and KDC checks which one is supported, and via a policy 
> decision determines which one will be used (if there is more 
> than one that both client and KDC support). I think this 
> approach is better, since it is not good to have client make 
> a decision on which etype to use, but to allow KDC to 
> determine this and if there is no etype which both support, 
> it can reject the authentication attempt.
> 
> Thanks,
> Tim
> 
>

---

From: Tim Alsop <[email-masked]>
Date: Mon, 15 Sep 2008 12:37:04 +0100

I am not disagreeing with the need for this negotiation (as suggested by Srinivas), just that I don't think it is a good idea for the client to make the decision. Instead, the KDC should make the decision on what etype to use when client and KDC are negotiating, as this can then be consistent within a particular implementation of Kerberos, rather than each client making its own policy decision, which may be different for many clients using same KDC. Also, if client makes the decision, it may be possible for somebody to change client code and authenticate using a weaker etype than the organisation allows, so this presents a potential security issue.

Regards,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 15 September 2008 12:32
To: Tim Alsop; [email-masked]
Subject: RE: [Ietf-krb-wg] FW: New Version Notification fordraft-ietf-krb-wg-otp-preauth-08

--Gareth

---

From: [email-masked]
Date: Mon, 15 Sep 2008 07:47:15 -0400

It is not clear how in the current ID, the client would send a list of
supported etypes to the KDC.

In the current proposal, the KDC only includes the etypes that in the
PA-OTP-CHALLENGE that its policy permits it to use.  The client only
selects from that list.  So if someone changed  client code, they could
only make it use the weaker of the etypes that conform to KDC policy.
I wouldn't think that this would be any different to the atacker
changing the client so that it sent the weaker algorithms in the list it
sent to the KDC.

Section 3.4 has the following text:

   The authentication MUST fail if the encryption type used by the
   client in the encData does not conform to KDC policy. 

> From: Tim Alsop [mailto:[email-masked]] 
> Sent: 15 September 2008 12:37
> To: Richards, Gareth; [email-masked]
> I am not disagreeing with the need for this negotiation (as 
> suggested by Srinivas), just that I don't think it is a good 
> idea for the client to make the decision. Instead, the KDC 
> should make the decision on what etype to use when client and 
> KDC are negotiating, as this can then be consistent within a 
> particular implementation of Kerberos, rather than each 
> client making its own policy decision, which may be different 
> for many clients using same KDC. Also, if client makes the 
> decision, it may be possible for somebody to change client 
> code and authenticate using a weaker etype than the 
> organisation allows, so this presents a potential security issue.
> 
> Regards,
> Tim
> 
> The idea was to allow negotiation of supported etypes in the 
> same way as the ID allows negotiation of one-way hash 
> functions.  The KDC would include a list of identifiers in 
> order of preference that its policy allows it to use and the 
> client selects the first one from the list that it supports 
> and is allowed to use by policy.  This would still allow 
> sequence of 
> which client 
> > and KDC support ? Is the one found first whilst scanning 
> the list, the 
> > one which is used ? Surely the decision on which etype is preferred 
> > should be made by KDC, not by client ? Normally, a client 
> sends list 
> > of etypes to KDC, and KDC checks which one is supported, and via a 
> > policy decision determines which one will be used (if there is more 
> approach is 
> > better, since it is not good to have client make a decision 
> on which 
> > etype to use, but to allow KDC to determine this and if there is no 
> > etype which both support, it can reject the authentication attempt.
> >
> > Thanks,
> > Tim
> >
> >
> 
>

---

From: Tim Alsop <[email-masked]>
Date: Mon, 15 Sep 2008 12:50:51 +0100

Gareth,

Ok, I was not clear on this and must admit I am not as familiar with the ID as you and Srinivas are. Anyway, I am satisfied with your response/explanation so do not have any concern on this now.

Regards,
Tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 15 Sep 2008 16:44:41 -0700

The KDC should not send any etypes it's not prepared to allow.  Any  
"preferences" are meaningless from a security standpoint since the  
client may not respect them.  The strength of the exchange is as good  
as the weakest etype allowed.

>>> etype which both support, it can reject the authentication attempt.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]