Subject: [Ietf-krb-wg] OTP - multi-vendor and multi-token support

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 1 Jul 2009 17:45:07 +0530

Gareth,

If the user can use only one token, that information can be sent to user in
PA-OTP-CHALLENGE e.g. info like OTPflags, otp-length, otp-keyID, otp-algID.

But the user may be given multiple tokens from an OTP Server or from
multiple OTP Servers from different vendors. If the user is permitted to use
any/some of the tokens to authenticate, then there is no way the KDC can
send all these information regarding tokens the user can use to authenticate
in PA-OTP-CHALLENGE, as the current PA-OTP-CHALLENGE structure can hold only
one token information.

Maybe we need to extend the PA-OTP-CHALLENGE structure something as follows
to send all the tokens information:

OTP-KEYINFO :: = SEQUENCE {

                flags              OTPFlags,

                otp-challenge  [0]    OCTET STRING (SIZE(8..MAX)) OPTIONAL,

                otp-length           Int32           OPTIONAL,   

                otp-keyID      [1] OCTET STRING    OPTIONAL,

                otp-algID            AnyURI          OPTIONAL

}

OTP-SERVERINFO :: SEQUENCE {

                supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

OPTIONAL,

                iterationCount     Int32           OPTIONAL,

                otp-service        UTF8String      OPTIONAL, (not sure
whether it has to go into this or at PA-OTP-CHALLENGE level).

                keyinfo            SEQUENCE OF OTP-KEYINFO

}

PA-OTP-CHALLENGE ::= SEQUENCE {

                nonce              OCTET STRING,

                etype              SEQUENCE OF Int32,

                serverinfo         SEQUENCE OF OTP-SERVERINFO,

                ...

}

The structure I proposed maynot be 100% correct, but I believe that if we
have something similar then we can support multi-vendors / tokens. This
would be scalable enough to support many tokens/ vendors.

I understand that this would mean that the client program should be
intelligent enough to show all the tokens info which can be used to
authenticate, so that the user can select one from the list and then enter
the tokencode. 

If only token is available, it is left to the KDC vendor to show the token
information to the user before he enters the tokencode.

Thanks,
Srini

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

---

From: <[email-masked]>
Date: Thu, 2 Jul 2009 05:37:47 -0400

Srini,
 
It is not totally clear to me in this proposal, how the client is to
handle the supportedHashAlg and iterationCount elements of the
OTP-SERVERINFO.

In a minimal request, where the KDC is not specifying any details of the
tokens the user may use, the current PA-OTP-CHALLENGE would contain
flags, nonce and the supportedHashAlg and iterationCount required by the
OTP Server.  If there are two OTP Servers then there could be different
values for supportedHashAlg and iterationCount for the different servers
and in the current model it would therefore be the responsibility of the
KDC to return values in the PA-OTP-CHALLENGE that can be handled by
both.

If both servers require hashing then the KDC should return:

a) The intersection of the two sets of hash algorithms.
b) The largest of the iteration counts.

The KDC would then hash the values received from the server with the
lower value to bring it up to the value used by the client.  If there is
no intersection of hash algorithms then the authentication would have to
fail.  If one of the servers does not support hashing then the
plain-text OTP values retrieved from it would be hashed.

In your proposal, is the idea that the client would instead perform this
logic?

Suppose the KDC can support OTP tokens from two OTP Servers and only one
of those servers requires hashing of OTP values.  Based on your
proposal, I would think that the PA-OTP-CHALLENGE would look something
like this.

nonce
etype
serverInfo
	serverInfo1
		supportedHashAlg
		iterationCount
		keyInfo
            	flags = 0
	serverInfo2
		keyInfo
            	flags=0
        
In this type of request, the client cannot know which of the servers the
user's token is from and so cannot know whether or not it needs to hash
the OTP values. I could imagine that if the keyInfo structures contained
sufficient information to allow the client to determine which token the
user is using that this might work but I wouldn't think that that would
be the case most of the time.

It seems to me that the client must carry out the logic described above
and hash all OTPs it receives if one of the server's requires hashing.

Given that, I would think that it might make more sense to move the
supportedHashAlg and iterationCount to the PA-OTP-CHALLENGE level.

--Gareth

________________________________

	From: Srinivas Cheruku [mailto:[email-masked]] 
	Sent: 01 July 2009 13:15
	To: Richards, Gareth
	Cc: [email-masked]
	Subject: OTP - multi-vendor and multi-token support

	Gareth,

	If the user can use only one token, that information can be sent
to user in PA-OTP-CHALLENGE e.g. info like OTPflags, otp-length,
otp-keyID, otp-algID.

	But the user may be given multiple tokens from an OTP Server or
from multiple OTP Servers from different vendors. If the user is
permitted to use any/some of the tokens to authenticate, then there is
no way the KDC can send all these information regarding tokens the user
can use to authenticate in PA-OTP-CHALLENGE, as the current
PA-OTP-CHALLENGE structure can hold only one token information.

	Maybe we need to extend the PA-OTP-CHALLENGE structure something
as follows to send all the tokens information:

	                flags              OTPFlags,

	                otp-challenge  [0]    OCTET STRING
(SIZE(8..MAX)) OPTIONAL,

	}

	                supportedHashAlg   SEQUENCE OF
AlgorithmIdentifier

OPTIONAL,

	                otp-service        UTF8String      OPTIONAL,
(not sure whether it has to go into this or at PA-OTP-CHALLENGE level).

	}

	                nonce              OCTET STRING,

	                etype              SEQUENCE OF Int32,

	                ...

	}

	The structure I proposed maynot be 100% correct, but I believe
that if we have something similar then we can support multi-vendors /
tokens. This would be scalable enough to support many tokens/ vendors.

	I understand that this would mean that the client program should
be intelligent enough to show all the tokens info which can be used to
authenticate, so that the user can select one from the list and then
enter the tokencode. 

	If only token is available, it is left to the KDC vendor to show
the token information to the user before he enters the tokencode.

	Thanks,
	Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 2 Jul 2009 15:26:46 +0530

Gareth,

I was thinking of a structure something like this:

nonce
etype
serverInfo
	serverInfo1
		supportedHashAlg
		iterationCount
		keyInfo
                  keyInfo1
                      keyID = 123456
                      challenge = xyz...
            	    flags = 0x40000000 (combine flag)
                      <otp-len, otp-algID if appropriate>
                  keyInfo2
                      keyID = 456789
            	    flags = 0
	serverInfo2
		keyInfo
                 keyInfo1
                    keyID = 567890
            	  flags=0

The client should be intelligent enough to show all the keyIDs so that the
user can select the appropriate token and use. Based on the selected keyID,
the client should use the appropriate hashalg, iteractioncount, challenge
etc.

I am not sure how feasible it is when using different tokens and different
OTP Servers.

Hope you can see why I have hashalg, iterationcount in serverinfo now.

Thanks,
Srini

---

From: <[email-masked]>
Date: Thu, 2 Jul 2009 06:46:59 -0400

Srini,

My point was that having the supportedHahsAlg and iterationCount in the
OTP-SERVERINFO works if the KDC sends enough information to allow the
client to identify the token used but not if fields such as otp-keyID
are not present.

The example you give below is really for the case where the KDC is
saying that the user may use a specific token from OTP server1 and
another specific token from server2.  I agree that in that case the
client can be intelligent enough to prompt the user.

The example I gave was where the KDC is using two OTP Servers and so can
accept tokens from either server but the OTP Servers but does not
include any information on what tokens the user is to use.  This maybe
for security reasons since it can usually be assumed that the user knows
which token they are supposed to use.  In this situation, the client
cannot know which token is used.

My concern is that if the supportedHashAlg and iterationCount are used
in this way that the client is either forced to work out the overlap of
hash algorithms or the KDC is required to include information
identifying the tokens the user may use.  In the latter case, the client
is then forced to prompt the user to select a token.

--Gareth 

> -----Original Message-----
> Sent: 02 July 2009 10:57
> Subject: RE: OTP - multi-vendor and multi-token support
> 
> Gareth,
> 
> The client should be intelligent enough to show all the 
> keyIDs so that the user can select the appropriate token and 
> use. Based on the selected keyID, the client should use the 
> appropriate hashalg, iteractioncount, challenge etc.
> 
> I am not sure how feasible it is when using different tokens 
> and different OTP Servers.
>

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 2 Jul 2009 17:22:40 +0530

Gareth,

See below:

Thanks,
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 July 2009 16:17
To: [email-masked]
Cc: [email-masked]
Subject: RE: OTP - multi-vendor and multi-token support

Srini,

[Srinivas Cheruku] I believe that KDC would be sending all the information
got from OTP Server. If OTP Server cannot send keyID for some reason then I
can see some issues. I think in this case as you suggested the intersection
of hash algorithm and max iterationcount to be used by the client. Even if
the client is intelligent enough to show all the keyinfo, it maynot be able
to distinguish between different tokens as keyID is not present.

[Srinivas Cheruku] yes.

[Srinivas Cheruku] correct. If enough information is not given then client
cannot know which token is used

[Srinivas Cheruku] Can we mandate using keyID? If we can make it a mandatory
param, then the client can show the different tokens the user can use to
authenticate.

--Gareth

---

From: <[email-masked]>
Date: Thu, 2 Jul 2009 08:09:29 -0400

See below.

> 
> My point was that having the supportedHahsAlg and 
> iterationCount in the OTP-SERVERINFO works if the KDC sends 
> enough information to allow the client to identify the token 
> used but not if fields such as otp-keyID are not present.
> 
> [Srinivas Cheruku] I believe that KDC would be sending all 
> the information got from OTP Server. If OTP Server cannot 
> send keyID for some reason then I can see some issues. I 
> think in this case as you suggested the intersection of hash 
> algorithm and max iterationcount to be used by the client. 
> Even if the client is intelligent enough to show all the 
> keyinfo, it maynot be able to distinguish between different 
> tokens as keyID is not present.

I am still not sure that the fact that there are multiple OTP servers
with different hashing requirements really needs to be exposed to the
client.  If the PA-OTP-CHALLENGE is viewed as the KDC telling the client
what it needs then the fact that there are really multiple OTP servers
behind it is not really significant.  The KDC might be an OTP server
itself or it might sit in front of multiple servers as a proxy.  Either
way, it could work out its hashing requirements and send them to the
client in the PA-OTP-CHALLENGE.  Why not let it do the work up front
instead of requiring each client to repeat it?

> 
> The example you give below is really for the case where the 
> KDC is saying that the user may use a specific token from OTP 
> server1 and another specific token from server2.  I agree 
> that in that case the client can be intelligent enough to 
> prompt the user.
> 
> [Srinivas Cheruku] yes.
> 
> The example I gave was where the KDC is using two OTP Servers 
> and so can accept tokens from either server but the OTP 
> Servers but does not include any information on what tokens 
> the user is to use.  This maybe for security reasons since it 
> can usually be assumed that the user knows which token they 
> are supposed to use.  In this situation, the client cannot 
> know which token is used.
> 
> [Srinivas Cheruku] correct. If enough information is not 
> given then client cannot know which token is used
> 
> My concern is that if the supportedHashAlg and iterationCount 
> are used in this way that the client is either forced to work 
> out the overlap of hash algorithms or the KDC is required to 
> include information identifying the tokens the user may use.  
> In the latter case, the client is then forced to prompt the 
> user to select a token.
> 
> [Srinivas Cheruku] Can we mandate using keyID? If we can make 
> it a mandatory param, then the client can show the different 
> tokens the user can use to authenticate.
> 

No, I don't think we can mandate that it be used.  I can imagine lots of
cases where an OTP Server will not want to divulge this information
since it leaks information about the user by allowing an attacker to
find out what tokens a user has.

The field was added mainly to support connected tokens where there may
be many OTP seed records on one device and giving the client the value
would help it locate the one to use.  I hadn't really thought about it
being used for disconnected tokens since the value would have to be
interpreted by the user.

> keyIDs so that 
> > the user can select the appropriate token and use. Based on the 
> > selected keyID, the client should use the appropriate hashalg, 
> > iteractioncount, challenge etc.
> > 
> > I am not sure how feasible it is when using different tokens and 
> > different OTP Servers.
> >

---

From: <[email-masked]>
Date: Thu, 2 Jul 2009 08:58:04 -0400

Srini,

How about something along these lines?

PA-OTP-CHALLENGE ::= SEQUENCE {
  nonce            [0] OCTET STRING,
  etype            [1] SEQUENCE OF Int32,
  supportedHashAlg [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL,
  iterationCount   [3] Int32                           OPTIONAL,
  otp-service      [4] UTF8String                      OPTIONAL,
  keyInfo          [5] SEQUENCE OF OTP-KEYINFO         OPTIONAL,
  ...
} 

OTP-KEYINFO :: = SEQUENCE {
   flags          [0] OTPFlags, 
   otp-vendor     [1] UTF8String                  OPTIONAL,   
   otp-challenge  [2] OCTET STRING (SIZE(8..MAX)) OPTIONAL,
   otp-length     [3] Int32                       OPTIONAL,
   otp-keyID      [4] OCTET STRING                OPTIONAL,
   otp-algID      [5] AnyURI                      OPTIONAL
  ...
}

I added the otp-vendor to the OTP-KEYINFO as you requested to optionally
carry the name of the token vendor.  I also made the keyInfo in the
PA-OTP-CHALLENGE optional; if it is not present then the client can
treat the flags field as being zero.

If we do something along these lines then it might also be possible to
use the same OTP-KEYINFO in the PA-OTP-REQUEST to carry information on
the token used by the client.

--Gareth

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 02 July 2009 13:09
> Subject: Re: [Ietf-krb-wg] OTP - multi-vendor and multi-token support
> 
> See below.
> 
> > 
> > My point was that having the supportedHahsAlg and iterationCount in 
> > the OTP-SERVERINFO works if the KDC sends enough 
> information to allow 
> > the client to identify the token used but not if fields such as 
> > otp-keyID are not present.
> > 
> > [Srinivas Cheruku] I believe that KDC would be sending all the 
> > information got from OTP Server. If OTP Server cannot send 
> keyID for 
> > some reason then I can see some issues. I think in this case as you 
> > suggested the intersection of hash algorithm and max 
> iterationcount to 
> > be used by the client.
> keyinfo, it 
> > maynot be able to distinguish between different tokens as 
> keyID is not 
> > present.
> 
> I am still not sure that the fact that there are multiple OTP 
> servers with different hashing requirements really needs to 
> be exposed to the client.  If the PA-OTP-CHALLENGE is viewed 
> as the KDC telling the client what it needs then the fact 
> that there are really multiple OTP servers behind it is not 
> really significant.  The KDC might be an OTP server itself or 
> it might sit in front of multiple servers as a proxy.  Either 
> way, it could work out its hashing requirements and send them 
> to the client in the PA-OTP-CHALLENGE.  Why not let it do the 
> work up front instead of requiring each client to repeat it?
> 
> > 
> > saying that the user may use a specific token from OTP
> that in that 
> > case the client can be intelligent enough to prompt the user.
> > 
> > [Srinivas Cheruku] yes.
> > 
> > The example I gave was where the KDC is using two OTP 
> Servers and so 
> > can accept tokens from either server but the OTP Servers 
> but does not 
> > for security reasons since it can usually be assumed that the user 
> > knows which token they are supposed to use.  In this situation, the 
> > client cannot know which token is used.
> > 
> > [Srinivas Cheruku] correct. If enough information is not given then 
> > client cannot know which token is used
> > 
> > in this way that the client is either forced to work out 
> the overlap 
> > of hash algorithms or the KDC is required to include information 
> > identifying the tokens the user may use.
> > In the latter case, the client is then forced to prompt the user to 
> > select a token.
> > 
> > [Srinivas Cheruku] Can we mandate using keyID? If we can make it a 
> > mandatory param, then the client can show the different tokens the 
> > user can use to authenticate.
> > 
> 
> No, I don't think we can mandate that it be used.  I can 
> imagine lots of cases where an OTP Server will not want to 
> divulge this information since it leaks information about the 
> user by allowing an attacker to find out what tokens a user has.
> 
> The field was added mainly to support connected tokens where 
> there may be many OTP seed records on one device and giving 
> the client the value would help it locate the one to use.  I 
> hadn't really thought about it being used for disconnected 
> tokens since the value would have to be interpreted by the user.
> 
> >

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 2 Jul 2009 18:57:33 +0530

>  carry the name of the token vendor.  

[Srinivas Cheruku] Thank you.

>  I also made the keyInfo in the

[Srinivas Cheruku] I think keyInfo shouldn't be optional. There should be
atleast one keyInfo element and this would mean that flags can be part of
keyInfo and no need of any assumption. This would also mean that KDC can
send any other information like otp-vendor or otp-challenge apart from keyID
if it wishes to do so. Or when the user is given multiple tokens, it can
send an array of keyInfo when keyIDs are known along with other information.

>  the token used by the client.

[Srinivas Cheruku] If we want to use a common structure for keyInfo which
can be used with OTP-CHALLENGE and OTP-REQUEST, then I believe it should
also contain otp-value, otp-time, otp-counter, otp-format which are
optional. But using structure thing like this would mean that some values
are not used in OTP-CHALLENGE and some not used in OTP-REQUEST. So am not
sure whether using common structure is a good idea.

---

From: <[email-masked]>
Date: Thu, 2 Jul 2009 09:33:54 -0400

> >  I added the otp-vendor to the OTP-KEYINFO as you requested to  
> > optionally  carry the name of the token vendor.
> 
> [Srinivas Cheruku] I think keyInfo shouldn't be optional. 
> There should be atleast one keyInfo element and this would 
> mean that flags can be part of keyInfo and no need of any 
> assumption. This would also mean that KDC can send any other 
> information like otp-vendor or otp-challenge apart from keyID 
> if it wishes to do so. Or when the user is given multiple 
> tokens, it can send an array of keyInfo when keyIDs are known 
> along with other information.
> 
My reasoning was that the KDC should only need to include a keyInfo if
it needs to specify anthing about the token to use.  If it doesn't need
to specify it then it need not include the element.  In this way, the
KDC would include a keyInfo for each specified token type.  If the
request is just "authenticate with a token" but the KDC does not specify
anything about that token then I wouldn't think that the keyInfo is
required.   I don't see how making it optional affects otp-vendor etc.
If the KDC needs to specify those then it needs to include the element.

> >  
> >  If we do something along these lines then it might also be 
> possible 
> > to  use the same OTP-KEYINFO in the PA-OTP-REQUEST to carry 
> > information on  the token used by the client.
> 
> [Srinivas Cheruku] If we want to use a common structure for 
> keyInfo which can be used with OTP-CHALLENGE and OTP-REQUEST, 
> then I believe it should also contain otp-value, otp-time, 
> otp-counter, otp-format which are optional. But using 
> structure thing like this would mean that some values are not 
> used in OTP-CHALLENGE and some not used in OTP-REQUEST. So am 
> not sure whether using common structure is a good idea.
> 
I agree and I'm not sure about it either.

> >  > From: [email-masked]  > 
> > [mailto:[email-masked]] On Behalf Of  > 
> > [email-masked]  > Sent: 02 July 2009 13:09  > To: 
> > [email-masked]  > Cc: [email-masked]  > 
> Subject: Re: 
> > [Ietf-krb-wg] OTP - multi-vendor and multi-token  support  >  > See 
> > below.
> >  >
> >  > >
> > in  > > the OTP-SERVERINFO works if the KDC sends enough  > 
> > information to allow  > > the client to identify the token used but 
> > not if fields such as  > > otp-keyID are not present.
> >  > >
> >  > > [Srinivas Cheruku] I believe that KDC would be sending 
> all the  > 
> > > information got from OTP Server. If OTP Server cannot 
> send  > keyID 
> > for  > > some reason then I can see some issues. I think in 
> this case 
> > as  you  > > suggested the intersection of hash algorithm 
> and max  > 
> > iterationcount to  > > be used by the client.
> >  > > Even if the client is intelligent enough to show all the  > 
> > keyinfo, it  > > maynot be able to distinguish between different 
> > tokens as  > keyID is not  > > present.
> >  >
> >  > I am still not sure that the fact that there are multiple OTP  > 
> > servers with different hashing requirements really needs to  > be 
> > exposed to the client.  If the PA-OTP-CHALLENGE is viewed  > as the 
> > KDC telling the client what it needs then the fact  > that 
> there are 
> > really multiple OTP servers behind it is not  > really 
> significant.  
> > The KDC might be an OTP server itself or  > it might sit in 
> front of 
> > multiple servers as a proxy.  Either  > way, it could work out its 
> > hashing requirements and send them  > to the client in the 
> > PA-OTP-CHALLENGE.  Why not let it do the  > work up front 
> instead of 
> >  > > The example you give below is really for the case 
> where the KDC 
> > is  > > saying that the user may use a specific token from OTP  > > 
> > that in 
> > that  > > case the client can be intelligent enough to prompt the 
> > user.
> >  > >
> >  > > [Srinivas Cheruku] yes.
> >  > >
> > Servers 
> > and so  > > can accept tokens from either server but the 
> OTP Servers  
> > > but does not  > > include any information on what tokens 
> the user is 
> > to use.
> >  > This maybe
> >  > > for security reasons since it can usually be assumed that the 
> > user  > > knows which token they are supposed to use.  In this 
> > situation,  the  > > client cannot know which token is used.
> >  > >
> >  > > [Srinivas Cheruku] correct. If enough information is 
> not given  
> > then  > > client cannot know which token is used  > >  > > 
> My concern 
> > is that if the supportedHashAlg and  > iterationCount are 
> used  > > in 
> > this way that the client is either forced to work out  > 
> the overlap  
> >  > > In the latter case, the client is then forced to 
> prompt the user  
> > to  > > select a token.
> >  > >
> >  > > [Srinivas Cheruku] Can we mandate using keyID? If we 
> can make it 
> > a  > > mandatory param, then the client can show the 
> different tokens 
> > the  > > user can use to authenticate.
> >  > >
> >  >
>  > imagine 
> > lots of cases where an OTP Server will not want to  > divulge this 
> > information since it leaks information about the  > user by 
> allowing 
> > an attacker to find out what tokens a user has.
> >  >
> >  > The field was added mainly to support connected tokens where  > 
> > there may be many OTP seed records on one device and giving  > the 
> > client the value would help it locate the one to use.  I  > hadn't 
> > really thought about it being used for disconnected  > tokens since 
> > the value would have to be interpreted by the user.
> >  >
> >  > >
> >  > > > Subject: RE: OTP - multi-vendor and multi-token 
> support  > > >  
> > > > > Gareth,  > > >  > > > I was thinking of a structure something 
> > like this:
> >  > > >
> >  > > > nonce
> >  > > > etype
> >  > > > serverInfo
> >  > > > 	serverInfo1
> >  > > > 		supportedHashAlg
> >  > > > 		iterationCount
> >  > > > 		keyInfo
> >  > > >                   keyInfo1
> >  > > >                       keyID = 123456
> >  > > >                       challenge = xyz...
> >  > > > The client should be intelligent enough to show all the  > > 
> > keyIDs so that  > > > the user can select the appropriate token and 
> > use. Based on the  > > > selected keyID, the client should use the 
> > appropriate hashalg,  > > > iteractioncount, challenge etc.
> >  > > >
> > and  > > > different OTP Servers.
> >  > > >
> >  > > > Hope you can see why I have hashalg, iterationcount in  > > 
> > serverinfo now.
> >  > > >
> >  > > > Thanks,
> >  > > > Srini
> >  > > >
> >  > > >
> >  > > >
> >  > >
> >  > >
> >  > >

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 3 Jul 2009 10:48:01 +0530

>  If the KDC needs to specify those then it needs to include the

[Srinivas Cheruku] I was just thinking on the assumptions you stated e.g.
flags being zero. But now your reasoning seems to convince me and I believe
that there is no need of any assumption of flags when keyInfo is not
available and the user can use any token of his choice when he is given many
tokens.