On Jul 31, 2008, at 2:14 PM, Adam Roach wrote:
On 7/31/08 1:49 PM, Dean Willis wrote:
Here's an example:
1) [EMAIL PROTECTED] calls [EMAIL PROTECTED]
2) The example.com AS authenticates Alice using a mechanism such as
proxy-authenticate, then adds an appropriate Identity and Identity-
Info header field.
3) Bob's B2BUA verifies the Identity header field
4) Bob's B2BUA checks the Identity value value against Bob's
whitelist and chooses to allow the call.
5) But Bob is out, so the B2BUA wants to forward the call to Bob's
mobile phone. But Bob's administrative policy requires recording
the call.
Since Bob's administrative policy requires recording the call,
Bob's b2bua steers the media through a recorder. This requires
either "editing the SDP" or termination of media on the SBC. in
either case, it is not reasonable to send the existing Identity
header on to Bob, since it's going to be broken.
6) Bob's B2BUA elides the previous Identity and Identity-Info and
adds a new Reasserted-Identity and Reasserted-Identity-Info header
field to the new request, adds a flag saying that the identity
being re-asserted was learned from a verified Identity header, then
sends it.
7) Bob's mobile sees the new request, knows that it trusts Bob's
B2BUA as a re-asserter, then checks its whitelist policy and finds
that it is willing to accept calls from [EMAIL PROTECTED] as long
as the assertion strength is either a direct Identity or a re-
asserted Identity based on verified Identity.
Here's the problem... if I trust a B2BUA, it doesn't necessarily
mean that I'll trust everything it trusts. If Bob's UA is going to
make an informed choice, we need it to be able to examine a chain of
custody for the identity, at the very least.
Is the stack of "verified by" parameters in history-Info adequate, or
do you want to be able to check each transitive crypto operation?
If the latter, we'd have to do something like add each pre-edit
message as a sipfrag body onto the current message. That could make
for some rather large SIP requests. Maybe a diff format could make it
better, but it is still going to get chunky.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
