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