Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> [email protected]
>
>    From: Hadriel Kaplan <[email protected]>
>
>    Although the draft mentions a UUID as one option, it leaves the
>    mechanism to be decided.
>
> In that regard, the draft is somewhat self-contradictory.  In one
> place it mentions UUIDs and in another place, it specifies the
> Session-Id as a crypto-random quantity.  But some UUID formats contain
> the MAC address of the creator thereof, which violates the stated
> security considerations.

Correct - I noted that before on the mailing list before submitting the draft that we wouldn't use the UUID based on MAC, but rather the pseudo-random one.  But I'm not tied to it being a UUID at all whatsoever - it was just an example - it's TBD based on WG input.


>    One thing we could do instead of UUID, for example, would be to
>    make it a hash of the received call-id and local system/node ID and
>    MAC or some such.  In other words take some non-volatile system
>    data munged with the call-id, and hash it to get the 128 bits of
>    output for the Session-ID header value.  That way a stateless proxy
>    can re-generate the same value again for upstream and downstream
>    requests and responses, without it compromising or being
>    re-create-able just from the call-id value and giving a reason for
>    folks to remove it.
>
> You'll have to include in the hash a secret local key.  Otherwise an
> adversary can check a guessed correspondence between a Call-Id and a
> Session-Id.

Yup exactly - that's what I meant by not being "re-creatable", and why I included a system/node ID and MAC into the equation.  Not really a secret local key per se - and maybe I should just say that instead in the draft.

Note the "adversary" so to speak is just that a downstream node can get a Call-ID and must not be able to tell from the Call-ID it got, what the Session-ID should be, so they can't tell the Call-ID was changed by a b2bua.  Of course an upstream node would be able to tell - for example the UAC would if it received a subscribe for the dialog-event that had a session-id it created, with a call-id+tags it didn't.  But then one of the main points of this exercise is to make those cases work.  I can't guarantee that all operators would want it to work in such cases, but for those that don't want it to, nothing will help us make it work.

-hadriel
_______________________________________________
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