Re: Comments on "Integrating OTP with Kerberos"

[Glen Zorn <[e-mail]>]

On Tue, 25 Jul 1995, Denis Pinkas wrote:

> 
> Here is my reply to your comments:
> 
> 
> > > . and "pass-phrase" will be used, when appropriate, to designate the 
> > > information used by the user to generate the passcode.
> 
> > This seems overly mechanism-specific to me: out of the dozen or so OTP
> > schemes of which I'm aware, S/Key is the only one that uses the term
> > "pass-phrase".
> 
> We need different terms:

Agreed.

> 
> 1. to designate the temporary (i.e. one time) information sent on the wire.

How about "preauthentication data"?  The passcode itself should only go 
on the wire in rare cases (S/Key not being one of them).

> 2. to designate the (static) secret information used on the client side to 
>    compute the temporary information sent on the wire.

How about "passcode", and specify that the term is used semantically, 
rather than syntactically; i.e., a passcode may be a "word" (a non-blank 
string of characters), a "phrase" (several whitespace separated words), 
etc., but in any case the passcode is used directly in the generation of 
preathentication data.  For example, the S/Key pass-phrase is _not_ a 
passcode, but the result of hashing it n times _is _ a passcode. 

> 
> > > "PA_OTPC_TYPE_SKEY is the traditional S/Key protocol, in which the KDC 
> > > will not know the pass-phrase. PA_OTPC_TYPE_SKEY_K0 is a variant of S/Key
> > > that uses the same passcodes and PC software or hardware device, but where
> > > the zeroth key (the S/Key pass-phrase) is actually stored on, and can be 
> > > used by, the KDC to generate the correct passcode"
> 
> > This seems to me to place unnecessary restrictions on implementors: I 
> > don't think that there is any requirement that the actual plaintext 
> > pass-phrase be stored on the KDC -- the first digest could be stored just
> > as easily, requiring less space and providing the same functionality.  In
> > fact, that is what I had in mind when I invented SKEY_K0.
> 
> You are right. However, we would need a name to designate that information. 
> Should it be "passcode 0" ?

OK

> 
> > > >    The otpc-flags field indicates whether the passcode is known by the
> > >                                                 ^^^^^^^^
> 
> > > I think we should say "pass-phrase" here.
> 
> > But it it not necessarily a pass-phrase (or even a derivation thereof).  
> > It might be a DES key (Digital Pathways), a 6-digit string (SecurID) 
> > or something else.
> 
> There is some confusion here by what is meant by : 
> "the passcode is known by the KDC". 
> 
> Do we say that:
> 
> - that a static quantity is known on both sides or 
> - that the same transient value can be computed on both sides ? 
> 
> The former case relates to the passphrase (or a derivative of it) 
> while the later to the passcode.

How about saying "the passcode itself is known or can be generated by the 
KDC"?  This is _not_ the case with either SecurID or traditional S/Key, 
but is true with other methods.

 > 
> Anyway we need to say exactly what is behind these concepts and find some 
> unambiguous names for them. Everything cannot be called a passcode.
> 
> 
> > > Why do we suggest to encrypt the passcode ? For what reason ? 
> > > More explanations are needed.
> 
> > The passcode is going to be used by the KDC to generate the key under 
> > which part of the AS_REP message will be encrypted. 
> 
> Is it the single way of doing it ? I would also be possible to send the 
> password in the clear

Do you really _mean_ password here?

> and then to compute the key under which part of the 
> AS_REP message will be encrypted (if the passcode is correct) by using the 
> following formula:
> 
> encryption key = hash (password, passcode).
> 
> In this way the client does not need to encrypt anything, it just needs to 
> decrypt as usual.
> 

I don't understand.

> 
> > > Currently OTP methods can be used from either trusted terminals (e.g. your
> > > own portable) or from untrusted terminals (e.g. a terminal that could be 
> > > used at the last Stockholm meeting). For the later case, security-aware 
> > > people carry their pre-printed list of passcodes. From the different 
> > > techniques which are exposed there seems to be no equivalence (yet) for 
> > > such a case.
> 
> > > This would mean that the current techniques being exposed are only valid 
> > > to be used from *trusted* terminals. If so, this should clearly be stated.
> 
> > > Nevertheless, one or more methods valid to be used from untrusted 
> > > terminals, if possible, should also be supported by this specification.
> 
> > I don't understand this comment: is there something in the I-D that
> > precludes the use of pre-printed lists?
> 
> The problem is when you enter the Kerberos password on an untrusted terminal.
> This untrusted terminal is able to steal it. This means that the Kerberos 
> password alone should not be usable anymore alone for that user. That user 
> should be forced to always use the password + passcode combination ... which 
> is rather painful for a day to day use.
> 
> What is required is to be able to use only pre-printed (one-time) information
> when away from home on untrusted terminals and still be able to use the 
> Kerberos password as usual on trusted terminals.

I thought that we had mentioned that.  It would certainly be possible to 
change the type of OTP required based upon the source IP address (subject 
to spoofing, of course) and if the type was SKEY_K0, the 
use_passcode_as_key flag could be set.

> 
> > > Beforehand, we need to say what kind of threats we want to address. In 
> > > particular, do we want to cover active attacks (which are *not* covered by
> > > draft-haller-otp-00.txt) ? and, if yes, what kind of combination of 
> > > communication line eavesdropping, spying from the untrusted terminal and 
> > > active communication line interception attack and/or active communication 
> > > line initialisation attack ?
> 
> > It seems that any approach we take should be at least as secure as and 
> > handle the same types of attacks as the Kerberos protocol.
> 
> Which Kerberos protocol ? The one without or with pre-authentication ?
> 
> - the one without pre-authentication allows for password guessing attacks 
>   from any terminal,
> 
> - the one with pre-authentication allows for password guessing attacks only 
>   when monitoring comunication lines.
> 

Actually, password guessing attacks are possible against both, without 
sniffing the network -- it's just more convenient and safer without 
preauthentication.

 > 
> > > I would also propose to the chair of the CAT group (John Linn) that we 
> > > advertise the current specification to the otp working group, i.e. 
> > > [e-mail] and that we copy it in the future with the comments
> > > related to this I-D.
> 
> > Both Cliff and I attended the S/Key BOF in Danvers, and there was 
> > discussion of what (if any) relationships existed between our draft and 
> > that working group.  I, at least, came away with the impression that the 
> > consensus was that there was essentially no relation at all. The method 
> > being standardized by the OTP Working Group is just one of many methods 
> > in use, and one of many that our protocol will support. 
> 
> I was there too. There is indeed some relationship. For the case of "OTP" 
> we need to say explicitly how it can be used in conjunction with Kerberos. 
> Since other methods are not (yet ?) candidate for Internet standardization, 
> such a need does not exist for them.

Mightn't this be a candidate for YAID?

> 
> Denis.
> 
> ============================================================================
>       Denis Pinkas                           E-mail : [e-mail]
>       Bull S.A.                                                             
>       Rue Jean Jaures  B.P. 68                Phone : [phone]
>       78340 Les Clayes sous Bois. FRANCE       Fax  : [phone]
> ============================================================================
> 
> 


~ gwz


Glen Zorn       	Senior Scientist	Voice: 206-883-8721
[e-mail]	CyberSAFE Corporation	FAX:   [phone]

Since I was forced to write it by the alien parasite which attached itself to 
my brain stem during my recent visit to an isolated area of Northern Arizona, 
it could hardly be construed that this message would reflect either the
opinions or the policies of my employer.