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