Subject: Re: [SIP] Re: SIP gateways and authentication

From: "James A. Donald" <[email-masked]>
Date: Fri, 01 Sep 2000 08:42:11 -0700

--
At 11:16 AM 8/31/2000 -0700, Paul Krumviede wrote:
 > there is a complexity result that use of "public key techniques are
 > unavoidable for password protocols that resist off-line guessing
 > attacks." i doubt we can require that in all environments...

No there is not.

If you put a turbine into a car, this does not require you to build a car 
with wings that flies.

We need a solution that for the user works like kerberos, does not require 
anything more of the user or administrator than kerberos requires, but is 
secure, unlike kerberos.  The underlying technologies used to achieve this 
are irrelevant.  As it happens, people who design kerberos like solutions 
these days tend to use public key techniques, just as people who build 
planes these days tend to use modern tools.

There is nothing about the underlying technologies that leads to the 
properties of the existing protocols.  The technologies are just 
tools.  You use bolts in an plane, and bolts in a bridge.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      3nBV+z9qm9n1z0nZqN4eSN1cTmAoF+Ne4z9VMplf
      478WQjH1WAD4d1A3hu7wyNA8KwewETOKL35vaVLg3

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "James A. Donald" <[email-masked]>
Date: Fri, 01 Sep 2000 09:08:04 -0700

--
At 08:53 PM 8/30/00 -0700, James A. Donald wrote:
 > >While you are correct that we should use Kerberos like security
 > >servers,  Kerberos itself is broken. It has been broken for some time.
 > >
 > >The problem is described in http://theory.stanford.edu/~tjw/krbpass.html,

At 05:17 PM 8/31/2000 -0700, Jonathan Trostle wrote:
 > The first line of defense against dictionary attacks in Kerberos is
 > a reasonable password policy. The paper you cite does nothing to
 > show that a reasonable password policy is not adequate to prevent
 > these attacks - the paper demonstates attacks against a Kerberos 4
 > realm with a very weak password policy. In particular, some users
 > had passwords with 1 character, some had passwords with 2
 > characters, etc.

That was not my reading of the paper.

The password checker discouraged, but did not flatly prohibit weak 
passwords.  The vast majority of the passwords that they cracked were 
passwords that the password checker had accepted.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      A0bbR6u7j50dqDEO+2Fc+OObr3x+2gH94Mde3CJQ
      4dxmy4K5kGimwMrQ0pNJ1zC9crVXCSszvx0j4Lp4z

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 01 Sep 2000 10:55:32 -0700

A password checker is not a good way to prevent weak passwords, since it is well established that some users will pick weak passwords if given the choice. Kerberos 5 password policy will not allow a user to pick a new password that does not conform with the password policy. One of the parameters for a password policy is minimum length.

Jonathan

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2000 08:37:48 -0400

I doubt that the SIP WG is the right group to evaluate or standardize
new general-purposed security mechanism. (Actually, I'm pretty sure it's
not...) If there are problems with Kerberos, they should be taken to the
relevant working group or the IESG. If there are new and interesting
authentication mechanisms, their authors should request a BOF to pursue
possible standardization.

Thus, for the time being, we're "stuck" with existing mechanisms,
including S/MIME and PGP (and MIME-PGP), plus Basic/Digest, at the
application layer, TLS at the transport layer and IPsec at the network
layer. Kerberos has been proposed, but unless it is very clear that this
adds new capabilities and does not raise any new security capabilities,
I'm not convinced that adding new mechanisms is going to be particularly
helpful.

Since most authentication is client-to-client, CPU issues are probably
not as grave a concern (no more than, say, for email). The ability to
implement PK protocols (or Kerberos) in very small devices is much more
likely to be an issue.

"James A. Donald" wrote:
> 
>      --
> At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote:
>  > A cross realm Kerberos based solution would be more than adequate to
>  > give you a high level of confidence that a piece of information came
>  > from the realm it claims to have come from.
> 
> and with the passage of time the problem becomes ever worse, due to the
> increased power of offline dictionary attack hardware and software.
> 
> A modern security system, (which kerberos is not) must only permit online
> attacks on the password.  Kerberos permits offline attacks. In a modern
> system the attacker must only be able to test his guesses by using the
> guessed password to attempt to establish a secure connection to the
> security server.  After some large number of consecutive failures, the
> security server will temporarily disable the account, and send to the user
> an insecure notification containing a log of all information about the
> failed attempts.  After each successful logon, the system sends the user
> information about all previous failed attempts through the secure connection.
> 
> The proposal to use PGP keys or verisign keys uses modern security
> techniques to solve the wrong problem.
> 
> The proposal to use kerberos techniques addresses the right problem in the
> right way, but the particular details of the solution are obsolete.
> 
> I propose the following EKE like solution, similar to that described in my
> web page http://catalog.com/jamesd/kong/secure_video.htm
> 
> The user establishes a secure connection with the secure personal presence
> server.
> 
> The personal presence client logs in to the personal presence server using
> the name and password.  The password is never revealed to the server.   An
> outside attacker would have to try his guessed password by attempting to
> log on.  If he tried lots of logons, this would become noticeable.
> 
> The server knows, not the password p , but h(p)*G where G is an elliptic
> point that the server makes known to anyone.
> 
> When the user created his account, his client software informed the server
> of h(p)*G through https.  The software ensures that it gave this account
> creation information only to the real server, thanks to the usual https
> mechanism, which guarantees the server's true name.  The server does not
> need to verify the users true name.
> 
> Lower case letters stand for very large integers, upper case letters stand
> for elliptic points. h(x) means "one way hash of x "
> 
> The object of the logon protocol is to ensure that the client program is
> communicating with a server that knows h(p)*G , and the server knows it is
> communicating with a client who knows h(p)    In this the protocol differs
> from SPEKE, where both the client and the security server both know
> p.   The implementors have to keep in mind the usual EKE concerns described
> in http://world.std.com/~dpj/speke97.html.
> 
> When the user logs on he sends the server his logon name in the clear, The
> server generates a true random number b , and sends the user b*G .
> 
> The client similarly generates a true random number c and sends the server c*G.
> 
> An attacker can discover c*G, b*G, and G, but cannot calculate c or b from
> this information.
> 
> The client then generates the secret elliptic point (b*G)*[c+h(p)]
> 
> The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)]
> , which will be equal to the point generated by the client.  This elliptic
> point is then used as the symmetric secret key for secure communications
> between client and the security server until the user logs off.
> 
> In order to succeed with the protocol, in order for the client to construct
> a secret elliptic point equal to that of the server, it must know h(p)
> corresponding to the server's h(p)*G
> Of course, ultimately our objective is not secure communications with the
> security server, but secure communications between any  two users, and
> secure communications between a user  and all the various entities that are
> involved in setting up his communication.
> 
> The simplest way of solving this is the classic DH method, now patent free,
> where each entity generates one true random transient public/private key
> pair, which lasts the duration of a login session.  Each security server
> authenticates the public keys of its users and entities, and only the user
> or entity knows the private key.
> 
> This could potentially lead to a very large number of public key
> operations, which are quite slow  Because the keys change infrequently,
> this problem can be solved by each entity caching the results of previous
> public key operations.   The cache is discarded when the entity logs out..
> 
> When Bob sends an authenticated and secure message to Ann, saying "Hi Ann,
> how are things?" it would use intolerable bandwidth if that message, and
> each of the various acks and nacks by various entities required to locate
> Ann and set up and send the message, required a verisign style public key
> signature, or pgp style public key signatue.
> 
> Instead, for any two entities, there will be a unique DH shared secret,
> constructed from each one's DH key.  Each obtains the other's public DH key
> from the others security server.  That unique shared secret will not change
> as long as both entities remain logged on to their security server.   Since
> each ack and nack will be sent encrypted using that unique and unchanging
> shared secret, no  public key operations will be needed to prove who is
> sending the ack, since only the apparent author or the apparent recipient
> could decrypt it or encrypt it.  We have only one public key operation per
> logon time per pair of entities that need to communicate securely, which
> will have an insignificant bandwidth and computational cost, not several
> public key operations per ack and nack, as would be required if we employed
> a signature system similar to that employed by verisign or PGP.
> 
>      --digsig
>           James A. Donald
>       i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO
>       478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2000 10:58:21 -0400

Removing sip-implementors, since this is really not an implementation
issue.

> 
>    With Kerberos based key distribution, Digest could
>    be almost aribitrarily large given cross realm
>    operation. With PKCROSS, you move the PKI
>    problem to the KDC which makes for an even more
>    scalable solution than pure PKI solutions.
>    Effectively, KDC's become PKI aggregators which
>    shield the vagueries of cross realm policy from
>    mere mortals.

I know you like Kerberos; since a large fraction of us want to first
make the existing mechanisms (which do not include Kerberos work), it
might, at this stage, be more helpful to write this up as an I-D rather
than have one-message discussions.

That said, Basic/Digest (and the other mechanisms) have the advantage
that they work using either no infrastructure (for Basic/Digest) or
existing infrastructure (company or domain-name-based certs). I also
suspect that any new security infrastructure will likely be developed
and deployed as part of a more generic AAA mechanism rather than be
SIP-specific. (Indeed, if we assume that mobile providers have to share
authentication information to allow roaming, the step to making subsets
of that available for caller identification is not that large.) Thus,
maybe Kerberos-based discussions may have a better home in the AAA WGs
or should at least be coordinated with folks there.)

> 
>  > See above. Again, at the danger of repeating myself, I'm talking about

Please read the sentence above, in case you missed it.

>  > things we can do today and where they might be useful. (Beyond the
>  > do-I-trust-this-caller-id problem, public-key signed requests are also
>  > useful for the is-this-call-really-from-the-local-gas-company problem.
>  > Secret-based authentication, as in Basic and Digest, does nothing for me
>  > there.)
> 
>    Not true. A cross realm Kerberos based solution
>    would be more than adequate to give you a high

At the danger of repeating myself (again): We do not have a
Kerberos-based solution today, except as vague email messages. Please
don't just ignore my repeated comments to this effect.

> 
>  > Are there statistics on the typical cert size?
> 
>    Probably, but I don't have any handy. I've
>    heard that typical certs are ~500 bytes and
>    that you need to ship part of the hierarchy
>    which may include a cert or two more. Even if
>    it's half, it's still problematic for multiple
>    realms.

Statistics would be most helpful here. If you have the model used by
today's web browsers, it would be presumably one certificate (with
pre-configured CA certificates). Given 512 bit public keys (64 bytes),
the estimate sounds close.

>  > Again, none of this addresses current capabilities and models.
> 
>    Is that actually true? If you posit a
>    pre-shared symmetric key between the two
>    entities, both digest and PGP provide a
>    means of doing symmetric key signatures.
>    It's true that there isn't a SIP endorsed
>    means of shipping Kerberos credentials, but

and no global Kerberos infrastructure, which seems the harder part

>    that doesn't mean that symmetric key PGP or
>    Basic/Digest couldn't be used as-is. I've
>    promised to write an ID by this fall on how
>    to do this, so we shall see.

Good idea. I look forward to reading it.

>          Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 Aug 2000 09:59:49 -0700 (PDT)

It looks like your argument is not with the SIP WG
but with the CAT WG. I'm sure a lot of folks there
would be willing to entertain (or not) this
argument. In particular, the assertion that that
Kerberos is inherently subject to dictionary
attacks looks more like an indictment against
symmetric key cryptography in general, rather than
Kerberos in particular. 

	    Mike

---

From: "James A. Donald" <[email-masked]>
Date: Mon, 04 Sep 2000 22:20:40 -0700

--
At 10:58 AM 8/31/2000 -0400, Henning Schulzrinne wrote:
 > That said, Basic/Digest (and the other mechanisms) have the
 > advantage that they work using either no infrastructure (for
 > Basic/Digest) or existing infrastructure (company or
 > domain-name-based certs).

But existing infrastructure is close non-existent.

Further, any system that uses external authentication is going to be a 
pain.  The users are still going to need passwords and accounts, and then 
they will need to somehow create a mapping between the identity provided by 
the external system, and the identity provided by passwords and accounts.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      Lnv4Xqow/SrLQBLy9Zsgi1mP0lyd3vJuHCQe7Gc/
      4B/GAaUW8T9qoYXG2ML4lysggFXszPJkTRhQ/wNvM

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Sep 2000 04:48:27 -0700 (PDT)

Henning Schulzrinne writes:
 > Since most authentication is client-to-client, 

   Why do you suppose that? This assumes that
   proxy-routed traffic won't be the norm. I 
   can think of a lot of cases where that
   assumption is incorrect.

 > CPU issues are probably
 > not as grave a concern (no more than, say, for email). 

   Email does not have post dial delay constraints.
   PGP/SMIME email doesn't have scaling issues on
   large trunking gateways, conference servers, 
   voice mail servers, etc, either. 

 > The ability to

   Symmetric key algorithms can fairly easily be
   accommodated by IP toaster grade embedded CPU's
   these days; not so public key intensive
   applications. Flash is finally coming down in 
   price due to pressure from camaras and the 
   like. Security isn't free but designed
   intelligently it doesn't have to be either
   brain-dead slow or out-of-reach expensive.

	      Mike

---

From: Stephen Thomas <[email-masked]>
Date: Wed, 20 Sep 2000 15:11:35 -0400

Finally getting around to reading old email and noticed no one had answered 
this.

>the estimate sounds close.

X.509 certificates can vary a lot in size, as CAs like to stuff all sorts 
of things within them. (Even, for example, Certification Practice 
Statements.) As a rule of thumb, Verisign certificates are around 1500 
bytes. For anyone wants to see the gory details, _SSL_and_TLS_Essentials_ 
http://www.amazon.com/exec/obidos/ASIN/0471383546/ breaks down a real 
Verisign Global Site ID byte by tedious byte; the example is 1384 bytes.