Kerberos WG (krb-wg)

headers Srinivas Cheruku | 1 Jul 2009 14:15

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
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: ietf-krb-wg-bounces <at> lists.anl.gov 
> [mailto:ietf-krb-wg-bounces <at> lists.anl.gov] On Behalf Of 
> gareth.richards <at> rsa.com
> Sent: 30 June 2009 18:09
> To: srinivas.cheruku <at> gmail.com; ietf-krb-wg <at> anl.gov
> 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:srinivas.cheruku <at> gmail.com] 
> 	Sent: 22 June 2009 12:00
> 	To: Richards, Gareth; ietf-krb-wg <at> anl.gov
> 	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
> ietf-krb-wg <at> lists.anl.gov
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

>>>>> "Ken" == Ken Raeburn <raeburn <at> MIT.EDU> writes:
8
    Ken> On Jun 27, 2009, at 00:29, Tom Yu wrote:
    >> Should this document state that it updates RFC 3961 and RFC
    >> 3962?  Or are we going to separately publish errata for those?

    Ken> For correcting errors, I think errata make more sense.

I agree.  I'd rather lose the DES test vectors from this document than
update 3961 in an appendix.

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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:srinivas.cheruku <at> gmail.com] 
	Sent: 01 July 2009 13:15
	To: Richards, Gareth
	Cc: ietf-krb-wg <at> anl.gov
	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:

	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
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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-----
> From: Srinivas Cheruku [mailto:srinivas.cheruku <at> gmail.com] 
> Sent: 02 July 2009 10:57
> To: Richards, Gareth
> Cc: ietf-krb-wg <at> anl.gov
> 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...
>             	    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
> 
> 
> 
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Gareth,

See below:

Thanks,
Srini

-----Original Message-----
From: gareth.richards <at> rsa.com [mailto:gareth.richards <at> rsa.com] 
Sent: 02 July 2009 16:17
To: srinivas.cheruku <at> gmail.com
Cc: ietf-krb-wg <at> anl.gov
Subject: RE: OTP - multi-vendor and multi-token support

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.

[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.

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.

--Gareth 

> -----Original Message-----
> From: Srinivas Cheruku [mailto:srinivas.cheruku <at> gmail.com] 
> Sent: 02 July 2009 10:57
> To: Richards, Gareth
> Cc: ietf-krb-wg <at> anl.gov
> 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...
>             	    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
> 
> 
> 

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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.

> 
> > -----Original Message-----
> > From: Srinivas Cheruku [mailto:srinivas.cheruku <at> gmail.com]
> > Sent: 02 July 2009 10:57
> > To: Richards, Gareth
> > Cc: ietf-krb-wg <at> anl.gov
> > 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...
> >             	    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
> > 
> > 
> > 
> 
> 
> 
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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

> -----Original Message-----
> From: ietf-krb-wg-bounces <at> lists.anl.gov 
> [mailto:ietf-krb-wg-bounces <at> lists.anl.gov] On Behalf Of 
> gareth.richards <at> rsa.com
> Sent: 02 July 2009 13:09
> To: srinivas.cheruku <at> gmail.com
> Cc: ietf-krb-wg <at> anl.gov
> 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.
> > 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.
> 
> > 
> > > -----Original Message-----
> > > From: Srinivas Cheruku [mailto:srinivas.cheruku <at> gmail.com]
> > > Sent: 02 July 2009 10:57
> > > To: Richards, Gareth
> > > Cc: ietf-krb-wg <at> anl.gov
> > > 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...
> > >             	    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
> > > 
> > > 
> > > 
> > 
> > 
> > 
> _______________________________________________
> ietf-krb-wg mailing list
> ietf-krb-wg <at> lists.anl.gov
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

>  
>  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.  

[Srinivas Cheruku] Thank you.

>  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.

[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.

>  
>  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.

>  
>  --Gareth
>  
>  
>  > -----Original Message-----
>  > From: ietf-krb-wg-bounces <at> lists.anl.gov
>  > [mailto:ietf-krb-wg-bounces <at> lists.anl.gov] On Behalf Of
>  > gareth.richards <at> rsa.com
>  > Sent: 02 July 2009 13:09
>  > To: srinivas.cheruku <at> gmail.com
>  > Cc: ietf-krb-wg <at> anl.gov
>  > 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.
>  > > 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.
>  >
>  > >
>  > > > -----Original Message-----
>  > > > From: Srinivas Cheruku [mailto:srinivas.cheruku <at> gmail.com]
>  > > > Sent: 02 July 2009 10:57
>  > > > To: Richards, Gareth
>  > > > Cc: ietf-krb-wg <at> anl.gov
>  > > > 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...
>  > > >             	    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
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > _______________________________________________
>  > ietf-krb-wg mailing list
>  > ietf-krb-wg <at> lists.anl.gov
>  > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
>  >
>  >

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

2	March 2013
1	February 2013
2	January 2013
1	December 2012
9	November 2012
13	October 2012
23	September 2012
21	August 2012
17	July 2012
94	June 2012
8	May 2012
28	April 2012
70	March 2012
149	February 2012
17	January 2012
23	December 2011
69	November 2011
56	October 2011
38	September 2011
84	August 2011
183	July 2011
93	June 2011
165	May 2011
49	April 2011
55	March 2011
32	February 2011
56	January 2011
49	December 2010
43	November 2010
170	October 2010
46	September 2010
83	August 2010
35	July 2010
12	June 2010
99	May 2010
13	April 2010
52	March 2010
16	February 2010
5	January 2010
21	December 2009
36	November 2009
122	October 2009
81	September 2009
44	August 2009
97	July 2009
102	June 2009
56	May 2009
64	April 2009
223	March 2009
24	February 2009
45	January 2009
60	December 2008
63	November 2008
18	October 2008
54	September 2008
140	August 2008
87	July 2008
4	June 2008
2	May 2008
21	April 2008
17	March 2008
32	February 2008
50	January 2008
62	December 2007
54	November 2007
41	October 2007
6	September 2007
52	August 2007
57	July 2007
37	June 2007
42	May 2007
35	April 2007
66	March 2007
13	February 2007
10	January 2007
6	December 2006
19	November 2006
24	October 2006
73	September 2006
46	August 2006
29	July 2006
47	June 2006
26	May 2006
36	April 2006
40	March 2006
42	February 2006
78	January 2006
28	December 2005
109	November 2005
90	October 2005
138	September 2005
84	August 2005
162	July 2005
59	June 2005
58	May 2005
42	April 2005
60	March 2005
175	February 2005
78	January 2005
42	December 2004
57	November 2004
114	October 2004
217	September 2004
52	August 2004
229	July 2004
70	June 2004
76	May 2004
111	April 2004
105	March 2004
95	February 2004
27	January 2004
114	December 2003
69	November 2003
254	October 2003
192	September 2003
113	August 2003
118	July 2003
62	June 2003
59	May 2003
91	April 2003
80	March 2003
47	February 2003
33	January 2003
187	December 2002
170	November 2002
101	October 2002
25	September 2002
21	August 2002
15	July 2002
29	June 2002
13	May 2002
49	April 2002

OTP - multi-vendor and multi-token support

Re: OTP draft - PIN change service

Re: WG Last Call: draft-ietf-krb-wg-preauth-framework-12

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Re: OTP - multi-vendor and multi-token support

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31