Subject: Re: [Ietf-krb-wg] OTP draft - PIN change service

From: <[email-masked]>
Date: Wed, 1 Jul 2009 12:31:07 -0400

Following discussions off-list, I have come to the conclusion that it
might be better to remove the handling of PIN change from the current
draft and simply have the KDC return an error code (similar to the
current KDC_ERR_KEY_EXPIRED).

The handling of PIN change could then be handled by a new draft
specifying a new protocol or possibly by a future Experimental extension
to the current draft.

--Gareth

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 30 June 2009 18:09
> To: [email-masked]; [email-masked]
> Subject: Re: [Ietf-krb-wg] OTP draft - PIN change service
> 
> Srini,
> 
> It looks as if you are right.  
> 
> I had assumed that PIN change would either be handled using 
> an existing mechanism that was already in place for the token 
> type or via a "PIN Change Service" as described in the 
> extract.  Since PIN change is similar to password change, I 
> had hoped that this could be handled using the existing 
> Kerberos password change system but it seems as if that was a 
> mistake.  Overloading an existing protocol is probably not a 
> good idea and I had not taken into account the fact that a 
> user could have multiple tokens or that multiple back-end OTP 
> servers could be involved.
> 
> 
> There are three main problems with the current approach:
> 
> 1) The existing ChangePasswordData in RFC3244 does not appear 
> to support a way for the client to inform the service which 
> token needs to have its PIN changed.  
> 
> 2) Generally, the client wouldn't even know which token the 
> user happened used and so wouldn't have the information to 
> provide anyway.
> 
> 3) Since the KDC would not generally be the OTP server 
> itself, the KDC itself cannot be assumed to have the 
> information required to change the PIN either.
> 
> With hindsight, it seems that it would probably be better if 
> the OTP pre-authentication draft leaves the actual method of 
> PIN change out of scope in the same way that I believe 
> RFC4120 does not describe how to carry out password change.  
> This would then leave it open for a separate PIN change protocol. 
> 
> So I suggest re-wording section 2.3 to remove mention of RFC3244.
> 
> --Gareth
>  
> 
> 
> ________________________________
> 
> 	From: Srinivas Cheruku [mailto:[email-masked]] 
> 	Sent: 22 June 2009 12:00
> 	To: Richards, Gareth; [email-masked]
> 	Subject: OTP draft - PIN change service
> 	
> 	
> 
> 	Hi,
> 
> 	 
> 
> 	From OTP draft,
> 
> 	 
> 
> 	   In the user is required to change their PIN then it 
> is recommended
> 	   that user PIN change be handled by a PIN-change 
> service supporting
> 
> 	   the ChangePasswdData in a AP-REQ as described in 
> [RFC3244 <http://tools.ietf.org/html/rfc3244> ].  
> 
> 	 
> 
> 	Just saying as above will not suffice as there are 
> issues which needs to be addressed for PIN change service are:
> 
> 	    1) A standard port needs to be defined for the PIN 
> change service or at least a way for the current RFC3244 
> password change service to distinguish between PIN and 
> Kerberos password changes
> 
> 	    2) The PIN change service would need a way of 
> telling which token of the user is having its PIN change
> 
> 	    3) Related to issue 2, the PIN change service would 
> need to be able to determine which OTP-server is handling the 
> token(Multiple OTP servers can be used in an organization).
> 
> 	 
> 
> 	Thanks,
> 	Srini
> 
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 10:55:45 -0400

Srini,

I am not sure if the PIN change issue was ever fully resolved.  Since it
appears as if handling of PIN change by the current password change
service will not work, there appear to be two possibilities.

1) Handle PIN change in-line as part of the pre-authentication exchange
as you have requested.

2) Leave PIN change out of scope to be handled by some additional draft
or an extension of this draft.

I was initially reluctant to handle PIN change as part of the
authentication process but I am starting to think that we might need to
re-visit the possibility.  The POTP EAP mechanism [RFC4793] handles PIN
change in-line using a New PIN TLV.  Would something along these lines
meet your requirements?
In this sort of exchange, the KDC would return a PA-OTP-PIN-CHANGE and
the client would send an additional AS-REQ containing a
PA-OTP-PIN-CHANGE containing the new PIN value before the KDC responded
with the final AS-REP.

Apart from not being able to use the password change service, there also
appear to be issues regarding multiple tokens and OTP servers.
Generally, the client will not know which token was used to authenticate
or which server issued that token and both pieces of information would
be required by a PIN change service.  

It looks as if the PA-OTP-PIN-CHANGE would either have to be extended to
include this information and so provide the client with full context or
PIN change should be handled in-line while the KDC has that context.

If more pre-authentication mechanisms are created to work with FAST then
maybe credential management might become a general issue.  Should each
mechanism handle credential change in its own way during the
authentication exchange?

--Gareth

> Sent: 01 July 2009 17:31
> Following discussions off-list, I have come to the conclusion 
> that it might be better to remove the handling of PIN change 
> from the current draft and simply have the KDC return an 
> error code (similar to the current KDC_ERR_KEY_EXPIRED).
> 
> The handling of PIN change could then be handled by a new 
> draft specifying a new protocol or possibly by a future 
> Experimental extension to the current draft.
> 
> --Gareth
> 
> > I had assumed that PIN change would either be handled using an 
> > existing mechanism that was already in place for the token 
> type or via 
> > a "PIN Change Service" as described in the extract.  Since 
> PIN change 
> > is similar to password change, I had hoped that this could 
> be handled 
> > using the existing Kerberos password change system but it 
> seems as if 
> > that was a mistake.  Overloading an existing protocol is 
> probably not 
> > a good idea and I had not taken into account the fact that a user 
> > could have multiple tokens or that multiple back-end OTP 
> servers could 
> > be involved.
> > 
> >

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 15 Jul 2009 10:43:12 +0530

Gareth,

Please see my comments inline.

Thanks,
Srini

>  From: [email-masked] [mailto:[email-masked]]
>  Sent: 13 July 2009 20:26
>  Subject: RE: [Ietf-krb-wg] OTP draft - PIN change service
>  
>  Srini,
>  

[Srinivas Cheruku] yes, I think this approach (sending another AS-REQ with
PIN change info) is better.

>  be required by a PIN change service.

[Srinivas Cheruku] correct. 

>  PIN change should be handled in-line while the KDC has that context.

[Srinivas Cheruku] I think handling the PIN change by KDC is better and
shouldn't be a part of client. If client is provided the context and if it
has to contact the OTP Server, then the user might as well use the OTP
vendor's PIN change service and do this. Don't think it is good idea to give
the full context to client and client code being changed to handle this. It
is better to have the OTP api code at KDC itself.

>  mechanism handle credential change in its own way during the

[Srinivas Cheruku] I am not sure on this.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Jul 2009 18:36:35 -0700

Structurally the KDC is usually a read-only daemon, and updates to the  
DB are handled by kadmind or kpasswdd (which only exist on the  
master).  I'm not making an argument for or against, but I think the  
implications need to be considered.

That BTW, was why I recommended doing PIN change via the password  
change protocol.  My apologies that the suggestion wasn't as good as  
it needed to be.  I've found a lot of similar mapping issues dealing  
with PKINIT deployment.

> PIN change info) is better.

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

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 05:25:56 -0400

Henry,

This issue was also raised Jeff when PIN change was last discussed on
the list and so I kept it out of the AS exchange.  But since issues have
now come up with handling it using a separate service, I'm in two minds
as to which is the best approach.

Generally, I would think that the KDC would not be the OTP server and
would communicate with the actual server to carry out the
authentication.  In this situation, I would think that all instances
could carry out the PIN change.  But the draft does not require that
this be the case and there is nothing to stop the OTP code being
embedded in the KDC.  If the KDC is read-only then there would be an
issue.

If we can't assume that the KDC can handle the PIN change then it will
need to be done by a new service and since RFC3244 can't handle it,
there will need to be a new one defined.  This will then require that
the client is given sufficient information to allow the service to
change the correct PIN.  

As I mentioned in my previous email, I am starting to wonder if this is
a generic problem.  How should pre-authentication mechanisms added to
the pre-auth framework handle credential change?

--Gareth

> From: Henry B. Hotz [mailto:[email-masked]] 
> Sent: 16 July 2009 02:37
> To: Srinivas Cheruku
> Cc: Richards, Gareth; [email-masked]
> Structurally the KDC is usually a read-only daemon, and 
> updates to the DB are handled by kadmind or kpasswdd (which 
> only exist on the master).  I'm not making an argument for or 
> against, but I think the implications need to be considered.
> 
> That BTW, was why I recommended doing PIN change via the 
> password change protocol.  My apologies that the suggestion 
> wasn't as good as it needed to be.  I've found a lot of 
> similar mapping issues dealing with PKINIT deployment.
> 
> >> In this sort of exchange, the KDC would return a PA-OTP-PIN-CHANGE 
> >> and the client would send an additional AS-REQ containing a 
> >> PA-OTP-PIN-CHANGE containing the new PIN value before the KDC 
> >> responded with the final AS-REP.
> >>
> >
> > [Srinivas Cheruku] yes, I think this approach (sending 
> another AS- REQ 
> > with PIN change info) is better.
> 
> The opinions expressed in this message are mine, not those of 
> Caltech, JPL, NASA, or the US Government.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 19 Jul 2009 10:22:09 -0700

Whether KDC === OTP server or not, there is a general problem with  
scaling an OTP service to many servers while maintaining client  
response time.  Absent a general solution, all we can do is flag it as  
an issue which requires attention during implementation/deployment.

---

From: Larry Zhu <[email-masked]>
Date: Tue, 28 Jul 2009 10:08:09 +0000

[email-masked] wrote:

> 1) The existing ChangePasswordData in RFC3244 does not appear to support
> a way for the client to inform the service which token needs to have its
> PIN changed.

It does not. However it would be reasonable to interpret that the PIN for the current token, which is used to get a ticket for the kpassword service, is changed.

> 2) Generally, the client wouldn't even know which token the user
> happened used and so wouldn't have the information to provide anyway.

The KDC need to find it out in order to validate the OTP. If we believe the OTP token is implicitly specified as stated in the previous point, the KDC can inject an authz data to identify the token and the PIN change service can use that information to change the PIN for the implicitly specified OTP token.

>3) Since the KDC would not generally be the OTP server itself, the KDC
>itself cannot be assumed to have the information required to change the
>PIN either.

Can we assume that the KDC can ask the OTP server for the info and return it as an authorization data element in the returned ticket.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 30, 2009 10:09 AM
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] OTP draft - PIN change service

Srini,

I had assumed that PIN change would either be handled using an existing
mechanism that was already in place for the token type or via a "PIN
Change Service" as described in the extract.  Since PIN change is
similar to password change, I had hoped that this could be handled using
the existing Kerberos password change system but it seems as if that was
a mistake.  Overloading an existing protocol is probably not a good idea
and I had not taken into account the fact that a user could have
multiple tokens or that multiple back-end OTP servers could be involved.

1) The existing ChangePasswordData in RFC3244 does not appear to support
a way for the client to inform the service which token needs to have its
PIN changed.

2) Generally, the client wouldn't even know which token the user
happened used and so wouldn't have the information to provide anyway.

3) Since the KDC would not generally be the OTP server itself, the KDC
itself cannot be assumed to have the information required to change the
PIN either.

With hindsight, it seems that it would probably be better if the OTP
pre-authentication draft leaves the actual method of PIN change out of
scope in the same way that I believe RFC4120 does not describe how to
carry out password change.  This would then leave it open for a separate
PIN change protocol.

--Gareth

        Hi,

        From OTP draft,

           In the user is required to change their PIN then it is
recommended
           that user PIN change be handled by a PIN-change service
supporting

           the ChangePasswdData in a AP-REQ as described in [RFC3244
<http://tools.ietf.org/html/rfc3244> ].

        Just saying as above will not suffice as there are issues which
needs to be addressed for PIN change service are:

            1) A standard port needs to be defined for the PIN change
service or at least a way for the current RFC3244 password change
service to distinguish between PIN and Kerberos password changes

            2) The PIN change service would need a way of telling which
token of the user is having its PIN change

            3) Related to issue 2, the PIN change service would need to
be able to determine which OTP-server is handling the token(Multiple OTP
servers can be used in an organization).

        Thanks,
        Srini

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 06:41:49 -0400

Larry,

I think that is is reasonable to assume that the PIN change will be for
the token used in the authentication.  I'm not sure what I was thinking
of with point 3 below, but I would think that the KDC would either have
knowledge of the token used from its communications with the OTP server
or could ask it.

If the KDC can obtain this information then I see no reason why this
could not be added to the authorization data of the service ticket which
could then provide any PIN change service with the required information.
Maybe this could also allow the service to tell the difference between
standard password change and PIN change requests.

The only alternative to this seems to be adding PIN change as part of
the authentication exchange.

--Gareth

> > 1) The existing ChangePasswordData in RFC3244 does not appear to 
> > support a way for the client to inform the service which 
> token needs 
> > to have its PIN changed.
> 
> It does not. However it would be reasonable to interpret that 
> the PIN for the current token, which is used to get a ticket 
> for the kpassword service, is changed.
> 
> The KDC need to find it out in order to validate the OTP. If 
> we believe the OTP token is implicitly specified as stated in 
> the previous point, the KDC can inject an authz data to 
> identify the token and the PIN change service can use that 
> information to change the PIN for the implicitly specified OTP token.
> 
> 
> itself, the KDC 
> Can we assume that the KDC can ask the OTP server for the 
> info and return it as an authorization data element in the 
> returned ticket.
> 
>            In the user is required to change their PIN then 
> it is recommended
>             1) A standard port needs to be defined for the 
> PIN change service or at least a way for the current RFC3244 
>             3) Related to issue 2, the PIN change service 
> would need to be able to determine which OTP-server is 
> handling the token(Multiple OTP servers can be used in an 
> organization).
> 
> 
> 
>         Thanks,
>         Srini
>

---

From: Larry Zhu <[email-masked]>
Date: Tue, 28 Jul 2009 22:51:47 +0000

The additional information returned by the OTP server and included by the KDC in the returned ticket can be passed to the OTP server when the PIN is changed. The complexity of adding this in the alternative approach to the AS exchange seems unwieldy.

Speaking as an individual, I support removing the PIN complexity out of this ID. It can be done in a separate draft.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 28, 2009 3:42 AM
To: Larry Zhu; [email-masked]; [email-masked]
Subject: RE: OTP draft - PIN change service

Larry,

--Gareth

---

From: "Henry B.Hotz" <[email-masked]>
Date: Tue, 28 Jul 2009 17:34:48 -0700

I suspect there is consensus that how we support PIN change is more  
complex than we thought, and it involves interactions we had not  
anticipated.  Since the rest of the ID is useful without it that would  
seem to recommend leaving it out as Larry says.

I would recommend that the PIN-change-needed code be defined, but that  
any behavior thereafter be undefined.

On Jul 28, 2009, at 3:51 PM, Larry Zhu wrote:

> The additional information returned by the OTP server and included  
> by the KDC in the returned ticket can be passed to the OTP server  
> when the PIN is changed. The complexity of adding this in the  
> alternative approach to the AS exchange seems unwieldy.
>
> Speaking as an individual, I support removing the PIN complexity out  
> of this ID. It can be done in a separate draft.
>
> --Larry
>

---

From: <[email-masked]>
Date: Wed, 29 Jul 2009 04:54:50 -0400

So it looks as if the consensus is to leave the handling of PIN change
out of scope of the current draft but to add some text around
recommending that the KDC add context information as authorization data
to the service ticket.  

It might still be worth removing mention of RFC3244 and so leave what
the service is that handles the PIN change totally out of scope. 

> From: Henry B.Hotz [mailto:[email-masked]] 
> Sent: 29 July 2009 01:35
> To: Larry Zhu
> Cc: Richards, Gareth; [email-masked]; [email-masked]
> I suspect there is consensus that how we support PIN change 
> is more complex than we thought, and it involves interactions 
> we had not anticipated.  Since the rest of the ID is useful 
> without it that would seem to recommend leaving it out as Larry says.
> 
> I would recommend that the PIN-change-needed code be defined, 
> but that any behavior thereafter be undefined.
> 
> > The additional information returned by the OTP server and 
> included by 
> > the KDC in the returned ticket can be passed to the OTP server when 
> > the PIN is changed. The complexity of adding this in the 
> alternative 
> > approach to the AS exchange seems unwieldy.
> >
> > I think that is is reasonable to assume that the PIN change will be 
> > for the token used in the authentication.  I'm not sure what I was 
> > thinking of with point 3 below, but I would think that the 
> KDC would 
> > either have knowledge of the token used from its 
> communications with 
> > the OTP server or could ask it.
> >
> > could not be added to the authorization data of the service ticket 
> > which could then provide any PIN change service with the required 
> > information.
> >> It does not. However it would be reasonable to interpret 
> that the PIN 
> >> for the current token, which is used to get a ticket for the 
> >> kpassword service, is changed.
> >>
> >> The KDC need to find it out in order to validate the OTP. If we 
> >> believe the OTP token is implicitly specified as stated in the 
> >> previous point, the KDC can inject an authz data to identify the 
> >> token and the PIN change service can use that information 
> to change 
> >> the PIN for the implicitly specified OTP token.
> >>
> >>
> >> Can we assume that the KDC can ask the OTP server for the info and 
> >> return it as an authorization data element in the returned ticket.
> >>
> >> existing mechanism that was already in place for the token type or 
> >> via a "PIN Change Service" as described in the extract.  Since PIN 
> >> change is similar to password change, I had hoped that 
> this could be 
> >> handled using the existing Kerberos password change system but it 
> >> seems as if that was a mistake.  Overloading an existing 
> protocol is 
> >> probably not a good idea and I had not taken into account the fact 
> >> that a user could have multiple tokens or that multiple 
> back-end OTP 
> >> 3) Since the KDC would not generally be the OTP server itself, the 
> >> KDC itself cannot be assumed to have the information required to 
> >> change the PIN either.
> >>
> >> pre-authentication draft leaves the actual method of PIN 
> change out 
> >> of scope in the same way that I believe RFC4120 does not 
> describe how 
> >> to carry out password change.
> >>        Just saying as above will not suffice as there are issues 
> >> which needs to be addressed for PIN change service are:
> >>
> >>            2) The PIN change service would need a way of telling 
> >> which token of the user is having its PIN change
> >>
> would need 
> >> to be able to determine which OTP-server is handling the

---

From: Larry Zhu <[email-masked]>
Date: Wed, 29 Jul 2009 08:57:07 +0000

Agreed.

---

From: Larry Zhu <[email-masked]>
Date: Wed, 29 Jul 2009 13:50:41 +0000

> mechanism handle credential change in its own way during the

I would like to see how generic this issue is.

First let's look at 3 major categories of authentication factors: passwords, certs/smartcards, and (other) hardware tokens. We have solutions for the first 2, and it appears that for OTP tokens, we do need a solution to change the PIN.

Based on the recent discussions on this topic, it seems that we can solve the multi-token issues by implicitly specifying the token as the one used to authenticate the user to the PIN change service. If we want to have a standardized solution that is not vendor specific (either to the KDC vendors or the OTP token vendors), it does seem straightforward to build such a solution. And do we need a solution now?

The question raised here should not impact the current direction that the PIN change service for the OTP ID should be handled separately.

The working group input would be greatly helpful and needed to make forward progress.

Thanks,
--Larry
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 13, 2009 7:56 AM
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] OTP draft - PIN change service

Srini,

--Gareth

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 29 Jul 2009 14:45:07 -0700

There is an argument that we should leave PIN change out-of-scope to  
be handled by the OTP token vendor and the deploying organization.   
Mapping and OTP service issues might make this the best solution.  Not  
providing any alternative to this option in the OTP ID makes it  
difficult for us to prohibit this option in the future, but I'm OK  
with that.

I would prefer that we handle PIN change with some modification to  
RFC3244.  The argument that the KDC knows what mapping was used to  
authenticate the user/OTP seems convincing to me.  My main concern is  
that the proposed authorization data be added in a way that will not  
adversely interact with other authorization data.

A third choice would be to extend the AS exchange to support it.  This  
may be the most straightforward option from a protocol standpoint, but  
I believe it the least desirable from an implementation standpoint.

On Jul 29, 2009, at 6:50 AM, Larry Zhu wrote:

> First let's look at 3 major categories of authentication factors:  
> passwords, certs/smartcards, and (other) hardware tokens. We have  
> solutions for the first 2, and it appears that for OTP tokens, we do  
> need a solution to change the PIN.
>
> Based on the recent discussions on this topic, it seems that we can  
> solve the multi-token issues by implicitly specifying the token as  
> the one used to authenticate the user to the PIN change service. If  
> we want to have a standardized solution that is not vendor specific  
> (either to the KDC vendors or the OTP token vendors), it does seem  
> straightforward to build such a solution. And do we need a solution  
> now?
>
> The question raised here should not impact the current direction  
> that the PIN change service for the OTP ID should be handled  
> separately.
>