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

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 1 Nov 2007 10:57:59 -0000

Nico,

Thanks for the response.  

The part I missed was that the KDC should return in the AS-REP a ticket
for the PIN change service with the INITIAL flag set rather than
returning a TGT that is then used via the TGS to get a ticket for the
service.   I would think that this would answer my concerns about
enforcing the PIN change.  In this situation, the OTP would be validated
using the old PIN in the same manner as you described for passwords.

I don't think re-synchronisation is an issue.  The current I-D uses the
FAST armor to protect the pre-auth exchange and if the KDC detects that
re-synchronization is required, it returns a response to the client
requiring it to re-issue the request using the next OTP value.  (Next
could be counter, time or whatever the token uses.)

Maybe the wording in section on PIN change in the I-D should be
something like this:

          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 MAY return a
          TGT in the KRB_AS_REP but it is RECOMMENDED that it return
          an INITIAL ticket for the PIN change service until the PIN
          has been changed.

--Gareth
 
> 
> On Tue, Oct 30, 2007 at 02:24:21PM +0000, Richards, Gareth wrote:
> > 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?  
> 
> 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
> -- 
> 
> 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Nov 2007 11:55:45 -0500

> using the old PIN in the same manner as you described for passwords.

As long as it's possible to limit what a user with an expired OTP PIN
can do and as long as it's possible to tie the change PIN process to the
old PIN then you're fine.

> could be counter, time or whatever the token uses.)

Ah, so OTP resyncs will be done through PA-DATA and PIN changes through
a PIN/password changing service.

That looks good to me.

Of course, PINs, being simpler than passwords, are a good candidate to
change via PA-DATA, and you get to avoid having the issue of the
multiplicity of deployed password changing services.  So I would still
encourage you to do the PIN change via PA-DATA if it's easy enough.  But
PIN change through a separate service will do if you must do it that
way.

(Hmmm, maybe we should build the password changing service into
PA-DATA... or at least into new PDUs to be used on port 88.)

Nico

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 1 Nov 2007 17:30:12 -0000

Nico,

> 
> Of course, PINs, being simpler than passwords, are a good 
> candidate to change via PA-DATA, and you get to avoid having 
> the issue of the multiplicity of deployed password changing 
> services.  So I would still encourage you to do the PIN 
> change via PA-DATA if it's easy enough.  But PIN change 
> through a separate service will do if you must do it that way.
> 

I did consider doing PIN change in-line using PA-DATA.  It would be easy
enough.  As I mentioned to Tim, one reason I went with the PIN change
service approach was to explore the possibility of handling PIN change
in a similar manner to password change.  The  password change protocol
already existed and I thought it worth trying to use it.  The other one
was that having a PIN change service rather than handling it in the
pre-authentication exchange would allow PIN change to be done at other
times.

I have no problem with changing to a PA-DATA method if it is the better
way but it would be a shame to loose the ability to change PINs when not
authenticating.

--Gareth

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Nov 2007 12:36:11 -0500

> way but it would be a shame to loose the ability to change PINs when not

If you have any need for localization of arbitrary messages sent by the
KDC, then a separate PIN changing service is the best way to go.

If so then you'll want to look at proposing an extension to
draft-ietf-krb-wg-kerberos-set-passwd and, perhaps, RFC3244.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Nov 2007 14:49:45 -0400

> way but it would be a shame to loose the ability to change PINs when not

Yes, it would.  It would also be a bad idea to assume that any KDC is 
capable of handling a PIN-change operation, since there are some 
widely-depoyed KDC implementations in which there can be multiple slave 
KDC's but only the master can handle operations which change the database.

I'd much rather see a separate PIN change operation than see this embedded 
into the AS exchange.

-- Jeff

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 1 Nov 2007 18:53:51 -0000

Richard,

There has to be some sort of authentication when changing PIN, e.g. by
providing the correct Kebreros password, or old PIN ... I therefore
think that it is still possible to implement this so that a PIN can be
changed on demand, but the OTP auth server needs to support this
capability. I think the auth server is the issue, since most that I am
aware of decide if the PIN needs changing, not the user/application
(e.g. KDC). If it is possible programmatically to ask for a new PIN for
a particular user, then the implementation will be simple and PA-DATA
can be used as suggested by Nico in earlier email.

Thanks,
Tim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: 01 November 2007 18:50
To: Richards, Gareth; Nicolas Williams
Cc: IETF Kerberos Working Group; Jeffrey Hutzelman
Subject: Re: [Ietf-krb-wg] PIN change in OTP pre-authentication

Yes, it would.  It would also be a bad idea to assume that any KDC is 
capable of handling a PIN-change operation, since there are some 
widely-depoyed KDC implementations in which there can be multiple slave 
KDC's but only the master can handle operations which change the
database.

I'd much rather see a separate PIN change operation than see this
embedded 
into the AS exchange.

-- Jeff

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 1 Nov 2007 18:57:10 -0000

Oops. Sorry Gareth, I just noticed I called you Richard by mistake.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tim Alsop
Sent: 01 November 2007 18:54
To: Jeffrey Hutzelman; Richards, Gareth; Nicolas Williams
Cc: IETF Kerberos Working Group
Subject: Re: [Ietf-krb-wg] PIN change in OTP pre-authentication

Richard,

Thanks,
Tim

-----Original Message-----

-- Jeff