Comments on "Integrating OTP with Kerberos"

[Denis Pinkas <[e-mail]>]

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.


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

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

>    Note that using PA_OTPC_TYPE_SKEY_K0  gives  up  one  advantage  of
>    S/Key, viz., that the information required to generate the key need
                                                                ^^^

Which key ? At that time of reading the sentence is unclear.

>    not be stored on the host; but since the KDC is assumed to be  more
>    secure  than  other  hosts  on the network, it may be acceptable to
>    give up this advantage in some situations.


>    The advantage of  using
>    the  S/Key  variant is that the security of the network protocol is
>    strengthened since the passcode is known by the KDC and can be used
                            ^^^^^^^^

I think we should say "pass-phrase" here.

>    as  part  of the key used to encrypt the KRB_AS_REP message, rather
>    than being sent protected by an encryption key that has  been  sub-
                                     ^^^^^^^^^^^^^^

Which encryption key ? Section 5 below does not clearly give the answer.

>    ject  to  possible  prior  exposure  to an attacker (see section 5,
>    below).  In any case, interoperability with the S/Key algorithm  is
>    important.

I fully agree. However, this sentence does not say (yet) how the S/Key 
algorithm works when embedded in Kerberos. Giving high level explanations 
here would help.


>    The otpc-flags field indicates whether the passcode is known by the
                                                ^^^^^^^^

I think we should say "pass-phrase" here.

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

>    able  manner. 

What means "must be provided to the KDC in a recoverable manner" ? Why do 
we suggest to encrypt the passcode ? For what reason ? More explanations 
are needed.

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

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

>    but  for  some  situations,  demonstration  of
               ^^^^
This is rather vague. Which situations ?

>    knowledge of the passcode alone may be acceptable.  


>    If the passcode
            ^^^^^^^^

I think we should say "pass-phrase" here.

>    is not known by the KDC, then send-encrypted-passcode will be  set,
                                  ^ add: "the flag" 

>    indicating  that  the  passcode  must  be sent to the KDC encrypted
>    under the key used in the response.  
               ^^^^^^^^^^^^^^^^^^^^^^^^ ?
At this time of reading, this sentence is not self-comprehensive. Which 
key are we talking of, which response ? Why not simply integrity-protect 
instead of confidentiality-protect ? Why do we even need a protection ?


>    If neither use-passcode-as-key
>    nor send-encrypted-passcode are set, the client may assume that the
>    KDC knows the passcode, but the Kerberos password  should  be  used
                   ^^^^^^^^
                   pass-phrase ?

>    along  with  the  passcode  in the derivation of the encryption key
>    (see below).



>    Note that there are specific constraints on the  integrity  of  the
>    PA-OT-PASSCODE-CHALLENGE  when some of these options are specified.

The current otp draft spec.(draft-haller-otp-00.txt) does not provide any 
integrity protection for the challenge. The current draft says: 

  "The OTP system (...) does not provide protection against either
  "social engineering" or against active attacks where the
  potential intruder is able to intercept and modify the packet
  stream."

So the question is really whether we want to provide protection against 
active attcaks or not and, if so, we should say it clearly. Then we should 
say when (and why) integrity protection is needed.


>    In particular, if any of  these  flags  are  set,  a  cryptographic
>    checksum  must be present and verified. 

Fine. But which key do we use to compute it or verify it ? On page 6 at 
the beginning of the last paragraph, we have the answer but this is rather 
late. It is as follows:

"The optional otpc-cksum field contains a cryptographic checksum  of
the preceding fields, protected using the same key as that used for
preauthentication in the initial  KRB_AS_REQ  message."

The implication is that unless preauthentication is used, we do not have 
such a key. So when pre-authentication is *not* supported we cannot 
protect the challenge. Should the conclusion be that a challenge /response 
system MUST support pre-authentication ???  :-(

In fact, all the possible combinations of such options are not clear and 
for each recommended mechanism it would be appreciated to clearly indicate 
what is required and recommended.


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

>           Also,  note  that
>           without  the  availabilty to the KDC of a relatively static,
>           unique secret key shared with the user, the only  mechanisms
>           that  can  be  used  to  protect the integrity of the PA-OT-
>           PASSCODE-CHALLENGE PADATA field are based on  either  public
>           key  cryptography  or  the  KDC's  knowledge of the passcode
>           itself.

This is a very important but rather late comment. Why not move that 
paragraph up-front in page 5 in the paragraph explaining 
PA_OT_PASSCODE_CHALLENGE, like ?

"Without the availabilty to the KDC of a relatively static, unique secret 
key shared with the user (like the Kerberos password), the only mechanisms 
that can be used to protect the integrity of the PA-OT-PASSCODE-CHALLENGE 
PADATA field are based on either publickey cryptography or the KDC's 
knowledge of the passphrase itself."

Note that this does not prevent to explain when/why integrity protection 
of the challenge is required.


> 5. Limitations
> 
>    Passcode implementations requiring the use of  the  send-encrypted-
>    passcode option are discouraged as their use on the network is less
>    secure than the case where a combination of the users password  and
>    passcode  is  used  as the encryption key.

On the other side we could say:   :-) 

"Passcode implementations requiring the use of the Kerberos password are 
discouraged as their use from untrusted terminals is less secure than the 
case where the encryption key is derived from the passphrase."

Again we should not so much discourage S/Key0 which is, from an outside 
attacker, as secure as the the classic S/Key method.


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.

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 ?


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.


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