Subject: [Ietf-krb-wg] PIN change in OTP pre-authentication

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 30 Oct 2007 14:24:21 -0000

Hello,

I recently submitted the 0th draft of the OTP pre-authentication I-D as
a WG document that replaces draft-richards-otp-kerberos-03.  Recently, I
was asked some questions about the handling of PIN change in the draft
and I was wondering if someone could advise me on some aspects of
password change in general.

In the current draft, if KDC discovers while validating the
pre-authentication data that the user's PIN needs to be changed (e.g.
has expired) then it will return a PIN change padata in the KRB_AS_REP.
I didn't want to handle the PIN change process as part of the protocol
but hoped to use the existing password change protocol in RFC3244 to
handle it.  However, I was also hoping to be able to ensure that the
user did change the PIN and my hope was the client would only be able to
use the issued TGT to gain a ticket for the password change service and
so would be required to change their PIN before proceeding.

Is this possible?  

>From what I can make out, this isn't the case for password change.
Section 3.3 of the password change I-D describes how "kadim/changepw"
should be used as the service principal in the case of an expired
password but this seems to be for a restricted service rather than
restricting which services they can request.

Thanks

Gareth Richards

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 24 October 2007 19:35
To: [email-masked]
Subject: New Version Notification for draft-ietf-krb-wg-otp-preauth-00 

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

Filename:	 draft-ietf-krb-wg-otp-preauth
Revision:	 00
Title:		 OTP Preauthentication
Creation_date:	 2007-10-05
WG ID:		 krb-wg
Number_of_pages: 15

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: Tue, 30 Oct 2007 15:12:12 -0000

Gareth,

I think you need to consider the Kerberos password in the KDC
differently to the PIN for the token device. The PIN change is typically
determined by the OTP auth server, not by the KDC, perhaps due to
administrator request or due to need to re-sync PINs because of
suspected attack or time sync issues.

As I have mentioned before, our TrustBroker product has support for OTP,
and we have included PIN change as well as PIN re-sync and new PIN, e.g.
When using RSA SecurID. We did this by making the KDC send back a msg to
the client when it needs a new pin, and the client then prompts the user
for the required information and sends it back to the kdc in encrypted
pre-auth data. In fact we coded this in a generic way so that if another
OTP product was to be supported we can do this by just coding a new
plugin for the KDC, and client software will be able to provide more
details when asked.

For example, a normal authentication might look like :

[root@shrek newkdc]# kinit talsop
Password for talsop@SHREK: 
Enter Passcode (PIN+Tokencode) or Tokencode from your SecurID Token: 
[root@shrek newkdc]#

But, if OTP auth server has determine that I need a new PIN I will get :

[root@shrek newkdc]# kinit talsop
Password for talsop@SHREK: 
Enter Passcode (PIN+Tokencode) or Tokencode from your SecurID Token: 
You need to change your PIN.
You may either specify your own new PIN or use the system generated PIN.
Your new PIN must contain between 4 and 8 alphanumeric characters.
Your new system generated PIN: srqk

Please enter a new PIN (default: srqk): 
Enter Passcode (PIN+Tokencode) from your SecurID Token: 
[root@shrek newkdc]#

As you can see, due to the way our product works the user can be
informed of any policy details for the new pin, e.g. number of digits,
whether the pin is numeric or alphanumeric, given a system generated pin
etc. You can also see that the Kerberos password is separate from the
PIN code as they are both needed with our current implementation.

Thanks,
Tim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Richards, Gareth
Sent: 30 October 2007 14:24
To: IETF Kerberos Working Group
Subject: [Ietf-krb-wg] PIN change in OTP pre-authentication

Hello,

Is this possible?  

Thanks

Gareth Richards

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 24 October 2007 19:35
To: [email-masked]
Subject: New Version Notification for draft-ietf-krb-wg-otp-preauth-00 

Abstract:

The IETF Secretariat.

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 30 Oct 2007 17:11:56 -0000

Tim,

Thanks for the help.

The situation I was thinking of is where the KDC is using an OTP auth
server to validate the OTPs in the pre-authentication exchange and is
told by the auth server that the user's PIN has expired.  In the current
I-D, the KDC would then return a response similar to the one you
describe that contains a minimum and maxim mum length and possibly a
system generated PIN.   I wasn't linking the OTP and the KDC managed
password.  Sorry for the confusion.

As I described, I was trying to avoid putting PIN change as part of the
protocol and so return the new PIN in pre-auth data and was trying to
see if I could instead use the existing password change protocol in
RFC3244 and the new password change I-D to change a PIN instead of a the
standard KDC-managed password.   However, I am not sure if this is the
right way to go.

Thanks 

--Gareth

> differently to the PIN for the token device. The PIN change 
> is typically determined by the OTP auth server, not by the 
> KDC, perhaps due to administrator request or due to need to 
> re-sync PINs because of suspected attack or time sync issues.
> 
> As I have mentioned before, our TrustBroker product has 
> support for OTP, and we have included PIN change as well as 
> PIN re-sync and new PIN, e.g.
> When using RSA SecurID. We did this by making the KDC send 
> back a msg to the client when it needs a new pin, and the 
> client then prompts the user for the required information and 
> sends it back to the kdc in encrypted pre-auth data. In fact 
> we coded this in a generic way so that if another OTP product 
> was to be supported we can do this by just coding a new 
> plugin for the KDC, and client software will be able to 
> provide more details when asked.
> 
> As you can see, due to the way our product works the user can 
> be informed of any policy details for the new pin, e.g. 
> number of digits, whether the pin is numeric or alphanumeric, 
> given a system generated pin etc. You can also see that the 
> Kerberos password is separate from the PIN code as they are 
> both needed with our current implementation.
> 
> Thanks,
> Tim
> 
> I recently submitted the 0th draft of the OTP 
> pre-authentication I-D as a WG document that replaces 
> draft-richards-otp-kerberos-03.  Recently, I was asked some 
> questions about the handling of PIN change in the draft and I 
> was wondering if someone could advise me on some aspects of 
> I didn't want to handle the PIN change process as part of the 
> protocol but hoped to use the existing password change 
> protocol in RFC3244 to handle it.  However, I was also hoping 
> to be able to ensure that the user did change the PIN and my 
> hope was the client would only be able to use the issued TGT 
> to gain a ticket for the password change service and so would 
> be required to change their PIN before proceeding.
> 
> Is this possible?  
> 
> should be used as the service principal in the case of an 
> expired password but this seems to be for a restricted 
> service rather than restricting which services they can request.
> 
> Thanks
> 
> Gareth Richards
>

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 17:15:37 -0000

Gareth,

Our product works the same way as you are suggesting, e.g. the KDC is
using an OTP auth server to validate the OTPs in the pre-auth exchange,
and has been told by the auth server that the PIN has expired, or needs
to be changed for some other reason.

When I mentioned KDC passwords and OTP PIN being different, this is
because the KDC password is something that is always present and most
KDCs (except Microsoft Active Directory) do not store the password,
instead they store a key which is derived from the password. The key
will always be present and usable as a password for a given principal,
so your suggestion to use the existing Kerberos password change protocol
to change OTP PIN does not make sense, and cannot work as you suggested.
This is what I was trying to say, and I am sorry if I was not clear.

In our product, we don't have pin change as part of the protocol either.
The kdc just has the ability to send a msg to client asking for more
info, and the new pin is one example of this being used. 

In summary, I don't think you will be able to use Kerberos change
password to change the PIN. I also don't think it would be sensible to
do so, even if it was/is technically possible.

Thanks,
Tim

-----Original Message-----
From: Richards, Gareth [mailto:[email-masked]] 
Sent: 30 October 2007 17:12
To: Tim Alsop
Cc: IETF Kerberos Working Group
Subject: RE: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim,

Thanks for the help.

Thanks 

--Gareth

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 30 Oct 2007 17:31:03 -0000

Tim,

I understand that the user's key will always be present on the KDC and I
was not suggesting that the password change service be used to change
the PIN but by a PIN change service supporting the ChangePasswdData.  

Thanks

--Gareth
> 
> Our product works the same way as you are suggesting, e.g. 
> the KDC is using an OTP auth server to validate the OTPs in 
> the pre-auth exchange, and has been told by the auth server 
> that the PIN has expired, or needs to be changed for some 
> other reason.
> 
> When I mentioned KDC passwords and OTP PIN being different, 
> this is because the KDC password is something that is always 
> present and most KDCs (except Microsoft Active Directory) do 
> not store the password, instead they store a key which is 
> derived from the password. The key will always be present and 
> usable as a password for a given principal, so your 
> suggestion to use the existing Kerberos password change 
> protocol to change OTP PIN does not make sense, and cannot 
> work as you suggested.
> The kdc just has the ability to send a msg to client asking 
> for more info, and the new pin is one example of this being used. 
> 
> In summary, I don't think you will be able to use Kerberos 
> change password to change the PIN. I also don't think it 
> would be sensible to do so, even if it was/is technically possible.
> 
> Thanks,
> Tim
> 
> The situation I was thinking of is where the KDC is using an 
> OTP auth server to validate the OTPs in the 
> pre-authentication exchange and is told by the auth server 
> that the user's PIN has expired.  In the current I-D, the KDC 
> would then return a response similar to the one you describe 
> that contains a minimum and maxim mum length and possibly a
> As I described, I was trying to avoid putting PIN change as 
> part of the protocol and so return the new PIN in pre-auth 
> data and was trying to see if I could instead use the 
> existing password change protocol in
> > differently to the PIN for the token device. The PIN change is 
> > typically determined by the OTP auth server, not by the 
> KDC, perhaps 
> > due to administrator request or due to need to re-sync PINs 
> because of 
> > As I have mentioned before, our TrustBroker product has support for 
> > OTP, and we have included PIN change as well as PIN re-sync and new 
> > PIN, e.g.
> back a msg 
> > to the client when it needs a new pin, and the client then 
> prompts the 
> > user for the required information and sends it back to the kdc in 
> > encrypted pre-auth data. In fact we coded this in a generic way so 
> > that if another OTP product was to be supported we can do 
> this by just 
> > coding a new plugin for the KDC, and client software will 
> be able to 
> > But, if OTP auth server has determine that I need a new PIN 
> I will get 
> > :
> > 
> > informed of any policy details for the new pin, e.g.
> > number of digits, whether the pin is numeric or 
> alphanumeric, given a 
> > system generated pin etc. You can also see that the 
> Kerberos password 
> > is separate from the PIN code as they are both needed with 
> our current 
> > implementation.
> > 
> > Thanks,
> > Tim
> > 
> pre-authentication I-D 
> > as a WG document that replaces draft-richards-otp-kerberos-03.  
> > Recently, I was asked some questions about the handling of 
> PIN change 
> > in the draft and I was wondering if someone could advise me on some 
> > aspects of password change in general.
> > 
> > user did change the PIN and my hope was the client would 
> only be able 
> > to use the issued TGT to gain a ticket for the password 
> change service 
> > and so would be required to change their PIN before proceeding.
> > 
> > Is this possible?  
> > 
> > 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.
> > 
> >

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Oct 2007 10:35:55 -0700

This discussion seems to assume that the Kerberos password, the OTP  
PIN, and the OTP value itself are all different.  I don't believe  
that GR's draft requires this, and I don't believe that we should  
assume or require that.

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 17:35:26 -0000

Gareth,

>From what I have seen with current OTP auth severs, they normally only
request a new PIN during an authentication attempt, so to do what you
suggest, the client code would have to use change password msg exchange
with KDC to change the pin during its attempt to authenticate a user...
So, instead of the normal AS-REQ, AS-REP exchange to get a TGT, the
client code would have to combine this with the password change when a
new pin is requested, so that the KDC can know the new pin, and use this
new pin to pass to auth server - unless I have misunderstood your
suggestion ??? To me that seems unnecessarily complex and not needed.
Surely the approach we use is ok, since we are sending the new pin over
a secure channel to kdc, and this new pin is passed to the OTP auth
server that requested the new pin for the user.

Thanks,
Tim

-----Original Message-----
From: Richards, Gareth [mailto:[email-masked]] 
Sent: 30 October 2007 17:31
To: Tim Alsop
Cc: IETF Kerberos Working Group
Subject: RE: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim,

Thanks

--Gareth

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 17:37:00 -0000

Henry,

What makes you say that ? I was not indicating that any values or PINS
are different, or the same. The solution will of course need to support
any combination and not make any assumptions, just like our product does
at the moment when we support OTP based auth.

Thanks,
Tim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Henry B. Hotz
Sent: 30 October 2007 17:36
To: Tim Alsop
Cc: IETF Kerberos Working Group; Richards,Gareth
Subject: Re: [Ietf-krb-wg] PIN change in OTP pre-authentication

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 30 Oct 2007 17:55:56 -0000

Tim,

You are correct that a new PIN is only requested during an
authentication exchange but it is really at the end of the process.  The
user's OTP value has been validated and the OTP auth server returns a
"new PIN requested" response.  

The sequence would therefore be an AS-REQ with with the OTP data and an
AS-REP with the "new PIN" asdata.  The pre-authentication would then be
complete and the user would have a TGT.  The proposal was that this TGT
would then be used to request a ticket for the PIN change service and
the PIN would be changed in a similar manner to the handling of password
change.

I am not sure if this is the best way to handle it but I was trying to
model the sequence on password change following authentication.

Thanks

--Gareth

> Gareth,
> 
> From what I have seen with current OTP auth severs, they 
> normally only request a new PIN during an authentication 
> attempt, so to do what you suggest, the client code would 
> have to use change password msg exchange with KDC to change 
> the pin during its attempt to authenticate a user...
> So, instead of the normal AS-REQ, AS-REP exchange to get a 
> TGT, the client code would have to combine this with the 
> password change when a new pin is requested, so that the KDC 
> can know the new pin, and use this new pin to pass to auth 
> server - unless I have misunderstood your suggestion ??? To 
> me that seems unnecessarily complex and not needed.
> Surely the approach we use is ok, since we are sending the 
> new pin over a secure channel to kdc, and this new pin is 
> passed to the OTP auth server that requested the new pin for the user.
> 
> Thanks,
> Tim
> 
> I understand that the user's key will always be present on 
> the KDC and I was not suggesting that the password change 
> service be used to change the PIN but by a PIN change service 
> supporting the ChangePasswdData.  
> 
> Thanks
> 
> --Gareth
> > 
> > the KDC is using an OTP auth server to validate the OTPs in the 
> > pre-auth exchange, and has been told by the auth server 
> that the PIN 
> > has expired, or needs to be changed for some other reason.
> > 
> > so your suggestion to use the existing Kerberos password change 
> work as you 
> > suggested.
> for more 
> > told by the auth server that the user's PIN has expired.  In the 
> > current I-D, the KDC would then return a response similar 
> to the one 
> > you describe that contains a minimum and maxim mum length 
> and possibly 
> > a
> > As I described, I was trying to avoid putting PIN change as part of 
> > the protocol and so return the new PIN in pre-auth data and 
> was trying 
> > to see if I could instead use the existing password change 
> protocol in
> > RFC3244 and the new password change I-D to change a PIN 
> instead of a 
> > the
> support for 
> > > You may either specify your own new PIN or use the system 
> generated 
> > > PIN.
> > > A new version of I-D, 
> draft-ietf-krb-wg-otp-preauth-00.txt has been

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Oct 2007 11:11:09 -0700

Maybe what's really needed is a more fully-specified protocol (or  
adaptation of the existing protocol).  I'm concerned with how the  
protocol "falls back" in the absence of some of these items (because  
they don't exist, or are inherently identical to other items).   
Suppose there's no PIN, or no Kerberos password because the KDC  
itself is acting as the OTP server?  That should simplify the user  
interaction without compromising security.  Perhaps what you two say  
covers that properly and I just can't tell.

I think GR's OTP draft covers that adequately for normal authentication.

On Oct 30, 2007, at 10:37 AM, Tim Alsop wrote:

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

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 18:27:01 -0000

Gareth,

Ok, I understand better now. However, I still cannot see any need to use
the password change protocol for something that is can be implemented
quite simply, and securely, and since there is already an exchange
between client and kdc to get the tgt using pre-auth data, you might as
well use this msg exchange to pass the new pin (as we do at moment in
our product). I cannot currently see any security issue with this
approach, or any reason why using the password change after getting the
tgt will be more secure, or better for any reason. If there is a reason
why you think this approach is better, can you explain ?

Thanks,
Tim

-----Original Message-----
Sent: 30 October 2007 17:56

Tim,

Thanks

--Gareth

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 18:31:11 -0000

See inline, below :

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]] 
Sent: 30 October 2007 18:11
To: Tim Alsop
Cc: IETF Kerberos Working Group; Richards,Gareth
Subject: Re: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim> can you explain what you mean by "fall back" ? This is not clear to
me.

Tim> There will always be storage in the kdc db for Kerberos passwords,
or keys derived from passwords. The password may be stored, but not
used, or may be set to a random value, but it will always be there ( or
a key derived from it will be there ).

Tim> If the OTP server is running on KDC host, then the functionality we
are discussing is exactly same as if the OTP server is on another host.

Tim> By "normal authentication" are you referring to being able to get a
TGT using OTP, or changing PIN (as this email exchange is discussing
this subject) ?

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Oct 2007 12:58:33 -0700

Let's take an extreme case:  there is no Kerberos password, only an  
OTP seed and PIN, and that's stored in the KDC's database.  There is  
no OTP server, and no challenge data.  The PIN is stored "in the  
clear" because it must be used as input to the OTP algorithm so the  
KDC can generate the same OTP token value that the user has.

Now that I think about it I see no need for *any* protocol  
enhancements in this case.  kpasswdd should simply interpret the new  
"password" as the PIN and store it accordingly.  The same argument  
applies if there is no PIN, so I think I've just demonstrated my  
concern is moot.

The real extreme case is neither a Kerberos password, nor an OTP PIN,  
but in that case you wouldn't need to change either one of them.

---

From: "Tim Alsop" <[email-masked]>
Date: Tue, 30 Oct 2007 20:25:57 -0000

Henry,

The world I work in, and have to consider is the commercial software
world, where vendors products need to interoperate, so I am only
currently considering the case where a product such as the RSA SecurID
Authentication Server is being used with a KDC. In this case it would
not be possible to make the KDC implement the OTP protocol, because that
is private to RSA and owned by them, and cannot therefore be implemented
in the KDC code in the way that you suggest. Perhaps you are referring
to an OTP technology that is open source based and therefore easy to add
to the KDC code in the way you suggest ?

Anyway, I think we are in sync now. Thanks for your feedback.

Regards,
Tim

-----Original Message-----
Sent: 30 October 2007 19:59

On Oct 30, 2007, at 11:31 AM, Tim Alsop wrote:

> ----------------------------------------------------------------------

> --

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Oct 2007 16:39:08 -0700

IMO the real issues with OTP are not the Kerberos protocol, but the  
associated implementation and deployment issues.  I had a long  
exchange with Nico Williams on [email-masked] on  
the subject, which I will not try to repeat here.

You'll enjoy the second-to-last post in the thread.  ;-)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Oct 2007 16:53:52 -0700

Oops, here's the archive of the thread:  <http://marc.info/? 
t=118099320400006&r=1&w=2>

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 30 Oct 2007 18:18:31 -0700

With regard to the open technology concern, HOTP algorithm as specified
in RFC 4226 is becoming an industry standard (My claim :). It is
endorsed by companies in Open Authentication (OATH) community and
others. It is considered the initial default list of OTP algorithm for
the work currently in IETF KeyProv work group.

It may be of useful to allow extensibility to support other third party
OTP algorithms such as SecurID with a delegation, instead of embedding
in the KDC.

For the KDC side embedded HOTP validation, there is some open source
code, e.g., SafeHaus / Apache LDAP + Kerberos implementation. The
protocol to use OTP in pre-auth is something missing in my
understanding.

- Ming

> Sent: Tuesday, October 30, 2007 4:39 PM
> To: Tim Alsop
> IMO the real issues with OTP are not the Kerberos protocol, 
> but the associated implementation and deployment issues.  I 
> had a long exchange with Nico Williams on 
> [email-masked] on the subject, which I will 
> not try to repeat here.
> 
> > not be possible to make the KDC implement the OTP protocol, because 
> > that is private to RSA and owned by them, and cannot therefore be 
> > implemented in the KDC code in the way that you suggest. 
> Perhaps you 
> > are referring to an OTP technology that is open source based and 
> > therefore easy to add to the KDC code in the way you suggest ?
> >
> The opinions expressed in this message are mine, not those of 
> Caltech, JPL, NASA, or the US Government.

---

From: "Tim Alsop" <[email-masked]>
Date: Wed, 31 Oct 2007 07:54:47 -0000

Henry,

Thank you for this. I read the reference you mentioned, and I think it
is worth mentioning that the market now is very different to 10 years
ago when Kerberos and OTP were not so popular and widely used as today.

Anyway, this is going off subject, since we are supposed to be
discussing the PIN change.

Regards,
Tim

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]] 
Sent: 30 October 2007 23:54
To: Tim Alsop
Cc: IETF Kerberos Working Group; Gareth Richards; Henry B. Hotz
Subject: Re: [Ietf-krb-wg] PIN change in OTP pre-authentication

On Oct 30, 2007, at 4:39 PM, Henry B. Hotz wrote:

>> that

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 31 Oct 2007 12:02:39 -0000

Tim,

When I produced the first version of this draft, I considered handling
PIN change in-line in a similar manner to your implementation and how it
is handled in the OTP EAP method (RFC 4793). Really the only reason I
went the current approach was that the password change protocol already
existed and I thought it worth exploring the possibility of using it for
PIN change via a PIN change service.  As I said, I thought it worth
trying to model this on the way password change is handled.  

One other minor reason was that PIN management can be seen as a separate
process to authentication using the OTP and having a PIN
change/management service would allow PIN change to be handled at other
times.

One possible issue with the current approach is ensuring that the PIN
change occurs.  The proposal currently relies on only allowing tickets
for the PIN change service to be issued until the PIN is changed but I'm
not sure if this is even possible.  (Hence the original question.)  But
wouldn't this issue also apply to password change?

Thanks

--Gareth

> 
> Ok, I understand better now. However, I still cannot see any 
> need to use the password change protocol for something that 
> is can be implemented quite simply, and securely, and since 
> there is already an exchange between client and kdc to get 
> the tgt using pre-auth data, you might as well use this msg 
> exchange to pass the new pin (as we do at moment in our 
> product). I cannot currently see any security issue with this 
> approach, or any reason why using the password change after 
> getting the tgt will be more secure, or better for any 
> reason. If there is a reason why you think this approach is 
> better, can you explain ?
> 
> Thanks,
> Tim
> 
> authentication exchange but it is really at the end of the 
> process.  The user's OTP value has been validated and the OTP 
> auth server returns a "new PIN requested" response.  
> 
> The sequence would therefore be an AS-REQ with with the OTP 
> data and an AS-REP with the "new PIN" asdata.  The 
> pre-authentication would then be complete and the user would 
> have a TGT.  The proposal was that this TGT would then be 
> used to request a ticket for the PIN change service and the 
> PIN would be changed in a similar manner to the handling of 
> password change.
> 
> I am not sure if this is the best way to handle it but I was 
> trying to model the sequence on password change following 
> authentication.
> 
> Thanks
> 
> --Gareth
> 
> > Gareth,
> > 
> normally only 
> > suggest, the client code would have to use change password msg 
> > exchange with KDC to change the pin during its attempt to 
> authenticate 
> > a user...
> > new pin is requested, so that the KDC can know the new pin, and use 
> > this new pin to pass to auth server - unless I have 
> misunderstood your 
> > Surely the approach we use is ok, since we are sending the new pin 
> > over a secure channel to kdc, and this new pin is passed to the OTP 
> > auth server that requested the new pin for the user.
> > 
> > Thanks,
> > Tim
> > 
> the KDC and 
> > I was not suggesting that the password change service be used to 
> > change the PIN but by a PIN change service supporting the 
> > ChangePasswdData.
> > 
> > Thanks
> > 
> > --Gareth
> > > 
> > > > [mailto:[email-masked]] On Behalf Of 
> Richards, 
> > > > Gareth

---

From: "Tim Alsop" <[email-masked]>
Date: Wed, 31 Oct 2007 12:31:18 -0000

Gareth,

This explanation helps me understand better. Thankyou.

I can now see a potential use case where PIN changing would be more
flexible if it was separated from the authentication. For example, a
user might find it difficult to remember their current PIN, so they want
to change it to something easier to remember, and this on-demand PIN
change could be useful for such cases, as long as the new PIN conforms
to a configured PIN policy. As you have indicated, this would be best
implemented using the existing change password protocol, or something
based on it - if this is technically possible, and does not weaken the
security in any way ...

When using Kerberos with passwords, normally tools such as kinit are
used to get a TGT, and if password has expired and needs changing the
TGT is not issued until the user has changed their password, and
re-authenticated using the new password. The same should apply to PIN
changing. In our product, we only issue the TGT after the required PIN
change is successful, so this is an advantage of using our current
approach rather than getting the TGT and then using this TGT to change
PIN via a change password like protocol, as you suggested might be good.

So, in summary - if the change password protocol is used in some way,
you might be making it less secure because I could try to authenticate,
and be asked to change my PIN, but since I have already been issued with
a TGT, I might decide to ignore the request to change PIN and use the
TGT already issued instead. If the reason for server requesting the PIN
change was due to some compromise of PIN or for some other security
reason, then the fact I have been issued with a TGT, which I can then
use to authenticate to applications is not good security ...

Thanks,
Tim

-----Original Message-----
From: Richards, Gareth [mailto:[email-masked]] 
Sent: 31 October 2007 12:03
To: Tim Alsop
Cc: IETF Kerberos Working Group
Subject: RE: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim,

Thanks

--Gareth

> Richards, Gareth

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 31 Oct 2007 16:05:42 -0000

Tim,

Thanks a lot for the help.

My concern with the current approach was the one that you described in
that it may be possible for the user to ignore the PIN change and use
the TGT issued by the KDC to access services.  My initial thoughts were
that the KDC would not issue tickets for anything other than the PIN
change service until the PIN is changed but I wasn't at all sure if this
was even possible and from what you say, this is not how password change
works.  

Even if the PIN change service is used, it looks as if the current text
in section 2.2 of the I-D is wrong.

   If, following successful validation of a PA-OTP-REQUEST in a
   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
   will include a PA-OTP-PIN-CHANGE element in the armored data of the
   PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP.  This data can be
   used to return a new PIN to the user if the KDC has updated the PIN
   or to indicate to the user that they must change their PIN.

   In the latter case, user PIN change shall be handled by a PIN change
   service supporting the ChangePasswdData in a KRB_AP_REQ as described
   in [RFC3244].  If such a user PIN change is required then the KDC
   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
   only issues tickets for the PIN change service until the PIN has been
   changed. 

It appears as if the last sentence should be something like:

If such a PIN change is required then the KDC SHALL return a TGT in the
KRB_AS_REP but it is RECOMMENDED that the client application should not
release TGT until the PIN change has been completed.

This is still not totally satisfactory but is probably an improvement.

Thanks

--Gareth

> I can now see a potential use case where PIN changing would 
> be more flexible if it was separated from the authentication. 
> For example, a user might find it difficult to remember their 
> current PIN, so they want to change it to something easier to 
> remember, and this on-demand PIN change could be useful for 
> such cases, as long as the new PIN conforms to a configured 
> PIN policy. As you have indicated, this would be best 
> implemented using the existing change password protocol, or 
> something based on it - if this is technically possible, and 
> does not weaken the security in any way ...
> 
> When using Kerberos with passwords, normally tools such as 
> kinit are used to get a TGT, and if password has expired and 
> needs changing the TGT is not issued until the user has 
> changed their password, and re-authenticated using the new 
> password. The same should apply to PIN changing. In our 
> product, we only issue the TGT after the required PIN change 
> is successful, so this is an advantage of using our current 
> approach rather than getting the TGT and then using this TGT 
> to change PIN via a change password like protocol, as you 
> suggested might be good.
> 
> So, in summary - if the change password protocol is used in 
> some way, you might be making it less secure because I could 
> try to authenticate, and be asked to change my PIN, but since 
> I have already been issued with a TGT, I might decide to 
> ignore the request to change PIN and use the TGT already 
> issued instead. If the reason for server requesting the PIN 
> change was due to some compromise of PIN or for some other 
> security reason, then the fact I have been issued with a TGT, 
> which I can then use to authenticate to applications is not 
> good security ...
> 
> Thanks,
> Tim
> 
> When I produced the first version of this draft, I considered 
> handling PIN change in-line in a similar manner to your 
> implementation and how it is handled in the OTP EAP method 
> (RFC 4793). Really the only reason I went the current 
> approach was that the password change protocol already 
> existed and I thought it worth exploring the possibility of 
> using it for PIN change via a PIN change service.  As I said, 
> I thought it worth trying to model this on the way password 
> change is handled.  
> 
> One other minor reason was that PIN management can be seen as 
> a separate process to authentication using the OTP and having 
> a PIN change/management service would allow PIN change to be 
> handled at other times.
> 
> One possible issue with the current approach is ensuring that 
> the PIN change occurs.  The proposal currently relies on only 
> allowing tickets for the PIN change service to be issued 
> until the PIN is changed but I'm not sure if this is even 
> possible.  (Hence the original question.)  But wouldn't this 
> issue also apply to password change?
> 
> Thanks
> 
> --Gareth
> 
> > 
> > Ok, I understand better now. However, I still cannot see 
> any need to 
> > use the password change protocol for something that is can be 
> > implemented quite simply, and securely, and since there is 
> already an 
> > exchange between client and kdc to get the tgt using pre-auth data, 
> > you might as well use this msg exchange to pass the new pin 
> (as we do 
> > at moment in our product). I cannot currently see any 
> security issue 
> > with this approach, or any reason why using the password 
> change after 
> > getting the tgt will be more secure, or better for any reason. If 
> > there is a reason why you think this approach is better, can you 
> > explain ?
> > 
> > Thanks,
> > Tim
> > 
> process.  
> > The user's OTP value has been validated and the OTP auth server 
> > returns a "new PIN requested" response.
> > 
> data and 
> > an AS-REP with the "new PIN" asdata.  The pre-authentication would 
> > then be complete and the user would have a TGT.  The 
> proposal was that 
> > this TGT would then be used to request a ticket for the PIN change 
> > service and the PIN would be changed in a similar manner to the 
> > handling of password change.
> > 
> > > > In our product, we don't have pin change as part of the 
> protocol 
> > > > either.
> > > > > [root@shrek newkdc]# kinit talsop Password for talsop@SHREK:
> > > > > [root@shrek newkdc]# kinit talsop Password for talsop@SHREK:

---

From: "Tim Alsop" <[email-masked]>
Date: Wed, 31 Oct 2007 16:13:00 -0000

Gareth,

See feedback below, inline :

Thanks,
Tim
-----Original Message-----
From: Richards, Gareth [mailto:[email-masked]] 
Sent: 31 October 2007 16:06
To: Tim Alsop
Cc: IETF Kerberos Working Group
Subject: RE: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim,

My concern with the current approach was the one that you described in
that it may be possible for the user to ignore the PIN change and use
the TGT issued by the KDC to access services.  

[ With our product, when using OTP to get a TGT, this is not possible
since the TGT is not sent from KDC to client until after the PIN has
been changed. With this in mind, using the change password protocol to
change PIN only has the advantage that a user can change PIN on demand.
It does nothing to improve the way a PIN is changed when authenticating.
]

[ I know most of this recent email discussion relates to PIN changing,
but with products such as RSA SecurID, there is another case, where the
user is asked for next tokencode to allow them to re-sync their token.
This is handled in our code the same way as changing PIN, but it does
not involve sending a new PIN to KDC, instead the next tokencode is sent
so it can be passed to RSA auth server. How does your proposal handle
this requirement ? ]

My initial thoughts were

[ I am not clear what you mean by issuing ticket for the PIN change
service. The user is authenticating so tickets will be issued to the
Kerberos client he/she is using and stored in credentials cache ]

[ I guess it might be ok if the TGT received at client is held in memory
and not stored in cache file which is accessible to other apps until PIN
change is successful. It would of course be even better if the TGT was
not even issued until the PIN change was successful ]

[ yes, maybe ]

Thanks

--Gareth

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 31 Oct 2007 16:30:25 -0000

Tim

Resynchronisation of a token (such as SecurID's next tokencode mode) is
handled by the KDC returning a "nextOTP" flag in the response it returns
to the client following the initial authentication attempt.  The client
is then required to re-issue the authentication request using the OTP
for the next token state.  The next time slot in the case of SecurID.

--Gareth 

> From: Tim Alsop [mailto:[email-masked]] 
> Sent: 31 October 2007 16:13
> To: Richards, Gareth
> Cc: IETF Kerberos Working Group; Tim Alsop
> My concern with the current approach was the one that you 
> described in that it may be possible for the user to ignore 
> the PIN change and use the TGT issued by the KDC to access services.  
> 
> [ With our product, when using OTP to get a TGT, this is not 
> possible since the TGT is not sent from KDC to client until 
> after the PIN has been changed. With this in mind, using the 
> change password protocol to change PIN only has the advantage 
> that a user can change PIN on demand.
> [ I know most of this recent email discussion relates to PIN 
> changing, but with products such as RSA SecurID, there is 
> another case, where the user is asked for next tokencode to 
> allow them to re-sync their token.
> This is handled in our code the same way as changing PIN, but 
> it does not involve sending a new PIN to KDC, instead the 
> next tokencode is sent so it can be passed to RSA auth 
> server. How does your proposal handle this requirement ? ]
> 
> My initial thoughts were
> that the KDC would not issue tickets for anything other than 
> the PIN change service until the PIN is changed but I wasn't 
> at all sure if this was even possible and from what you say, 
> this is not how password change works.  
> 
> [ I am not clear what you mean by issuing ticket for the PIN 
> change service. The user is authenticating so tickets will be 
> issued to the Kerberos client he/she is using and stored in 
> credentials cache ]
> 
> Even if the PIN change service is used, it looks as if the 
> current text in section 2.2 of the I-D is wrong.
> 
> 
> If such a PIN change is required then the KDC SHALL return a 
> TGT in the KRB_AS_REP but it is RECOMMENDED that the client 
> application should not release TGT until the PIN change has 
> been completed.
> 
> [ I guess it might be ok if the TGT received at client is 
> held in memory and not stored in cache file which is 
> accessible to other apps until PIN change is successful. It 
> would of course be even better if the TGT was not even issued 
> until the PIN change was successful ]
> 
> > flexible if it was separated from the authentication.
> > For example, a user might find it difficult to remember 
> their current 
> > PIN, so they want to change it to something easier to remember, and 
> > this on-demand PIN change could be useful for such cases, 
> as long as 
> > the new PIN conforms to a configured PIN policy. As you have 
> > indicated, this would be best implemented using the existing change 
> > password protocol, or something based on it - if this is 
> technically 
> > possible, and does not weaken the security in any way ...
> > 
> kinit are 
> some way, 
> > you might be making it less secure because I could try to 
> > authenticate, and be asked to change my PIN, but since I 
> have already 
> > been issued with a TGT, I might decide to ignore the 
> request to change 
> > PIN and use the TGT already issued instead. If the reason 
> for server 
> > requesting the PIN change was due to some compromise of PIN or for 
> > some other security reason, then the fact I have been issued with a 
> > TGT, which I can then use to authenticate to applications 
> is not good 
> > security ...
> > 
> > Thanks,
> > Tim
> > 
> > PIN change in-line in a similar manner to your 
> implementation and how 
> > it is handled in the OTP EAP method (RFC 4793). Really the 
> only reason 
> > I went the current approach was that the password change protocol 
> > already existed and I thought it worth exploring the possibility of 
> > using it for PIN change via a PIN change service.  As I said, I 
> > thought it worth trying to model this on the way password change is 
> > handled.
> > 
> > One other minor reason was that PIN management can be seen as a 
> > separate process to authentication using the OTP and having a PIN 
> > change/management service would allow PIN change to be handled at 
> > other times.
> > 
> > for the PIN change service to be issued until the PIN is 
> changed but 
> > I'm not sure if this is even possible.  (Hence the original 
> question.)  
> > But wouldn't this issue also apply to password change?
> > 
> > Thanks
> > 
> > --Gareth
> > 
> > >

---

From: "Tim Alsop" <[email-masked]>
Date: Wed, 31 Oct 2007 16:31:12 -0000

Gareth,

Ok, thanks. I have to admit that I have not yet read your draft in
detail so I didn't notice you had already taken care of this
requirement.

Take care,
Tim

-----Original Message-----
From: Richards, Gareth [mailto:[email-masked]] 
Sent: 31 October 2007 16:30
To: Tim Alsop
Cc: IETF Kerberos Working Group
Subject: RE: [Ietf-krb-wg] PIN change in OTP pre-authentication

Tim

--Gareth

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 31 Oct 2007 10:45:21 -0700

The KDC should treat a "PIN change required" the same as an expired  
password.  No tickets should be issued except for the PIN change  
service.  Once the PIN has been changed then the authentication can  
be restarted from the beginning.

Many client interfaces already understand the expired password  
scenario, and prompt the user appropriately.  They could (SHOULD)  
handle PIN change the same way.

The KDC should not depend on client behavior to guarantee security.

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 31 Oct 2007 17:53:17 -0000

Henry,

I have tried to write the current I-D so that PIN change works in the
same way as password change.  Section 2.2 describes the PIN change
process as follows:

What I have been trying to find out is if this is even possible.  I am
not sure of the details of how password change works and so wasn't sure
if it is possible for the KDC to issue a TGT in this way and so require
the user to change their PIN before continuing.  From what you say, it
looks as if what I currently have is correct.  

Thanks

--Gareth

> Sent: 31 October 2007 17:45
> To: Richards, Gareth; Tim Alsop
> The KDC should treat a "PIN change required" the same as an 
> expired password.  No tickets should be issued except for the 
> PIN change service.  Once the PIN has been changed then the 
> authentication can be restarted from the beginning.
> 
> Many client interfaces already understand the expired 
> password scenario, and prompt the user appropriately.  They 
> could (SHOULD) handle PIN change the same way.
> 
> described in 
> > the TGT issued by the KDC to access services.  My initial thoughts 
> > were that the KDC would not issue tickets for anything 
> other than the 
> > PIN change service until the PIN is changed but I wasn't at 
> all sure 
> > if this was even possible and from what you say, this is not how 
> > password change works.
> >
> > Even if the PIN change service is used, it looks as if the current 
> > text in section 2.2 of the I-D is wrong.
> >
> >
> >    KRB_AS_REQ, the KDC requires that the user changes their 
> PIN then 
> > it
> >    PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP.  
> This data can 
> > be
> > If such a PIN change is required then the KDC SHALL return a TGT in 
> > the KRB_AS_REP but it is RECOMMENDED that the client application 
> > should not release TGT until the PIN change has been completed.
> >

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Oct 2007 15:34:46 -0500

> so would be required to change their PIN before proceeding.

Sortof.

In order to use a separate password change service you must be able to
obtain a ticket for it.  But you can't, since the password is expired.
This chicken-egg problem is resolved by allowing the user to obtain an
INITIAL ticket to talk to the password changing service -- the *old*
password is used to authenticate the user to the AS.

However, in the case of an OTP device in a resync-type state you
[typically] can't do anything to authenticate the user, even
temporarily, without going through the OTP resync procedure, by which
point you wouldn't need to use a password changing service any longer.

So, how to deal with this?  Two ways:

a) use PKINIT with anon client + FAST armor to protect the OTP resync
   exchanges done in pre-auth

b) use PKINIT with anon client to get an initial ticket for the anon
   client principal to authenticate to a password changing server and
   then use that service to resync the OTP.

(b) seems like more work than (a), except that OTPs come in many
flavors, and a one-size-fits-all OTP resync pre-auth may not be easy
(but I'm not an expert on OTPs).

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 31 Oct 2007 14:55:16 -0700

>    SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it

s/SHALL/MAY/

I'd say SHALL NOT, but I suppose we ought to allow for local policy  
and OTP implementation variations.  I'm assuming that it's actually  
possible to authenticate someone with the old PIN when this happens.   
If that's not true then I think the scenario is outside the scope of  
this standard.