Fwd: [Ecrit] comments on draft-barnes-ecrit-auth-00

["Richard Barnes" <[e-mail]>]

---------- Forwarded message ----------
From: Richard Barnes <[e-mail]>
Date: Jul 23, 2007 10:27 AM
Subject: Re: [Ecrit] comments on draft-barnes-ecrit-auth-00
To: Jonathan Rosenberg <[e-mail]>


Jonathan,

Thanks a lot for your comments. Some responses below:

> If my understanding is correct, the primary problem being addressed here
> is dealing with malicious callers that try and send emergency calls that
> are not really emergency calls. Is that correct?

Essentially, yes.  I will add a better exposition of this problem in
the next version.

> Furthermore, I think
> the fundamental assumption you are making is that a call is considered a
> valid emergency call if its routing will cause it to arrive at a PSAP.
> Consequently, the primary threat that is being addressed here are users
> that label calls as emergency calls, in order to get some kind of
> specialized treatment, but the calls don't go to a PSAP, but rather go
> to a friend or colleague. Is that correct?

I wouldn't characterize it quite that way.  The basic assumption is
that somebody (VSPs, ISPs, etc) will want to distinguish between
emergency and non-emergency calls, based on some criterion.  The
distinguishing criterion could be the identity of either endpoint (To:
or From:), or some explicit designation by a third-party authority.
Presumably some action will be taken based on this distinction (e.g.
changes in billing), that will make it attractive to have a call
handled as an emergency call.

So the threat is that the mechanism used for distinguishing emergency
calls from non-emergency calls will be abused by non-emergency callers
to obtain special treatment.

> I'll note that this problem goes away if the VSP performs the location
> to PSAP mapping, not the UA. You might want to mention this as another
> solution.

That solution only provides assurance to the VSP that does the
mapping, not to any upstream or downstream entities.  And in any case,
a lot of the motivation for this document was the "location hiding"
use case, where there's no location in the SIP message that the VSP
can read (e.g., an access-controlled L-by-R).

> Section 2.2 - why does the identity of the caller, as asserted by the
> called party, indicate that this is an emergency call? I'd think you
> really want an assertion of role of the connected party - i.e., the 200
> OK response to a call to a PSAP has a SAML document that attests that
> this 'user' is a PSAP.

First, note that the asserter is asserting its own identity; the
called party asserts the identity of the callee, not the caller. The
identity of the called party indicates that it is an emergency call
because the identity presumably demonstrates that the called party is
a PSAP.  This is consistent with the definition of an emergency call
used in the "location+URN" case (in which case the identity is the To
AoR, and it is shown to be a PSAP via LoST).

As far as direct assertions (like SAML), that's what I was trying to
describe in section 2.3.

> The draft talks about "authenticating" emergency services calls, but
> this term is not correct here. Authentication is establishment of
> identity of the originator of a message. That is not what we are doing
> here. I think this draft is about verification that a call is an
> emergency call.

I was using the term in the sense the the mechanisms in the document
"authenticate" the emergency status of the call (vs. the call itself),
in that they demonstrate that the call is actually, authentically an
emergency call.  But it's just terminology, if people like
verification better, we can change it to that.

Thanks a lot,
--Richard

_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit