- SIP - Session 2 (Official Notes) * Location Conveyance (James Polk) - SAML (Jeff Hodges) - New sip-saml ID - addressed list feedback - enhanced assertion example section - added references - changed order of scope and intro sections - moved use cases in appendix - Open Issues - Is this spec only for the trait-based authz reqs? - If so, only need to meet stated requrements in trait-authz-02 - would not need to met reqs of other saml based drafts - may need their own saml profiles - Should we allow proxies to add SAML assertions by value? (Currently by reference) - Discussion - Chair: We've accepted as wg item. Does it cover the right thing? - JDR - yes, sent comments to list - binding of assertion to SIP call itself may be an issue. - Author will check to make sure it is covered - Hannes Tschofenig: JDR Wants saml assertion to have identifying info to bind to SIP message, right? - JDR: Yes--for example, binding to identity is not enough if a stale assertion gets attached to a new call from same id - Wants to correlate signed data with the SIP message - JP: That's a stronger check than any of the saml constraints - Chair: Take issue to list - JDR: backwards compatibility issue referencing saml. Server does not know whether to provide a cert or a saml association - JP: sip-identity will allow other URL schema so it could reference saml association. - Take to list - - Squirrel in tree? (Jason Fischel) - sip-certs - how many people have reviewed? - lots - how many will implement - several - RJS: Almost implemented, will be at sipit - Chair: Ready for WGLC? - WGLC in a week or two. Get any comments in quickly - - hop limit diagnostics (Scott) - In body of 483, server SHOULD return the request message - Also return request for other unrecoverable errors? - Scott puts up an example list of errors - Scott thinks it might be useful - text might say that if an error does not already specify a diagnostic or recovery mechanism, it could do this - JDR: suggested this in the first place, but is not sure of the list - mainly for proxy generated errors - Need to think about which error codes this is good for. - RJS: no one objects to increase the scope - EKR: Does spec call for returning body? - Scott: no - Take to list - Is it okay to use warning header for problems other than SDP? - should a specific warning code be defined? - RJS: Don't mess with Warning. Do something with sipfrag in body. - Henning and Scott: what is objection? The tying to SDP was only because that was the use case at the time. Using warning for non SDP does not appear to break anything. - Scott: We're seeing non-SDP bodies for which Warning might apply - RJS: Need to log a bug to change text to allow warning for non-SDP - Scott: Can do this with IANA considerations to change statement in registery for warning - Hadriel Kaplan - [ notetaker overflow -- could not figure out subject] - Currently uses 399 - a system must not take automated action. Suggestions to create new code--will do so. - Should there be a limit to response size? - Response size not mentioned in 3261. Veery large responses may not make it. - Do we need a response to say my response is too big? - Proposal: Address this as a separate work item, not in this effort. - Chair: This draft will not progress until this problem is solved. - Scott: This could affect 2XX responses as well. - Dean: Possible useful things in congestion-safety draft - Nils: We could trim off via's, etc. If UAC needs them it can sip trace-route - Scott: Text says you can remove, starting with oldest (nearest UAC) first. But repeating the message does not ensure the same path. Does not solve general problem of response size. - Nils: Different path could create different error. - JDR: 3261 did not limit response size because at the time, the responses were generally the same size as the requests, so the request limit mostly limited the response. - Scott: Is that assumption still true? Probably not. - Hadriel Kaplan NAt issues - Andrew Allain: Why not consider content redirection? - Scott: we can't be sure we can reach the proxy that would have the info. - Rohan: If the response gets fragmented, we could get retransmissions that may be worse than not having the diag info in first place - JDR: Suggest a 200 byte limit for diag information. The request limit was chosen assuming that responses would not usually add more than 200 bytes to request size. - JDR: Maybe we should send a SIP request in reverse direction - Cullen as AD: This can't be WGLC'd yet because this is not yet a WG item. - some controversy over this - Chair summay: Not ready for WGLC (even when it gets chartered) - Need to say what status codes are in scope - Warning okay, need to look at fixes to 3261 and/or IANA registry - Response size issue still open, discuss on list. - [The notetaker thanks the chair for the summary, and wishes this happened more often] - - Connected Identity (John Elwell) - Open Issues - Option tag to undicate UAS support for Identity header field in mid-dialog requests - saves UPDATE tranxation after answer if the AoR is the same as To header - Yet another option tag - Will anyone really support id-change without connected-identity? - Email suggestion to make it dependent on receipt of id header - Proposal: Don't need new option tag - Proposal accepted - SIP Identity is silent on how to behave is identity if from header is not one the authenticated UAC is allowed to assert. - left to local policy - Policy may be different for mid-dialog request - Proposal: add note to this affect - Francois: Also applies to identity draft - JP: Identity draft has blanket note to this effect - Proposal to add note accepted - Should we mandate update rather than reinvite? - fewer messages - Avoids offer/answer - might be useful to do offer/answer to get signed SDP anyway - Could make 3311 mandatory to support if you support id-change tag - Hisham: what about implementations that don't do update? - Rohan: anyone who can deal with identity should be able to do update - Proposal: If you support this extention, you must support UPDATE - accepted - Should we mandate inclusion of SDP in UPDATE - would allow SDP to be signed - rjs: Only useful if you mandate signed SDP. Should call sdp in update out as something you can do, but don't require it. - Dan Wing: Agrees with Rjs--just needs a way for this to be possible - Proposal: Allow this if you wish, but do not require. - accepted - - Should To header in response be allowed to differ from request - This is different than allowing From header URI to change in mid-dialog requests - No warning in 3261 that this could ocur. - Some people say it's not useful - Some people says it doesn't hurt - related to TIPSPAN connected identity draft, which assumes the allowing of two identities for different purposes. TISPAN expects to be able to change To header URI in response - - TISPAN does not provide authentication of changed To - connected-identity could solve this - TISPAN issue in tispan-connected-identity editor had trouble following presentation--is the TISPAN issue a sub--part of the To header change issue? Or a separate one? Or vice versa? - RJS: TISPAN does not get to change what the identity semantics mean without going through sipchange process. The P-AID has well defined values, and TISPAN is trying to change that. - Keith: Does not redefine P-AID--just says what will be put in P-AID - JDR: If each group redefines how identities are interpreted, nothing will interoperate - Keith: TISPAN is just saying that the From header says who the caller thinks he is, P-AID is who the network things he is. TISPAN thinks the different is useful. - Hisham: Both identities are for same user - JDR: Still, TISPAN is trying to say the p-aid is billing id. That adds semantics - John: PSTN does not know the difference, only that P-AID is an authenticated ID - Andrew: P-AID must contain a _reachable_ AOR. - Dean: Clarification example to describe the issue with a P-AID without a routeable AoR. - Hadriel Kaplan: P-Asserted-ID has lost focus on what it means. Is being used by enterprises. Hard to know which one to trust. - Dean as chair: This may be a bigger problem that could not be addressed in this draft. - Cullen: This may imply we need a billing ID. Could the 3gpp charging related headers be used? There are real interop issues here on what to use for callback number and caller-id presentation. May need discussion with liaison. May need to spec a real charging vector. - Brian: Agrees with that p-asserted ID doesn't work as a charging vector. - Brian: There are situations where this make sense when you _want_ to change the callback number. - Martin Dolly: 3 problems: who to bill, who to call back, what sort of subcategory of user is the caller a part of. - Dean: Should john fall back and specificy requirements around this in tispan-connected-identity - Discussion that this issue does not have to be solved in connected-identity draft. - Conclusion: Do not try to solve this in connected-identity, may rethink requirements in tispan-connected-idienty - Editorial question: Do we need correct calues for identity header field, along with a real private key, etc. (as in identity) - Cullen as individual: It really helps, and he will be willing to supply some. - Security Call Flows (Robert Sparks) - Issues - Rules are not adequately captured - identity tries to clarify - This draft tries to capture cert matching rules for the general SIP with s/mime for TLS cases. - JP: Wants to fall back to RFC 2818 rules, except it is informational. Working out how to reference it. But it has correct guidance. - work out examples, submit for WGLC - Fork Amplification Fix (Robert Sparks) - Suggestions - Don't start loop detection until you've gone around at least once. - optimized behavior in normal case - requres extra logic - Proposal to not change this - accepted - - Why are some things requred in computed hash? - call id - route values - to tag, from tag - why proxy require, proxy auith - Current text leaves this out. Propose to leave it out unless we can figure out why it was there. - JDR: Thinks there was a reason, but can't remember why. - Maybe proxy-require - RJS: Normatively says anything you are using to compute route goes in the hash--would cover this case. - Conclusion: Will leave out unless something comes up in lists. Send specific issue to list. - - Feature Creeps (Robert Sparks) - advancing the standard - Want to avoid exponential explosion of must/should/may features - Tools - global.sipit.net - generally acceptable wiki for inter-SIPit interop issues - brainstorm featureson global.sipit.net - initial draft at San Diego - Not as important as finishing other work - Henning: Progression effort may not make sense after newtrack discussion. - RJS: Other things motivate this work as well. - Henning: Need to make strategic decision on whether a bug-fix doc should become a 3261bis effort. - RJS: One motivation is to determine what was stable and what was still rough - JDR: Useful for feature compliance statements. - Hitchhiker's guide (JDR) - removed sip family discussion - Changed list of documents in scope, include MIME and SDP - redefined core specs as things used for every caller, registration, etc - [42] references real Hitchhiker's guide - Added references to towel - When is this done? - a) Split out core to close now, rest of it later - b) keep as one doc, pick a point where we issue and revise later (snapshop releases) - Suggest b) - Jeff Hodges - LDAP world has a roadmap doc, waited for all parts to RFC before finishing doc. Did a revision that updated all docs and roadmap together. - Smaller doc set. - Sohel Kahn - wants to have more formal name. - JDR disagrees - Propose accept B, verify on list. - Needs feedback on if something is missing - SIPS URI Guidlines - Will be discussed in ad-hoc - Chair: Will we do these guidelines in SIP? - SIPS and TLS guidelines - Explain what we already have, not normative changes. (which would progress separately) - JP: Concurs, do it here. - Paul K: Thinks we will discover we have normative work to do (not part of this draft.) - Francios Audet: Third revision based on list discussion. Does not think we can fix this without normative fixes. Does not believe anyone has succesffully limited SIPS. - Keith: Look at fixes afterwards - No objections to proceeding with an informative document. Will ask for AD charter. - - Meeting Complete at 1505