Re: Comments on "Integrating OTP with Kerberos"

[Denis Pinkas <[e-mail]>]

July 25, 1995

Glen,


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:

1. to designate the temporary (i.e. one time) information sent on the wire.
2. to designate the (static) secret information used on the client side to 
   compute the temporary information sent on the wire.

> > >    Note that the use of
> > >    preauthentication here may allow an offline guessing attack against
> > >    the Kerberos password separate from the one-time passcode, 

> > Delete : " separate from the one-time passcode" since the passcode is one
> > time and its value does not need to be confidentiality-protected.

> Why not?  

If it needs to be sent encrypted, we need to say why. I can however think of a 
scheme where the passcode can be sent in the clear. See later.

> > "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" ?

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

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


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

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


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

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]
============================================================================