I would suggest the problem is not the making of the new assertion.
The issue is the removal of the assertion that some other entity made,
that may be equally valid.
Note that this may particularly be an issue in emergency calls, where
PSAPs object to the removal of any information about the user (correct
or incorrect), and in some countries, they may want to believe the
asserter in the trust domain before they believe the user and his
certificate server owner.
Regards
Keith
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 18 October 2006 14:09
To: shida at ntt-at.com
Cc: Cullen Jennings; SIP; Elwell,John; Jon Peterson; Dan Wing
Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
draft-ietf-sip-connecte d-id entity-01 comments)
Shida Schubert wrote:
Although using P-A-ID may look like a good approach for
this, I don't
know if it's really a good idea as it seems to change the
semantics of
P-A-ID.
I don't think this *is* changing the semantics of P-A-ID.
The semantics are very simple: something in the trust domain
determines the identity of the message and inserts to header
for the benefit of others in the trust domain. The entity
doing the assertion has full latitude about how it determines
the identity it asserts.
What this is doing is providing a new way to make that determination.
The new way may not be appropriate in all environments, and
that's fine.
Also, it may generates some issues when P-A-ID already
exists in the
message along with connected-identity.
That part needs to be clarified.
Following illustrates potential problems.
connected-id(FROM): carol at b.com
P-A-ID: carol at b.com
Now, following the proposal by John when Case 2 is deployed, and
assuming the verification of identity failed, it will still forward
the message as it is if we allow Case 2.
I guess here you are assuming:
- the P-A-ID was present before the verifier got the message
- the verifier leaves it in the message when verification fails
These are assumptions about the interaction of preexisting
P-A-ID and connected identity verification. There is an issue
there, but there are other possible answers to it.
When UAS receives the request
it will see both the identity-info/header and P-A-ID with the value
equivalent to the value in the FROM header.. If UAS has no
ability to
verify the signature itself, it will assume that the verification
worked. P-A-ID looks like a good place to indicate the
success of the
verification but it might need something else.
IMO the presence of the P-A-ID is not evidence that the
verification worked. It is merely in indication that someone
in the trust domain asserted this identity. It could be
because the verification of the Identity worked, or because
some other kind of authentication worked, or it could be
because some bogus party within the trust domain lied.
If you choose to trust the P-A-ID, it means you choose to
believe in the trust model. Nothing more.
As for Cullen's comments. I agree with Paul here, if the security
policy at the verification side would allow request without
identity,
it should forward the request even if the verification fails.
Lastly, if P-A-ID value is used in some context, changing the value
may cause some problem as well(Assuming P-A-ID was there but a
different value from FROM value > verifier after
verification succeeds
change the P-A-ID value to that of FROM).
Regards
Shida
Paul Kyzivat wrote:
Cullen Jennings wrote:
I'm generally on board with things like you are
suggesting below and
what is suggested in draft-rosenberg-sip-identity-coexistence.
However, I want to think very carefully about the security
properties of not rejecting things that failed based on security
properties - I'm not sure what I think of this yet.
Any time you allow a security action that failed to
continue sending
the request downstream, you run the risk that something
further down
stream assumes that the security action worked because it
must have
happened upstream. Clearly from a security point of view
it would be
better not to have upstream elements do the security
validation for
a downstream element but we did decide long ago that when doing
Identity we were going to allow for this so that we could migrate
from UAs that do not support Identity to system that does.
So let me flip this around the other way and ask - do we
really need
to allow for a request that failed verification to not
result in an
error?
I think the poster child for this is when the error is 437
Unsupported Certificate.
In this case the caller may be trapped. It has an identity
service it
can't control, that unconditionally adds an identity. And then the
callee has an authentication verifier in front of it. As things
stand, that verifier is required to reject requests with certs it
doesn't understand, even in cases where it will permit
requests with
no identity at all.
Paul
Are there use cases where the verification would fail and
we really
do want to continue with the message? If these cases would only
happen in a fairly broken system, then it might not be worth the
security problems they would cause. I don't know what I
think but I
am interested in where we might need this and if there might be
other ways to skin the cat in those situations.
Cullen
On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote:
John,
What you outline below is exactly what I had in mind.
Paul
Elwell, John wrote:
Paul,
Dan Wing made a suggestion that P-Asserted-Identity
would fulfil
your requirement. I guess it would work like this.
A Verifier not located at the UAS would attempt to verify the
signature in the Identity header field.
- Case A - verification succeeds. The Verifier inserts into the
forwarded request a P-Asserted-Identity header field containing
the verified URI (from the From header field) in the forwarded
request. The Identity and Identity-Info header fields
will still
be present and available should another verifier be encountered
downstream.
- Case B - verification fails but request not rejected. The
verifier is unable to verify (e.g., because it can't
dereference
the URL) but according to policy does not reject the
request. It
simply forwards the request as is.
If there is a further verifier downstream, that too can
attempt to
verify the signature.
- Case C - verification fails but request is rejected. The
verifier is unable to verify (e.g., bad signature) and
according
to policy it rejects the request.
A UAS that does not contain a verifier can simply use
P-Asserted-Identity, if present.
This seems to have some synergy with
draft-rosenberg-sip-identity-coexistence. In fact the
relaxation
of rules concerning rejection by a verifier that is unable to
verify a signature might be beneficial to that proposal.
I will omit discussion of the mechanics of
documentation until I
see what reaction there is to the technical proposal.
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: 09 October
2006 13:54
To: Elwell, John
Cc: Cullen Jennings; Jon Peterson; SIP
Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
draft-ietf-si p-connecte d-id entity-01 comments)
Elwell, John wrote:
Paul,
Your message arrived just after I had submitted 02, so your
comments are not
taken into account in that version. However, I felt it was
useful to get 02
out as a baseline for further discussion.
Sure. I too am interested in seeing other inputs on
this subject.
It seems the remaining issue is whether to add an explicit
indication of
removal of the Identity header field by a verifier that has
been unable to
verify the signature. Whilst this may make sense, I am
concerned it starts
to go beyond the scope of connected-identity, so I would like
other opinions, especially from the chairs and from
the authors
of Identity.
Rather than adding something to indicate that identity has been
*removed* due to failure to verify, I am advocating adding
something to indicate that verification has *succeeded*, while
leaving the identity header in place. In this way, a
downstream
element may *either* trust the info added by the
verifier or do
its own verification of the identity header.
Of course this is only significant if the verifier is
doing work
for downstream elements, and not for itself.
Paul
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent:
05 October
2006 16:29
To: Elwell, John
Cc: Cullen Jennings; Jon Peterson; SIP
Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
draft-ietf-si p-connecte d-id entity-01 comments)
Elwell, John wrote:
Paul,
So your proposal is that the connected-identity RFC should
update RFC 4474
to somehow relax rules at a verifier. Correct?
Yeah, I think so.
So the next question concerns the way in which these
rules should be
relaxed. One problem with the verifier not being located at
the UAS but at
some proxy is that the UAS might be configured always to
trust identities
received in requests via the verifier's proxy if an
Identity header field is
present, on the assumption that the signature has been
checked by the
verifier. Therefore it sounds like the verifier, if it does
not reject a
request with a bad signature, should remove the Identity
header field (and
also Identity-Info) before forwarding the request towards
the target.
(I think I have seen someone propose combining the use of
Identity and P-Asserted-Identity, though I don't recall the
details, or which draft it was. So what I am about
to say might
bear no
relationship to that.)
I could see how Identity might be used between trust
domains, while
P-Asserted-Identity is used within a trust domain. In that
case, a verifier might run at the entry point to a
trust domain
and if verification succeeds, insert a P-Asserted-Identity
header with a corresponding identity. It then might,
or might
not, remove the Identity header. Recipients within the trust
domain could then use P-Asserted-Identity as the source of
identity info. (In this scenario, an identity header
would only
be added to requests when they leave the trust domain.)
In this kind of environment, it is only necessary for the
verifier to
omit the P-Asserted-Identity header when verification fails.
Under what conditions should a verifier remove an Identity
header field
rather than rejecting with 436/437/438? My inclination
would be to leave it
as a matter of policy as far as the update to RFC 4474 is
concerned, and
then make more precise statements concerning
mid-dialog requests.
Alternatively the update to RFC 4474 could just relax the
rules for
mid-dialog requests. I think there is some merit in
relaxing the rules in
general, because otherwise there might be situations where
a legitimate
caller cannot establish a call because an Authentication
Service (outside
the UAC's control) is inserting an unverifiable signature
(e.g., in
Identity-Info placing a URL that the Verifier cannot
dereference for some
reason).
What you say sounds reasonable to me.
There is however some risk to having a verifier remove
identity. The
problem would be when there are potentially multiple
verifiers that
don't trust one another. If an early one removes the
header, then it
prevents a subsequent verifier from doing its own
verification.
This could come up if a request transits a domain on
the way to
another domain. Each domain may wish to do its own
verification.
That is an advantage to having the verifier add something to
the request to indicate the result of its verification.
One consequence of the Verifier being separated from the
UAS is that we
don't want to rely on stateful behaviour at the Verifier or
its proxy (for
similar reasons that you cited for the Authentication
Service earlier). So
for mid-dialog requests we would need to mandate, or at
least recommend,
that 436/437/438 should not be sent.
Right.
Paul
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: 03
October 2006 01:44
To: Elwell, John
Cc: Cullen Jennings; Jon Peterson; SIP
Subject: Re: [Sip] RE: Rejecting connected
identity (was RE:
draft-ietf-sip-connecte d-id entity-01 comments)
Elwell, John wrote:
Thinking further on this, perhaps there is a 4th way:
4. Specify that if a UAS rejects a mid-dialog request with
436, 437 or 438,
then it MUST NOT invoke the verifier for a subsequent
request
This assumes that the verifier is invoked by the UAS, and
not by some
proxy in front of the UAS. Isn't it valid to have
a verifier
in a proxy before the UAS? This rule would forbid that,
because it would cause that proxy to be call stateful.
I think it would just be better to update the RFC, even
though that is a bit more trouble than not to.
Paul
on the same
dialog unless the From header field URI has
changed, and in
such cases
SHOULD NOT make use of the unverified connected-identity.
Then a UAC, on
receiving 436, 437 or 438, MUST repeat the request once.
This would allow
business as usual on this dialog (but without the benefit
of connected
identity, therefore no worse than at present). It avoids
any change to RFC
4474, because verification is optional anyway.
Would this work?
John
-----Original Message-----
From: Elwell, John Sent: 26 September 2006 21:02
To: Cullen Jennings; Jon Peterson
Cc: SIP; Paul Kyzivat
Subject: FW: Rejecting connected identity (was RE:
draft-ietf-sip-connected-id entity-01 comments)
Cullen, Jon,
In case you missed this (it wasn't addressed directly to
you), I would greatly appreciate an opinion from each of
you on this remaining issue in
connected-identity. Just to
summarise, RFC 4474 leaves it up to policy whether to
return a 428 response if Identity is missing,
but mandates
the sending of a 436, 437 or 438 response for certain
errors arising while verifying the signature. It
seems that
for mid dialog requests this behaviour could be harmful.
What does the UAC for the mid dialog request do if it
receives 436,
437 or 438? If the mid-dialog request was solely for the
purpose of connected identity, it can give up
and allow the
call to continue as is. But if the request was for some
other purpose (e.g., renegotiating the session
because of
hold, say, or session timer refresh), the UAC
really wants
it to work. For the normal case where the Authentication
Service is at a proxy, not at the UAC, the UAC
cannot force
the Authentication Service to refrain from putting this
unverifiable signature in the mid-dialog request, so any
attempts to repeat the request would most likely
be doomed
to getting the same response.
It seems there are three things we could do, none very
attractive:
1. Get connected-identity to modify the procedures of RFC
4474 for a verifier by softening the requirements for
sending 436, 437 and 438 in response to
mid-dialog requests.
But then a mid-dialog request from a rogue
source would be
accepted.
2. Say that the Authentication Service should omit the
signing of mid-dialog requests if a previous attempt has
resulted in 436, 437 or 438. But this implies
statefulness
at the AS.
3. Accept the fact the mid-dialog requests can
fail in this
way and therefore things like session refresh
and session
renegotiation cannot be done, probably resulting in call
failure. Sounds bad, but it is no different from
an initial
INVITE request, where there is nothing the UAC can do if
the AS inserts an Identity header that gets
rejected with
436,
437 or 438.
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: 22
September 2006 19:26
To: Elwell, John
Cc: Cullen Jennings; SIP
Subject: Re: Rejecting connected identity (was RE:
draft-ietf-sip-connected-id entity-01 comments)
John,
I want to hear what others, especially Jon and Cullen,
have to say about this.
It is of some concern to me that a call might fail
because of some
problem with the identity mechanism when the same call
might have
succeeded in the absence of any identity.
But possibly the solution to this is policy in the
implementation of the verifier. What to do in
the case of
the conditions that
lead to these
errors could be configurable in the verifier: either to
generate the
error or simply to remove the identity info from the
message. And the
policy could conceivably vary based on
attributes of the
message, such as whether it is in-dialog or not.
Does it require a change to 4474 to permit that kind
of policy?
It would be annoying if the end user had no
control over
the insertion and verification of identity, and it
resulted in calls failing that the user would like to
permit. But I suppose that is itself
a policy
decision. There are certainly enterprises that want to
exert that kind of control over what users are
permitted
to do.
Paul
Elwell, John wrote:
Paul,
I agree with most of your points, and on reflection I
think
I agree that the
solution has to be with the verifier.
I think RFC 4474 is not a problem as far as
sending a 428
'Use Identity
Header' response is concerned, because that is left to
policy, so we could
say in connected-identity that policy should be to not
send 428.
However, 436, 437 and 438 responses are all a problem,
because RFC 4474 says
that they MUST be sent under respective conditions.
Interestingly, though,
there are other failure scenarios that can
arise from the
procedures of
section 6 of RFC 4474 for which no normative
statement is
given on how to
respond, e.g. invalid Date header field, signer not
authoritative for the
domain.
So one way to solve the present problem would
be for the
connected-identity
draft to modify verifier behaviour in RFC 4474 in the
case
of mid-dialog
requests. I guess this would mean that it would update
RFC
4474 as well as
updating RFC 3261. But I don't like this, because it
seems
to remove some of
the security properties of RFC 4474.
Another way would be to accept that 436, 437 and 438
responses will be sent,
and failure to verify a signature will
therefore result
in
inability to
process the UPDATE or re-INVITE request, and
hence if the
UPDATE or
re-INVITE request was for some other purpose such as
session timer refresh
or modifying the session, that action will
fail. Then the
call will fail (in
the case of inability to refresh the session timer) or
the session
modification will fail. I guess this is somewhat
analogous
to caller ID
verification failure in an INVITE request - it is
impossible to establish a
call if verification fails. Moreover, the UAC has no
ability to rectify the
situation, since it is at the mercy of a proxy-based
Authentication Service
that puts a rogue Identity header field in
every request.
In the connected
identity case, the only difference is that the call is
already established
but is likely to fail if verification fails.
Of course, if the mid-dialog request is indeed from the
wrong source, then
sending a 436, 437 or 438 response is indeed
the correct
thing to do, and
overriding the verification procedures of RFC
4474 would
indeed be the wrong
thing to do. So perhaps we just have to accept
that these
response codes can
be received and will lead to failure.
So, my preferred way forward is simply to recommend not
sending a 428 and
accept the consequences of other responses that the
verifier might send.
John
-----Original Message-----
From: Paul Kyzivat
[mailto:pkyzivat at cisco.com] Sent: 22
September 2006 15:13
To: Elwell, John
Cc: Cullen Jennings; SIP
Subject: Re: [Sip] RE:
draft-ietf-sip-connected-identity-01 comments
Elwell, John wrote:
From: Cullen Jennings
[mailto:fluffy at cisco.com] When
an Update is sent. Are there any conditions
under which
it might be rejected. Bad identity for example. I
think that
might need a
little discussion and also what the UA does when it
sends
an update
with a no identity and it gets rejected.
[JRE] A very good point. We don't want to get to a
situation where it is
impossible to perform a mid-dialog request (e.g., for
purposes such as
session timer refresh or session re-negotiation) just
because connected
identity fails.
My proposed fix is as follows:
1. Say that a UAS SHOULD NOT reject a mid-dialog
request
with 428 'Use
Identity Header'.
I'm not sure about this. At the least I think this
one needs
some clear explanation of the SHOULD NOT - about the
conditions when
it can be
violated.
I see this as somewhat analogous to doing a digest
challenge on an
in-dialog request. In some cases it is the right
thing to do.
A UA that imposes such a requirement will be
limited in what
it can do, but that may still be right in some cases.
2. Say that an Authentication Service MUST NOT add an
Identity header field
to a mid-dialog request if a previous request on that
dialog has resulted in
436 'Bad Identity-Info', 437 'Unsupported
Certificate'
or
438 'Invalid
Identity Header'.
This requirement would force the
authentication service
to
be dialog
stateful, which is not ideal. Better to push the state
back into the
sender of the request. This may require a way for the
UAC
to tell the
authentication service not to act.
3. Say that a UAC MUST repeat a mid-dialog
request that
results in one of
these responses if the mid-dialog request was not
solely
for the purpose of
connected identity. If solely for the purpose of
connected
identity there is
no point in repeating it, so I will say "SHOULD NOT
take
any further
action".
This seems wrong to me.
I think that the remedy to these is in the
verifier. The
purpose of the verifier is ultimately to drive an
authorization
decision. If
authorization would succeed in the absence of the
identity, then the
request should be permitted to continue as if the
identity was not present.
Unfortunately this would seem to require a revision to
4474 even though the paint is hardly dry on it.
If this is done, then there is no need of a
mechanism to
cause the
authentication service *not* to authenticate.
If this is
*not* done,
then that need remains, which will still require a
change to 4474.
Paul
_______________________________________________
Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP
Protocol Use sip-implementors at cs.columbia.edu for
questions on
current sip
Use sipping at ietf.org for new developments on the
application of sip
_______________________________________________
Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on
current sip
Use sipping at ietf.org for new developments on the
application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip