Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?)

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Feb 2002 03:13:34 -0600

I believe there are reasonable threats against SIP (at least one of which is
described in bis) that justify end-to-end confidentiality of bodies. I'm not
sure that I want intermediaries to be able to inspect or potentially modify
SIP bodies, especially SDP, for a number of reasons. I think we need a base
SIP mechanism to address this concern.

Originally, S/MIME was discussed in a separate draft authored by Henning. We
pulled the S/MIME material into bis, and elaborated on its implementation
because of the known threats against the protocol.

There are, incidentally, numerous things in bis which have yet to be
implemented by any SIP device to my knowledge. That is one of the reasons
why SIP remains a Proposed Standard rather than a Draft. No doubt the S/MIME
mechanism will be refined as we progress with the SIP standard.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 12:28 AM
> To: Michael Thomas; Juha Heinanen
> Cc: Jonathan Rosenberg; Lawrence Conroy; Henry Sinnreich; 'Michael
> Thomas'; 'Peterson, Jon'; [email-masked]
> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?)
> 
> 
> 
> > Juha Heinanen writes:
> >  > i have seen sip UAs that support basic authentication 
> together with tls
> >  > and digest authentication without any transport layer 
> security, but i
> >  > haven't heard of any that would do smime.
> >  > 
> >  > is there any?  if not, then does it make sense to have 
> smimi in the bis.
> > 
> >    I don't think so. The addition of SMIME seems to
> >    be a solution in search of problem. Also: SMIME
> >    is a complete pig. I can't imagine any low end
> >    UA's implementing it. It certainly doesn't
> >    deserve "SHOULD" status.
> 
> I kind of like the opportunistic SMIME scheme in Bis. However,
> I do agree with you that it's not a low-end thing. My personal
> recommendation would be either a MAY or a separate RFC.
> 
> Jari
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Feb 2002 12:15:29 +0200

> SIP mechanism to address this concern.

I think we're in rough agreement about the above, though we may differ
in the exact level of importance put to the intermediary inspection, hence
the difference in SHOULD vs. MAY. I do believe intermediary inspection
is an issue, but perhaps not as big of an issue as is actual media stream
protection. Given that the latter can be handled e2e using e.g. SRTP without
relying on security of the SIP signaling, I tend to think that the most pressing
needs of the users are satisfied even if no S/MIME is present. Put in
another way, if I had a budget to implement a single new thing in a multimedia
terminal I would probably go for SRTP rather than S/MIME.

Continuing this line of though slightly beyond the original scope of the
discussion, my list of priority order for SIP security is:

1. Operators and gateway owners get paid: The only thing that
    appears to be able to do this over proxies etc. is Digest, possibly
    enhanced in some manner. This is a clear MUST for everyone
    (like it is in Bis).

2. SIP does not introduce new DoS holes that "Internet-Wreckers" could
    employ. This isn't as much of an issue in closed networks and under
    some sort of lower layer security, but it appears that people want to
    allow open SIP nodes for everyone to contact them, and here I think
    lies some danger. It appears to be possible to get at least small
    amounts of amplification by reflecting packets, possibly with
    spoofed addresses, through a proxy: INVITE, 180 Ringing, 200 OK etc.
    I'm glad to find the Anon Digest in latest Bis that addresses this.
    One thing that is still unclear to me though whether we should perhaps
    have a MUST somewhere where this should be applied. A proxy/b2bua
    that doesn't have TLS or IPsec at the bottom, MUST apply Anon Digest?
    Another thing that is unclear to me is whether we'd be safe after that.
    Maybe, but somehow I'd like to be convince myself better.

3. User's multimedia streams are secured. SRTP (and MIKEY) should
    take care of this as described above, or possibly IPsec in some circumstances.
    Clearly we don't need to have any MUSTs in Bis about this.

4. Some sort of signaling protection may also be necessary. The
     interesting thing about this is that there appears to be widely
     different requirements about this. Cellular folks scream about
     heavy weight public key crypto, kernel TCP state (may be easier
     in the app as you know you're going to have a million open sessions),
     roundtrips and here enhanced digest schemes appear the right
     engineering tradeoff. In some other situations either IPsec or TLS
     would do the job. The trouble is that any MUSTs in the spec have
     been known to cause a strong reaction from the group that feels
     their case was not favored in the selection, and are going to lead
     to dead code in products if something extra has to be implemented.
     My call here could be to have a MUST for enhanced digest and
     a SHOULD for TLS, MAY for IPsec and SMIME, leaving SIP with a
     scheme that can cover both h2h/e2m/e2e protection and
     UDP/SCTP/TCP, and room for the different groups to do their
     favorite thing in addition.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 07:23:00 -0800 (PST)

> SIP mechanism to address this concern.

As far as I can tell, only the authors and the AD
have shown any interest in this. Nor did the
security design team have any input on this at
all. I don't call that rough consensus. 

This is trivially separable from the bis draft.
Life manifestly will go on without SMIME support,
regardless of any threatened vetos. The most
likely outcome is that millions and millions of
UA's will ignore this just like they ignored the
PGP stuff. Forcing it in because of parlimentary
reasons is oh-so ITU-like; as in, engineering for
the sake of engineering, rather than for the sake
of accomplishing something useful.

		 Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 Feb 2002 07:46:41 -0800

> of accomplishing something useful.

I'm not sure we have rough consensus but I also don't agree that only
the AD and the authors have shown any interest.

Let's take a step back:
The current SIP security mechanisms have NO way to protect against a
malicious (but certified) proxy. S/MIME provides such a mechanism
(albeit, not as cleanly as I would like).

SIP either needs to have something like S/MIME support or it needs a
disclaimer to the effect that there's basically no security.

For instance:
"SIP security relies critically on the security of the
proxies.  In any environment where the messages may go through
untrusted proxies, no security properties can be assured."

As for the assertion that we're behaving like the ITU...  what of it?
My view of the situation is a little different.  Left to their own,
WGs almost invariably design protocols with weak security
mechanisms. One of the jobs of the IESG is to exert backpressure on
the WG when that happens. The IESG obviously needs to be sensitive to
the claim that something is difficult to implement, but that doesn't
mean yielding whenever some implementor claims that they just don't
want to.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 08:05:24 -0800 (PST)

You seem into falling into a false dichotomy that
if SMIME doesn't go into bis, we are now and
forever resigned to inadequate security for
SIP. This is bogus. A standards track draft could
trivially be pursued by the WG and it would be far
stronger if there were actual ROUGH CONSENSUS
amongst the implementors rather than fiat by those
manning the veto buttons.

What is in bis now seems to have no support
amongst those building UA's and since it's only a
SHOULD there isn't even a penalty if you ignore
it. Also: I have seen no evidence that the
backpressure has even considered anything other
than what is expedient to give this draft a new
RFC number regardless of utility.

	Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 Feb 2002 08:19:33 -0800

Michael Thomas <[email-masked]> writes:
> SIP.
I don't think it's a false dichotomy. Rather, it's a pretty
accurate statement of the common pattern. To whit: WG produces
a document with horrible security problems. Says, "we'll fix
security later". Document passes. WG doesn't fix security.

> This is bogus. A standards track draft could
The problem with doing it as a separate  draft is that the WG
almost never has any incentive to push that draft through,
precisely because of the kind of complaining from implementors
that you're engaging in now. OTOH, if the IESG holds up the main
draft, that gives the WG some incentive.

[Disclaimer: Since I'm not on the IESG, I clearly don't speak for them
on this one, but that's my view of the situation.]

> it.
I'd be perfectly willing to have it a MUST if that would
make you happier.

> Also: I have seen no evidence that the
We'd get a lot further here if you'd stop accusing other people of
bad faith. From what I've seen the authors are genuinely interested
in producing something that will more or less work.

-Ekr

---

From: Allison Mankin <[email-masked]>
Date: Fri, 15 Feb 2002 11:26:17 -0500

> on this one, but that's my view of the situation.]

That is the AD's view of the situation too.  Thank you.

Allison

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Feb 2002 18:39:58 +0200

> that you're engaging in now. 

I think everyone here agrees to this. There's
no question at all that we need a mandatory
basic-level security in RFCs. Same RFC or
different RFC with a keep-in-queue-until-reference-
is-there gets you the same result.

But I think the current discussion has
often the following pattern:

  A: MUST Foo
  B: Oh no, not Foo, can't implement it and not useful
     for me.
  A: If not Foo, then there's a security hole
     and IESG might stop us from getting through
     if we have a security hole
  B: $%%^1

This doesn't appear like a very useful discussion
form. But A's argument above isn't always the
right one. We are constantly reminded that the
chosen security mechanisms do not cover all
needs and threats, and I agree. But this invalidates
the argument above on IESG stopping us if we
drop a particular security piece. What *really*
matters is whether we have the right priorities
for the threats we intend to solve, not that we
have necessarily solved all threats. Just the
ones that we and IESG feels are the main ones.

I'd like to see a list from the Bis editors that
shows their priorities and justification, perhaps
in a manner similarly to what I e-mailed few mails
ago. THEN we could move on from this discussion
pattern into a more productive one.

Jari

---

From: Eric Rescorla <[email-masked]>
Date: 15 Feb 2002 08:47:59 -0800

> is-there gets you the same result.
Yes, I don't care which of these it is.

> We are constantly reminded that the
Agreed. It's my view that having no protection against rogue proxies
isn't really adequate. OTOH, if that's what the WG group really wants,
I'm not going to kick up an enormous fuss. However, I do think that if
we're going to accept that kind of security hole we have an obligation
to actually describe what that means in the document. The purpose of
my suggested text was precisely to get people to think about what kind
of security hole this is so that they can decide if they really want
that.

If people don't feel comfortable with putting that kind of text in the
RFC then the solution is to fix the protocol, not just pretend the
problem doesn't exist.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 08:48:25 -0800 (PST)

> security later". Document passes. WG doesn't fix security.

Are you actually claiming that SIP without SMIME
would be "a document with horrible security
problems"? I sure hope not, because if you are I
think you need to get a grip; the current PSTN
does exactly this today, and the world has not
come to an end.

 > draft, that gives the WG some incentive.

Oh, please. There has been *abundant* interest in
the WG for various security pieces. Many of the
security pieces are things that actual people have
*actually* been asking for have been ignored in
the bis draft in favor of things that nobody's
been asking for.

 > I'd be perfectly willing to have it a MUST if that would

This is a perfect example of why most security
protocols are complete failures. Making an
unworkable and bloated thing a MUST or SHOULD does
not change the dynamics of development, deployment
or system engineering. If something is useless
and/or harmful it will not be implemented,
holier-than-thou attitudes not withstanding.

If we actually want to acheive something that has
better security than the status quo -- and that is
an abysmally low threshold as far as the eye can
see -- it is generally prudent to actual consider
what is feasible in the real world and provide a
gradient which doesn't make it an all or nothing
proposition where "nothing" is the invariable
choice. But once again, what we have here is
security pixie dust thrown to the wind with no
concern with whether it solves real life problems.
In this case, the pixie dust seems to be aimed at
making the IESG happy. C'est la guerre.

 > in producing something that will more or less work.

Placing a huge new requirement on UA's with both
dubious utility and zero working group input is
an example of good faith? Who knew?

	   Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 Feb 2002 09:08:18 -0800

> an example of good faith? Who knew?
Michael, one of the things that draft authors do is put text into
drafts so that it can be debated by the WG. As for the changes
being of dubious utility, I know it's hard for you to believe,
but people might have different opinions from you about utility.

-Ekr

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 15 Feb 2002 19:12:31 +0200

> That is the AD's view of the situation too.  Thank you.

if the ADs really want the wg to publish a document that includes
unimplemented stuff that has no industry or user support and that is
there just to please the process, then the only right thing to do is to
publish the current document as "experimental". 

after that we'll have time to find out what the real solution will be
that will gain wide industry and user support and once we are all
convinced, we'll respin the document as a standards track rfc.

-- juha

---

From: Allison Mankin <[email-masked]>
Date: Fri, 15 Feb 2002 12:44:20 -0500

Juha,

Only if this were going to Draft Standard, would we bar features
that are new and unimplemented.  But anyway, the specified security
implementations are not new and unimplemented:  TLS, S/MIME
and Digest Authentication are all old specifications, widely
used in applications of all kinds.

There's a vulnerability assessment (required) in bis and
the security solutions are needed to address those vulnerabilities.
(Not all vulnerabilities for all time, but a key set).

SIP is for the Internet.  It will not pass with security based
on closed system plans of some industries, even if those
industries and vendors object to the Internet requirements of
the protocol.

Allison

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 10:01:15 -0800 (PST)

> used in applications of all kinds.

   Can you please show where SMIME is widely used?

 > (Not all vulnerabilities for all time, but a key set).

   One of the things being questioned here is how
   e2e body crypto made it into the "key set". To
   date, this seems to be an assertion rather than
   a demonstrated need.
 
 > industries and vendors object to the Internet requirements of

   With SIP, you can always do end-to-end INVITE's
   even with proxy routing. If you bring up NAT's
   and border proxies again, I'll point out that
   SMIME will not operate in those environments
   either. 

		Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Feb 2002 20:09:23 +0200

> of security hole this is so that they can decide if they really want

All true, but we have to remember that S/MIME is not the only
solution today that works against rogue proxies. In fact, the
solution deployed today for that is Digest, and S/MIME does
not fix *the* rogue proxy problem, it basically extends the
scope of the protection to privacy, and allows a wider audience
NxN benefit from the protection. Again, personally, I like the
S/MIME solution *a lot* and would like to keep it in the draft.
But perhaps as a MAY, and I would like to get more emphasis
on the security solutions that people and certain networks also
intend to use, such as digest.

Jari

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 15 Feb 2002 20:13:13 +0200

> used in applications of all kinds.

right, but who is widely using s/mime for anything?  s/mime never became
become popular for email and it is even less likely to become popular
for sip applications.  so including s/mime in the sip spec and
pretending that we have solved the problem is nothing but fooling
ourselves.

 > industries and vendors object to the Internet requirements of

i haven't has proposed any closed solution for this.  i proposed that we
publish the sip i-d as experimental until we find out what the popular,
widely accepted security solutions will be.

-- juha

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Feb 2002 20:34:30 +0200

> industries and vendors object to the Internet requirements of

Can we please get out of this process discussion and to the
technical stuff? I don't think Juha tried to argue that we don't
make an Internet-scale SIP standard.

The *real* question is if we have the right "key set" above!
Let's start discussing that.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 12:08:36 -0800 (PST)

> but people might have different opinions from you about utility.

   Fine. Let's have a consensus call. 

	       Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 16 Feb 2002 09:05:10 +0200

>    Fine. Let's have a consensus call. 

Well, I counted myself, Juha, Sanjoy, and Mike already supporting
my ealier priority list which concluded that S/MIME is not the highest
priority. At least Jonathan, Eric, and Jon have the opposite view so
at present the no-S/MIME group is slightly larger but we really don't
have any consensus.

But I have a compromise suggestion. Why don't we keep the S/MIME
stuff in Bis but make it a MAY, and then move on to continue to the
discussion about relative priorities of Digest, Enhanced Digest, TLS,
and IPsec?

Jari

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 08:06:59 -0800

> discussion about relative priorities of Digest, Enhanced Digest, TLS,
I don't think the issues of Digest, Enhanced Digest and S/MIME
are separable. In my view, they all serve roughly the same
purpose, except that S/MIME is rather more flexible.

The requirement here is for some form of authentication and message
integrity that survives multiple trips through proxies. The requirement
that it survive proxies produces two side effects:

1. It rules out the use of TLS or IPsec since those are inherently hbh.
2. It requires that we allow some headers to be excluded from
integrity protection so that they can be modified en route by
proxies.

Pretty much every solution to this sort of problem looks roughly
the same: a message integrity check over the headers (and maybe the
body) but with certain headers somehow excluded.

There are four primary design decisions to be made:

(I) How to exclude content from the domain of protection?

1. specifically call out certain headers to be unprotected
[this is the approach that digest takes]
2. protect everything but allow certain parts of the message
to be modified in flight. [this is the approach that Jon et
al use with S/MIME].

Approach (1) has the advantage that it's wire encoding is compact,
since changed headers don't take up space. Approach (2) requires an
audit trail to allow verification. OTOH, approach (2) allows the
recipient to determine the original values of the headers, even of
those which were allegedly excluded from verification. This allows the
recipient to apply a stricter security policy than required by the
standard, by rejecting certain modifications.

(II) What kind of keying to use?

You'll note that I haven't said anything about what kind of integrity
check to use for data origin authentication. That's because it's an
orthogonal question. The two obvious approaches are MACs based on
shared keys and digital signatures based on public keys. S/MIME supports
both (password is discussed in RFC 3211). Digest supports only shared key.

(III) Anti-replay protection and challenges.

This is the big difference between S/MIME and Digest. Digest was
conceived as a Web security mechanism and so has a method
for a server or proxy to tell the client or proxy that it would
like authentication. The authors of the S/MIME section of -bis
obviously conceived of S/MIME as something that the client would
offer, not be prompted for, so there's no comparable mechanism.
(That's certainly how S/MIME is used in the e-mail context). 
However, it would be relatively straightforward to adapt the
Digest prompting and anti-replay mechanisms to S/MIME.

(IV) Confidentiality
Once you're in the message-processing business, confidentiality
becomes an attractive proposition. S/MIME offers it. Digest does
not. (Though of course you could add it.)

Since Digest and S/MIME cover so much of the same space, I don't see
much point in having both. We need to keep Digest around for a while
for compatibility reasons but we should start to deprecate it and do
either Enhanced Digest or S/MIME but not both.  The question then
becomes which is a more suitable base to start from, S/MIME or 
some Enhanced Digest.

In my view, S/MIME is the better choice because it provides an upgrade
path. In particular, there's no extra specification effort to provide
public-key based authentication or confidentiality. You just get them
when you specify S/MIME. It would of course be possible to add these
features to Digest but it would be ugly and you'd essentially have
reinvented most of S/MIME at that point. By contrast, using
a Digest-based anti-replay and prompting mechanism with S/MIME is
easy and requires no modifications to S/MIME per se.

Accordingly, I propose we do the following.

(1) Specify S/MIME support (roughly as in bis), as XXX 
    (XXX=MUST or SHOULD. I'd prefer MUST but I could live with SHOULD).
    profiled as:
    (a) Support for password and symmetric key management as XXX.
    (b) Support for public key as MAY.
    (c) Support for confidentiality as MAY.
(2) Adapt Digest's prompting mechanism to work with S/MIME.
    Essentially this means providing a new header to say 
    'authenticate with S/MIME. Here's the anti-replay token to use'.

I understand that this will be somewhat more effort for implementors
(since S/MIME processing is a little more complicated than Digest,
but profiled down this way, I believe it's quite manageable). And
implementors who want to do more can easily do so.

I'm against proceeding with Enhanced Digest. Digest is already
pretty messy and will just get more messy if we go further down
that path.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sat, 16 Feb 2002 15:22:36 -0800 (PST)

> purpose, except that S/MIME is rather more flexible.

In fact, the way the draft is written, this is
incorrect. Digest is being used for proxy
authentication, and SMIME is being used for end to
end. However, if we weren't in a headlong rush to
cram stuff into bis, something probably could
unify all of these. As currently written, SMIME
in bis is not that something. This is why I would
like to see SMIME taken out of bis, and considered
separately.

 > becomes which is a more suitable base to start from, S/MIME or 

I certainly haven't suggested that digest should
be extended. In fact, I don't think that enhanced
digest is all that interesting, and have stated so
in the past. However, that doesn't necessarily
imply SMIME. SMIME is terribly heavy and needs a
lot more consideration than has been given thus
far. SIP needs to run in very low footprint and
very low bandwidth/lossy environments. SMIME was
clearly not designed with those constraints in
mind, and is hardly ideal. 

Indeed, the right thing here might be to do
something that makes sense for SIP rather than
relying on things which were designed for other
requirements. Given how important rendezvous
protocols are in real life, I think it's far more
important to get it right rather than just jamming
something into the spec at the last minute and
hoping that it works. As specified now, SMIME is
nothing more than warmed over PGP -- which had no
support either. This is not encouraging.

	Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 16:58:28 -0800

Michael Thomas <[email-masked]> writes:

> incorrect.
As I tried to make clear in my original message, I'm not talking about
S/MIME as it's currently wedged into SIP, which I agree could use some
work, but about S/MIME proper.

In my view, SIP needs some sort of message integrity and
confidentiality protocol. The choices on the table are invent
something new or hijack something old. I'd rather do the latter
if we can get away with it. The prime candidate there is S/MIME.

> requirements.
I don't understand what features of this new protocol you
propose to design are going to make it substantially more
lightweight than S/MIME. Do tell.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sat, 16 Feb 2002 19:48:47 -0800 (PST)

> work, but about S/MIME proper.

Well, right now that's what's in the draft which
is rapidly headed for last call. 
 
 > if we can get away with it. The prime candidate there is S/MIME.

In fact, my draft even used SMIME as an example.
For some things it may be appropriate, especially
for X.509 based things. However, dragging in SMIME
just for symmetric keying seems likely to be
overkill, and probably too heavy for people to
justify making the jump from digest.

Of course, the *real* problem here is that it was
thrown into the draft without ever researching
these considerations.

 > lightweight than S/MIME. Do tell.

Trivial. 

Requirement #1: no ASN.1

:-)

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 20:44:26 -0800

> justify making the jump from digest.
What I was trying to argue earlier was twofold:

(1) A minimal S/MIME implementation that does essentially
what digest does would be of comparable size to digest.
(2) A message security protocol that does what we'll
eventually want will be of comparable size to S/MIME.

Thus, we might as well bite the S/MIME bullet now.

>  > lightweight than S/MIME. Do tell.
I trust the smiley here means that you're not serious. The amount of
code required to implement CMS EncryptedData and AuthenticatedData 
(which is all that would be required to replace digest) is quite small.

As I understand it, you have two primary objections to S/MIME:
(1) difficulty of producing a completed specification in time.
(2) code size and complexity.

I'm sensitive to argument (1) but I don't think that the code
size and complexity argument holds up under examination.

-Ekr

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 17 Feb 2002 11:52:57 +0200

Michael Thomas writes:

 > hoping that it works.

i fully agree with this.  we should not put anything into bis that the
industry has not had time to carefully consider and form a consensus.
we can't afford a third security round.  so it is better to publish bis
now as experimental including only what is currently widely available,
i.e., digest and tls, and then keep on working on consensus for better
security solutions.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Sun, 17 Feb 2002 13:15:03 -0800 (PST)

> Thus, we might as well bite the S/MIME bullet now.

   This is *far* from clear. It does not follow
   _at all_ that SMIME is the right vehicle for
   shared keys, AAA or Kerberos. Ie, the usual
   suspects for authentication. Kerberos, for
   example, already has standard mechanisms for
   integrity/confidentiality (krb-safe/priv) and
   doesn't need extra kruft around it. Dragging
   in SMIME for simple challenge protocols is
   also equally debatable. And I'll bet that the
   people who want AAA based authentication would
   probably like to see something more EAP like
   so that it integrates with RADIUS/DIAMETER.

 > (which is all that would be required to replace digest) is quite small.

   The smiley was because I know it's not realistic.
   I'm perfectly serious that ASN.1 is a pig and to
   be avoided.

 > size and complexity argument holds up under examination.

   Yes, you keep asserting this. You're a hardware 
   designer, no?

	    Mike

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 17 Feb 2002 23:26:22 +0200

Michael Thomas writes:

 >    And I'll bet that the

yes, it is very important that the sip authentication mechanism
integrates well with eap/radius that is already used for ras, ethernet
switch and wlan authentication.

-- juha

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2002 13:49:18 -0800

>    so that it integrates with RADIUS/DIAMETER.
I think you're confusing key exchange with messaging.
The purpose of S/MIME in this context is to have a generic
messaging protocol which allows multiple key exchange
mechanisms. 

Obviously, you can save some space (though surprisingly little)
by tying your messaging protocol more tightly to your key
exchange. I consider that to be generally a mistake. In view
of your oft-voiced desire not to pick winners, I'm surprised
that you don't as well.

>    I'm perfectly serious that ASN.1 is a pig and to
I hear this a lot from people who don't really know that much
about ASN.1. It's true that generic ASN.1 engines such as
OSS are pretty piggy. However it's quite feasible to write
small targeted codecs for specific protocols. 

>    Yes, you keep asserting this. You're a hardware 
No, I'm a programmer. 

Moreover, I have extensive experience writing ASN.1 based
systems. I've worked with at least four separate ASN.1 toolkits of
various stripes, from compilers to table-driven engines and written
hand-rolled decoders numerous times. I'm quite confident I could write
an EncryptedData and AuthenticatedData codec in less than 1000 lines
of C (Actually, I expect that 500 lines is feasible.) For reference,
I'm currently looking at an X.509 engine (much more complicated than
that needed for symmetric key S/MIME) that consumes about 1500 lines
of Java.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2002 13:51:44 -0800

> switch and wlan authentication.
As far as I know, it should be possible to use S/MIME messaging
with a key established via these mechanisms.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sun, 17 Feb 2002 14:20:04 -0800 (PST)

> of your oft-voiced desire not to pick winners, I'm surprised

   Note: I'm not saying that SMIME shouldn't be 
   considered. I'm just saying that SMIME as the
   ultimate answer is not a universally shared
   sentiment, and there's a lot of ground to cover
   before there's consensus on that point.

 > small targeted codecs for specific protocols. 

   I'm well aware of that. I had to code up a BER
   parser in the late 80's for SNMP. It's still a
   pig. It takes quite a bit of effort to hand
   code ASN.1, and even then you get messes like
   MIT's Kerberos code which is not only hand
   coded, but bloated on top of it.

 > systems. 

   Well, I've had extensive experience developing
   software for embedded systems. You are grossly
   simplifying their considerations. For one
   thing, it costs lots of $$$ and time to market
   to deviate from off the shelf code. For
   another, simply saying "add more ram" belies
   the reality that for many low end products this
   far easier said than done. Moore's law
   eventually catches up, but adding transistors
   costs money and for consumer grade gear,
   pennies matter. The object of SIP is to be
   the protocol of choice for those devices. 
   Doubling (or worse) the flash/ram footprint
   is going to be a bitter pill. While I have no
   sympathy for those who would use that as an
   excuse to do nothing, I have a lot of sympathy
   for the plight of engineers trying to cram
   things designed with no consideration for
   space/money tradeoffs into miniscule amounts of
   memory.

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2002 15:08:55 -0800

Michael Thomas <[email-masked]> writes:
>    pig.> It takes quite a bit of effort to hand
How bloated things are depends on the ASN.1 you're writing to. I'm not
familiar with the SNMP ASN.1 and only vaguely familiar with the
Kerberos ASN.1, but I'm VERY familiar with the S/MIME ASN.1 and it's
perfectly possible to write a small codec for it, albeit while taking
a little care. X.509 is a different issue, but we were discussing
manual keying, so X.509 overhead isn't relevant at this moment.

>    space/money tradeoffs into miniscule amounts of
I'm sorry, but I don't see the relevance of this. Anything we
require will force the embedded guys to change something and
I'm certainly in favor of making that something as minimal as
possible, consistent with the requirements of decent security.

What's presently at issue here is the actual impact of adding
S/MIME as opposed to some non-S/MIME messaging system with
similar functionality. Your argument about the piggishness
of ASN.1 notwithstanding, my experience implementing such
systems leads me to believe that the footprint of such a system
will be roughly the same as S/MIME.

-Ekr

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 17:32:05 -0600

> (III) Anti-replay protection and challenges.
. . .
> Digest prompting and anti-replay mechanisms to S/MIME.

You know, if we added this same anti-replay mechanism to the signature I've
been proposing on RPID (possibly along with the inetgrity-protection fom
enhanced digest), we'd fix the whole RPID signing security problem!

Conversely, is it appropriate to solve the RPID problem with another S/MIME
body?

Would the S/MIME body need to be evaluated by proxies? I suspect that
parsing and evaluation of S/MIME bodies on SIP messages would by a
two-order-of-magnitude performance hit on SIP proxies, relative to a simple
header approach.

--
Dean