Re: Comments on "Integrating OTP with Kerberos"

[Glen Zorn <[e-mail]>]

On Mon, 24 Jul 1995, Denis Pinkas wrote:

> 
> July 24, 1995
> 
> 
> From: Denis Pinkas
> 
> 
> Comments on draft-ietf-cat-kerberos-passwords-01.txt:
> 
>          Integrating One-time Passwords with Kerberos
> 
> 
> During the last IETF meeting in Stockholm, I had a talk with Cliff Neuman 
> and I explained to him some of the concerns I had with the current spec. 
> I promissed him to send a list of comments on this I-D to the CAT list, so 
> here it is.
> 
> Following are detailed comments. If you do not have time to read them, you 
> can go directly to the end of this E-mail and read the conclusion section 
> (it is about 20 lines).
> 
> 
> DETAILED COMMENTS
> =================
> 
> At the end of the section 1 (Abstract) we should add:
> 
> "Many of the methods described hereafter require the use, in addition to 
> the one-time-password, of the Kerberos password."
> 
> 
> >    For  the  sake
> >    of  brevity,  "one-time  password"  will  often  be  abbreviated to
> >    "passcode" in the remainder of this document.
> 
> We should also use, when appropriate the wording "pass-phrase" which is 
> being used in draft-haller-otp-00.txt. So the following adding is 
> proposed:
> 
> . 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".

> 
> > 3.1 Challenge/Response Model
> > 
> >    Depending  on
> >    whether  preauthentication  is  used,  the  user  may or may not be
> >    prompted at this time for a password.  If (for  example)  encrypted
> >    timestamp   preauthentication  is  used,  then  the  user  will  be
> >    prompted; on the other hand, if no preauthentication is in use  the
> >    prompt  for  the  password  may  be deferred. 
> 
> This is not correct. As it is explained later on, SKEY_K0 does not require 
> an additional password. So all challenge/response models do not need it. 

True.

> Change into:
> 
> When preauthentication is used, the user may be prompted at this time
> for a password. If (for example) encrypted timestamp preauthentication
> is used, then the user will be prompted.
> 
> 
> >    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?  

> >    but if a passcode is required, then the password by 
itself is not > >    sufficient for authentication.
> 
> Interrestig point that we should clarify. I suggest:
> 
> " ...but if a passcode is required for a given user, then the Kerberos 
> password should not be allowed to be used alone. This later restriction is 
> required when using an untrusted terminal which could steal the Kerberos 
> password."
> 
> 
> >    PA_OTPC_TYPE_SKEY is
> >    the traditional S/Key protocol, in which the KDC will not know  the
> >    passcode.  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  secret) is actually stored on, and can be
> >    used by, the KDC to generate the correct passcode.
> 
> We should replace the sentences by: 
> 
> "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.

...

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

  > 
> >    KDC (in which case it can be used as part of the encryption key for
> >    the response), or if it must be provided to the KDC in  a  recover-
>                           ^^
>                        the passcode ?

Yes.

> 
> >    able  manner. 
> 
> What means "must be provided to the KDC in a recoverable manner" ?

Encrypted in a fashion that allows decryption (as opposed to the one-way 
encryption used by crypt(3).

> 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. If we send the 
passcode in the clear, we hand an eavesdropper part of that key.  Note 
that, in the case of either of the S/Key derivatives, there would be no 
need to send the encrypted passcode.

> >    If it is known to the KDC, 
use-passcode-as-key indi-
> >    cates that the passcode alone will be used to generate the  encryp-
>                     ^^^^^^^^
> 
> I think we should say "pass-phrase" here.

See above.

> 
> >    tion  key  for  the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
> >    and that the user will not need  to  also  enter  a  password.
> 
> To make it even clearer, we should say : 
> "... to also enter a Kerberos password".
> 
> >    We
> >    recommend  that  this  option  not  be used, 
> 
> This is the single case, where the Kerberos password is not needed. So 
> this is nice from the user point of view. Should it be so deprecated ? See 
> later comment.
> 
> >    and that the user also
> >    enter  a  password,  
> 
> So, the recommendation is to always use a Kerberos password in addition to 
> the passcode. This means that the security now relies on the use of *two* 
> information. This is why I suggested to add a sentence up-front in section 
> 1.

That is correct.  Suppose that you were to have a generated list of S?key 
passcodes.  If you were to misplace that list, or expose it to the wrong 
people at the wrong moment, an attacker could masquerade as you.  
Requiring both the Kerberos password and an OTP nullifies this problem.
Additionally, some OTP schemes use passcodes that would be inappropriate 
for use as keys by themselves.

...

> 
> 
> >           If the use-passcode-as-key flag is set and the integrity  of
> >           the  PA-OT-PASSCODE-CHALLENGE  PADATA  field can be verified
> >           using the otpc-cksum field, then the passcode is run through
> >           the  string_to_key  function  and  the result is used as the
> >           encryption key for the  request.   WARNING:  the  use  of  a
> >           passcode  in this manner is NOT recommended unless the range
> >           of the passcode is large enough to make an  exhaustive  off-
> >           line search impractical and the risks involved in the use of
> >           a passcode alone are  fully  considered. 
> 
> Current OTP systems are already exposed to that risk, and for that reason 
> the pass-phrase must contain at least 10 characters. So the risk is not 
> higher.
> 

Again, this comment seems only to apply to S/Key-based systems; the 
SecurID passcode is 6 digits, for instance.

...

> 
> CONCLUSION
> ==========
> 
> Trying to address all current and future methods in a single spec. is not 
> that easy. 
> 
> 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?
 
> 
> 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 protcol.
 
> 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.  The results of the 
OTP WG work will certainly have an effect upon the implementors of our draft, 
but that seems to me to be about it.
 
> > Denis Pinkas. > > -- > 
> ============================================================================
>       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.