Subject: [SIP] Re: SIP gateways and authentication

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Aug 2000 01:25:50 -0400

> David Harris wrote:
> 
> If an H.323 or MGCP originator calls a SIP user agent through a
> gateway, I am thinking the messaging should go from the gateway to a
> SIP proxy server and then to the SIP user agent. My guess is that
> registering all possible originators from the gateway wouldn't be an
> valid solution so if the proxy server is authenticating INVITEs, how
> is authenticating an INVITE from a gateway handled?

This is a good question; one that we have mentioned in passing here and
there, but for which we have not  yet settled on a solution.

Let me rephrase the problem. A user makes a call from a PSTN phone
through a PSTN->SIP gateway. This call arrives at a proxy server, then
gets routed to a UAS. Either or both of the proxy/UAS might challenge
this request. In this case, who is being authenticated, the gateway
itself, or the user calling in through the gateway? If its the user
themselves, how would that work?

One might argue that authentication of a gateway by a proxy is useless;
really in this case you want a hop by hop security mechanism like IPSec
or TLS, and forgo completely the high overhead SIP authentication for
each message. Then again, in the absence of support for IPSec or TLS,
SIP proxy authentication migth provide a way to authenticate the gateway
from a proxy.

It also seems unlikely the UAS would really be interested in
authenticating the originating gateway.

So, given there are useful cases for authenticating both the gateway and
the user calling in through the gateway, how do we know which is being
challenged?

Some options:

1. The realm indicates this. For example, a realm of "gateway" would
indicate that the gateway is being authenticated, "user" means the user.
We wouldn't need to standardize the actual words here, but rather
standardize that the realm would indicate which was the case through
administrative configuration.

2. Use a different response code for each case. Probably not a great
idea.

3. Others?

I'll also note that this problem is not limited to gateways - its the
fundamental issue of whether you authenticate a device or a user, and
could equally well apply to a softphone application, single line
gateway, and trunking gateway.

Thoughts on this issue?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Aug 2000 08:47:02 -0700 (PDT)

> themselves, how would that work?

    It depends. Clearly the gateway must proxy the
    authentication no matter what.
 
 > SIP proxy authentication migth provide a way to authenticate the gateway

   Probably, though you may again want to have a "default"
   service which is authenticated as the gateway (directly
   or implicitly through the lower level SA) and a user
   authenticated service.

 > authenticating the originating gateway.

   Why not? It may very well be that I don't trust
   or have control over my first hop proxy. Assuming
   that the gateway had a default secondary dialtone
   IVR maze which would change the From: address and
   respond to any challenges with a PIN, this is 
   pretty much exactly what you'd want.
 
 > 2. Use a different response code for each case. Probably not a great

   I think it's a slippery slope trying to draw
   a difference between "gateway" and "user". A 
   better way to think of this, IMO, is that a
   particular device may at any time take on one
   or more identities, and that at any point each
   proxy/UAS is entitled to demand authentication
   for an identity in its realm. This is consistant
   with real life: I have a drivers license for
   driving, a credit card for buying dinner and
   a cisco badge for getting into our buildings.
   At each place, a different identity is stored in
   those pieces of plastic and each demand the
   proper one for its realm. 

 > gateway, and trunking gateway.

   Yes, I'll say again that like my wallet, it
   is necessary to be brutally parsimonious about
   the size of credentials. For SIP, I really,
   really think we need to introduce the concept
   of cached credentials on the UA/proxies so that
   you can transfer a relatively large and/or
   expensive credential (kerberos ticket,
   X.509...) once, and use a keyed hash for
   subsequent messages. If it were just one
   credential that might be demanded upon the
   path, it might be OK (and with public key
   operations, even that is doubtful), but the
   possibility of an unlimited (where for both
   kerberos and X.509 "unlimited" is > 2) set
   of credentials means that you couldn't do
   UDP INVITE's without fragmentation which 
   really sux.

   An iterative model of challenge/response/cache
   where the UAC sends a keyed hash based on a
   shared symmetric key after the initial
   challenge would scale *much* better.

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 13:49:56 -0400

Michael Thomas wrote:

>    pretty much exactly what you'd want.

Also, if the gateway provides the caller id (e.g., as From), the UAS
might be very interested in gauging whether it can trust this
information. 

>    proper one for its realm.

Also note that the realm is the challenge *from* the UAS, so this would
not be particularly useful in the general case.

The model seems a bit different depending on whether we're talking about
basic/digest or PGP (or S/MIME) authentication.

For basic/digest authentication, the gateway would have to know a user
id and password registered with the remote UAS, appropriate for the
realm "challenge". It's not likely that either a gateway or proxy will
know what user names and passwords are valid at the callee UAS. (It is
much more likely that a GUI-equipped SIP UAC will have this information,
e.g., embedded in an address book or other cache, similar to how web
browsers handle authentication.)

For PGP or S/MIME, this is much more likely, as long as I can get
something that is certified. Again, very similar to server
authentication in a web case. In that model, the UAS would simply get
"this call originated from a gateway that has the private key of
Telephant Telephone Company." This would likely be good enough for me to
judge whether this company will deal with crank calls appropriately and
whether the caller id is more than a random bit string. (What you really
want is probably something stronger, such as a way to find out whether
this entity is certified in some way to have these properties, as the
average callee is unlikely to recognize Granby Telephone, say.)

Since the number of calls from a particular gateway to a particular UAS
are likely going to be very low in most instances (I'd guess no more
than ten a day), long-lived associations or caching aren't any more
necessary than for S/MIME or PGP-secured email.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Aug 2000 11:32:34 -0700 (PDT)

> average callee is unlikely to recognize Granby Telephone, say.)

   I guess I'm missing the huge difference
   here. Both situations the UAC is somewhat
   clueless about what credentials it needs
   to ship for the URI. It can guess, and may
   do a reasonable job at that, but it looks
   fundamentally the same to me.
 
 > necessary than for S/MIME or PGP-secured email.

   The caching may not be very important on the UAS.
   It becomes more important the farther upstream
   you go. It seems silly to always be shipping
   credentials to my first hop proxy, for example,
   when a far simpler keyed hash would do. The 
   trick for the UA's is to know when the
   credential has been cached so that it can use
   the faster method. This is trivial for the
   first hop, but problematic at subsequent hops
   since you don't exactly know how a particular
   request URI will be routed until you try it.
   Maybe there's some algorithmic ways of
   accomplishing that, but I suspect that
   heuristics may be easier to implement and
   provide adequate results.

		    Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 14:53:55 -0400

Michael Thomas wrote:

>    fundamentally the same to me.

No, this is very different. In the certificate (X.509, S/MIME, PGP)
case, the UAC doesn't need to know anything about the receiver. It
simply sends a cert saying "CA X believes I'm Telephant Telecom. If you
believe CA X, you'll trust that I'm indeed Telephant." For basic and
digest, the UAC has to know

- what user id's are valid at the UAS
- what secrets are associated with those userids.

Generally, a gateway calling a random SIP URL (obtained via enum, say),
would have no clue about any of these.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Aug 2000 12:01:43 -0700 (PDT)

> digest, the UAC has to know

   Not true. You are still guessing that the UAS will
   trust that certificate hierarchy. That may not be
   a valid assumption. It's the exact same problem 
   as guessing which basic/digest realm might be needed
   along the way. I can just as easily posit a global
   symmetric key realm as a global PKI realm. Both
   are fantasies.

   This is a TANSTAAFL problem inherent in proxy
   routed traffic.

			Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Aug 2000 12:34:35 -0700 (PDT)

Henning Schulzrinne writes:
 > Given the practical success of having CA's embedded in millions of web
 > clients, this seems at least feasible and works millions of times each
 > day, even though it's less than ideal if you're a new CA and want to be
 > recognized as such.

   Just because I trust your certificate to name
   you as Henning doesn't relieve me of knowing
   what you're authorized for. That means that I
   keep it in some sort of database or it needs
   to be transfered in the authentication token
   (cert, ticket). Keeping a symmetric key in that
   database as well doesn't seem to much of a
   stretch.

   So, I still don't see what you've bought
   yourself with PKI, other than lots of CPU
   cycles to do private key operations. If you
   encode the authorization into the cert you
   fall back into the same problem of realm 
   multiplicity, if you don't you've consigned 
   yourself to database lookups.

 > This does not mean that you couldn't use a ticket-based system (Kerberos
 > and kin), but we're here talking about the existing SIP authentication
 > mechanisms Basic, Digest and PGP (or, in the case of S/MIME, trivially
 > added), not something that doesn't exist yet in our context.

   There are two possiblities:

   1) Carry the authentication in SIP itself which runs
      into the MTU problems, naively.
   2) Carry the authentication in a separate protocol
      (such as the results of the KINK to-be-WG) and
      reuse digest authentication as the means of
      generating the keyed hash.

   I generally don't like reliance on third party
   protocols/questionable layering, but it is a
   possiblity and is somewhat inherent in both
   IPsec and TLS schemes (less so with TLS, but
   still).

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 15:10:22 -0400

Given the practical success of having CA's embedded in millions of web
clients, this seems at least feasible and works millions of times each
day, even though it's less than ideal if you're a new CA and want to be
recognized as such. I see no way to have a global symmetric key realm
without additional protocol support. (Even with a monster LDAP database
containing the world's users, there doesn't seem to be a way that a UAS
can verify your *digest* secret in an external database without also
obtaining a useful secret that the UAS can employ elsewhere.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 16:39:04 -0400

Michael Thomas wrote:

>    what you're authorized for.

There are two different things here:

- trusting the information (which is what we started out from in this
gateway discussion, e.g., trusting the caller-id value). Here, it's good
enough to know that it's an AT&T gateway, say (see earlier discussion).
Whether I accept a call from that gateway is a separate matter and
something that no third party can authorize anyway. (That is, the
traditional "Cisco badge" model doesn't apply here.)

- granting authorization (should my phone ring). 

For authorization, the Basic/Digest mechanisms works, since I can hand
out user names and secrets to the very small subset of people in the
world that I want to be able to call me (at least outside certain hours
or using certain means of communication). This also works for outside
gateway access since the gateway has to have at least an indirect
business relationship with me in any event, requiring prior
establishment of trust.

>  That means that I

See above. Again, at the danger of repeating myself, I'm talking about
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.) 

>       into the MTU problems, naively.

Are there statistics on the typical cert size?

>    IPsec and TLS schemes (less so with TLS, but

Again, none of this addresses current capabilities and models.

---

From: Paul Krumviede <[email-masked]>
Date: Fri, 25 Aug 2000 13:50:47 -0700

i'm missing something here. with certificates, one can,
at least in theory, attempt to do path discovery/validation,
which seems to be able to do much better than "database
lookups" in trying to deal with "realm multiplicity." one can
also attempt to specify and apply policies as part of the
path validation exercise. one can't do this with older
PGP keys, but one can get an X.509 certificate for at
least some PGP keys (i haven't tried it with all the
different flavors of keys).

granted, this could chew up lots of cycles and network
time. also, there may be reasons to not want to accept
certificates from third parties, such as verisign class
one certificates, as they don't really give much authentication,
but that seems like something that could be handled by
policy in the verification path.

as to authorization issues, one could look into attribute
certificates, but that seems orthogonal to authentication
(and can't be done in a pure PGP or S/MIME context
anyway, as far as i know).

-paul

--On Friday, 25 August, 2000 12:34 -0700 Michael Thomas <[email-masked]> 
wrote:

>  > day, even though it's less than ideal if you're a new CA and want to
>  be > recognized as such.
>
>  > This does not mean that you couldn't use a ticket-based system
>  (Kerberos > and kin), but we're here talking about the existing SIP
>  authentication > mechanisms Basic, Digest and PGP (or, in the case of
>  S/MIME, trivially > added), not something that doesn't exist yet in our
>  context.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Aug 2000 22:56:47 -0400

(trimming sip-implementors from the cc list)

As with many of our security discussions, I think we've gotten a bit off
track. The problem is very spceific; does proxy (and UA) authentication
actually authenticate the originating device, or the user of that
device. Seems like there were valid reasons to authenticate the user and
the device for both proxy and regular (401) authentication. Henning's
example of trusting the caller-ID on the gateway is a good one.

So, given that we need both, we have an ambiguity in the spec which we
must resolve. WHich one is implied by the current authentication
mechanisms (user, I would assume), and how would we specify that the
other is what is desired? Should we impose some structure on the ream to
indicate this, so that:

realm="device:MyRealm"

indicates that device authentication is desired for that specific realm? 

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2000 10:16:16 -0700 (PDT)

> indicates that device authentication is desired for that specific realm? 

   I don't think this is a good idea. If a SIP
   UA, say, gets challenged to authenticate in
   a particular realm, it should first check if
   it knows how to authenticate to that realm
   directly (ie, has the password, etc). If it
   does, then it provides the authentication
   proof. If it doesn't then it needs to pop it
   up to the user who initiated the call and they
   get to figure it out. 

   As such, I see no motivation for drawing a 
   distinction between "devices" and "users".
   What I think *is* clear is that an INVITE
   may traverse multiple different authentication
   challenge points. However this has nothing to
   do with a user/device false dichotomy. I,
   [email-masked], may very well be challenged to
   enter an acct#/PIN for my Telephant.com (:-) 
   calling card and then again challenged to
   listen to my SIP voice mailbox at cisco
   all in the same proxy-routed INVITE. This
   implies that you need to ship multiple
   credentials each time, but as far as I can
   tell, that's legal SIP. 

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Aug 2000 16:03:42 -0400

I'll repeat my question, since the answer matters greatly: are you
talking about Basic/Digest or PGP authentication? 

Since that's what's implemented, I'm assuming Basic/Digest for now.

With Basic/Digest, it only matters what name(s) and associated secrets
the receiving proxy recognizes. If it recognizs gateway:spoiled-milk for
all request-URIs, that's fine, but it's not clear what establishing a
canonical user name, realm or password accomplishes.

In any event, the secret has to be hard-configured for each gateway. For
the proxy and UA case,

sip:[email-masked]
...realm="foo"
and
sip:[email-masked]
...realm="foo"

are different protection spaces.

As a guide to implementors, it may be useful to indicate that if you
don't care about different authentications for different request-URIs,
it makes sense to establish a "global" user name/password/realm that's
the default challenge if a particular user name doesn't have its own
realm or set of user names. Similarly, gateways may want to try their
global user name and secret when challenged. 

> example of trusting the caller-ID on the gateway is a good one.

I don't think this phrasing helps. Basic/Digest authentication assures,
for a particular request-URI on that proxy, that the requestor has one
of possibly several valid name/secret combination. If the proxy or UA
allows the same user for all request-URIs, it's effectively an
authentication for the 'device'. (This assumes, for example, that the
per-number cgi scripts running on the server are trustworthy. With basic
authentication, a script could easily get the secret and then create a
fake call for any phone number on that server.)

---

From: "James A. Donald" <[email-masked]>
Date: Mon, 28 Aug 2000 21:32:30 -0700

--

It seems to me that the more general problem is that the existing 
certificate structure is designed to prove that Telephant Telecom is the 
real Telephant Telecom , rightful owner of various cheque accounts and 
credit cards, an entity capable of being sued.  Ultimately, it is designed 
to facilitate shopping and contracts.

It appears to me that the goal of encryption in SIP is not to enable 
shopping and contracts, but merely to prove that when you are communicating 
with [email-masked] you are communicating with someone who knows the 
password to log on to the account [email-masked], and only that someone.

If our system has to know that [email-masked] is the real Telephant 
Telecom, in order to prevent someone from listening in to his sex chat, we 
have problems.

If everyone in the system has to know that [email-masked] is the real 
Telephant Telecom, we have really big problems.

Sometimes Joe97 might want to prove he was the real Telephant Telecom for 
some reason, but most of the time the software merely wants to know he is 
the real Joe97, and does not want to deal with the burden of an additional 
mapping between SIP identities and authenticated true names.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Aug 2000 09:02:55 -0700 (PDT)

> traditional "Cisco badge" model doesn't apply here.)

   Oh, OK. I see where you're going. I didn't read the
   original message this way.
 
 > business relationship with me in any event, requiring prior

   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.

 > Secret-based authentication, as in Basic and Digest, does nothing for me

   Not true. 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 it doesn't require expensive public key 
   operations at the endpoints or proxies. The 
   only place that symmetric key solutions come up
   short is in their inability to deal with the
   situation where you can, without prior
   knowledge of the recipient, sign something that
   the recipient can verify directly. This is
   useful sometimes -- particularly in multicast
   cases -- but the unicast case only requires a
   an end to end INVITE to make that advantage
   disappear.

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

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

	 Mike

---

From: "James A. Donald" <[email-masked]>
Date: Wed, 30 Aug 2000 20:53:23 -0700

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

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, 
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
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO
      478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK

---

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: Paul Krumviede <[email-masked]>
Date: Thu, 31 Aug 2000 11:16:10 -0700

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

-paul

--On Thursday, 31 August, 2000 09:59 -0700 Michael Thomas <[email-masked]> wrote:

>  > attacks on the password.  Kerberos permits offline attacks.

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 31 Aug 2000 17:17:56 -0700

Comments below.

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.

Jonathan

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 31 Aug 2000 19:37:11 -0500

Am not sure such complexity is jutified for phone calls having
the cost close to e-mail.

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>James A. Donald
>Sent: Wednesday, August 30, 2000 10:53 PM
>To: Michael Thomas; Henning Schulzrinne
>Cc: Michael Thomas; Jonathan Rosenberg; David Harris;
>Sip-Implementors
>(E-mail); sip
>Subject: Re: [SIP] Re: SIP gateways and authentication
>
>
>     --
>The problem is described in
>http://theory.stanford.edu/~tjw/krbpass.html,