SIP session 2, IETF 53, March 20, 2002, 1 p.M.

Notes by Renee Cohen

NEW SPEAKER: Please sign the blue sheet today if you didn't sign it in the first session. May we have a volunteer for notes. Someone volunteer to take notes, please. Who shall be our victim?
One more time for a volunteer, before we point.
NEW SPEAKER: There's our victim. You didn't object fast enough, Collin, you're it.
NEW SPEAKER: Let's see.
NEW SPEAKER: All right. There is our agenda, does anybody have any problems? Speak now.
NEW SPEAKER: Please note, we have a small modification. We've added a second discussion area on digest for the aka digest enhancements and somebody will be talking about that. Also a few minutes for a path discussion down at the end of the list.
James.
NEW SPEAKER: This is just going to be a quick run through of the improvement to digest based authentication, because we've gotten the draft.
In the current version of SIP RFC 26 17 that we've got today, we have U A C to U A S authentication and U A C to proxy authentication. Our draft now adds proxy to U A S, bid down protection, integrity protection for the message, mutual authentication where both parties can check, the other one is who they say they are. And a suggested mechanism for re play action.
To cope with the proxy to U A S authentication, what we've done is add three new headers, and one new response. We've got the U A S authenticate, which is the challenge equivalent of the authenticate messages that you have for both normal and proxy authenticate. Authorization, which is again, similar to the authorization headers. And U A S authentication info.
In order for all of this to go back to the XT's that you wish to authenticate, we've got a new header, 49 two, which is put there so that you can, s just go, it's send the challenges backwards, and if you have a U A S that's aware of the draft, it will then re issue the request, propagating the U A S authenticate patterns forward to the relevant vent entities.
In bid down protection, what we wanted was a mechanism where you can issue whatever challenges you like and be assured that somebody in the middle isn't going to take out the stronger challenges, only leaving the weaker challenges, which then means that they can attack the messages as they continue. This has been achieved by adding prefixes to the moans, these are just, they're both required, in order to crate the hashes, the attack err in the middle can't multiply them unless they can physically attack the hashing algorithm that you use.
And you also know, again, N O N C E S are going to come back so you can see exactly when you offered them.
This is being extended to extend to protect the something and not the algorithm which I'll explain later. We've also added mutual authentication, this has been by multiplying the authentication in flow headers to make them non digest specific. In RFC 26 17 it's always assumed that you're going to be using digest when you get to the authentication header or proxy authentication info header. I believe this is a serious limitation, so, we've attempted to correct it in this draft.
On the subject of integrity, we provided two additional methods to go with ones that are in RFC 26 17. We have a complete one hop message where the entire message is protected by that, the hashing digest. And also, in negotiated is header integrity method where the headers that are going to be included in the hash can be negotiated. This contains bid down protection, in that, it's when the person issuing the challenge provides it, and the person responding toll challenge that then responds, they have to include there that the super set of the headers that they were challenged with. So if they decide that it's not enough headers were being protected, they can increase the number of headers being protected but not decrease them.
Now, onto the problems that exist with this draft and the authentication framework in general. We're unable to provide algorithm protection. By that I mean, if the hashing algorithm that's used for protecting your messages is broken, we don't have a mechanism for revoking use of that, use of that algorithm, and the proposal that I make is that, to express that, is a known limitation, and rule that algorithm replication is out of scope, because it's physically prepared to accept or issue challenges containing a broken algorithm, then a Hacker or an attack err in the middle is always free to use that to obtain that credentials.
Another issue that's been raised on the list recently, is that there's no negotiation of body integrity protection. Due to the fact that the proxies can't alter message bodies. I would suggest that that was left unchanged and that you always have body integrity protection.
Another issue that's come up on the list recently, has been if you use weak pass words or session keys, for protecting the integrity, people can break the pass words, break the session keys and they have free access to it. I believe that if you pick a weak password or someone introduces a scheme that allows weak, or that uses weak session keys, then that's a limitation that we can't cover in this draft.
Another issue that's cropped up is that the proposed 49 2 mechanism requires U A C support in order to reflect the challenges back to proxies, so they can authenticate themselves with the U A S. So, I contend the U A S already made a policy decision saying that it's potentially going to reject a message based on lack of authentication, that this really isn't an issue and that note it as a deficiency but leave it unchanged.
NEW SPEAKER: Question, do you want to take questions now or --
NEW SPEAKER: I'll take questions now.
NEW SPEAKER: I'm curious if the mechanism that we had come up, where, the forwards direction service, unanimous, saying, I can't authenticate myself now, do with me what you want, so that in a sense, that if you can authenticate, you get it. If you can't, you at least, you can decide what you want to do after that, fail or whatever. Is that making sense in this context? I'm not sure --
NEW SPEAKER: I think that that might also relate to this slide, where you client server can't initiate --
NEW SPEAKER: No. If the U A S challenges from the previous proxy.
NEW SPEAKER: It's othogonal.
NEW SPEAKER:
NEW SPEAKER: I'm sorry?
NEW SPEAKER: I think that mechanism makes a lot of sense, but it's othogonal to the mechanism that you would use to challenge it.
NEW SPEAKER: Sure.
NEW SPEAKER: Whether you do this reflection, you know, thing off the U A C, it makes sense for sure. I did have a comment on that, again, I guess it's, you want to do these one at a time or run through all of them?
NEW SPEAKER: I don't mind comment now.
NEW SPEAKER: From a mechanism perspective, I thought I had suggested this and maybe I did it in the list, but a better way to do this is to target a proxy, is to, we have a line in the spec that's often ignored but important for this one, if a proxy gets a response for which there are no more response it for it, if a user agent server wants to challenge a proxy two down, it would take all but the top two headers and rip them out of the response. And then send the response, what is it 4 '93 or something. Back, and it would go back two proxies and that would run out of headers and know that response was for it. And then using a different transaction I D it would be able to re initiate the request as a pseudo request approach, and that would serve more closely emulate how it works in the forward direction. The bouncing off the client thing, it makes me a little nervous.

NEW SPEAKER: I think this one is more discussed. And it involves a third party, that John had pointed this out to me, a third party, that involves to properly help you authenticate, because you have to know that it's going to bounce the request back forward, what if it decides it doesn't like you and doesn't want you to authenticate its proxy or something?
NEW SPEAKER:
NEW SPEAKER: Well, if it doesn't like you, it won't know what to call you.
NEW SPEAKER: I suppose. but just from my latency message count perspective, in what way is that worse than the via stripping thing? That seems to be a simpler approach, lesser of two evils.
NEW SPEAKER: Well, the, I haven't actually seen the via stripping idea, but I'd also like to see how it run in a SIPPING test.
NEW SPEAKER: Yes. Well, you need the proxy support for the first place, and you know, it's got to know that it's got to answer a challenge. So that doesn't change. So I don't actually see how this introduces any inter op issues.
NEW SPEAKER: Fair point.
NEW SPEAKER: Did I miss something in the draft? Or is there some, is there no way for the client to tell the, say the U A S for the proxy, to make sure it's authenticate. I see how the proxy tells the client, listen, I want you to authenticate, but what controls mutual authentication for client only? I see it, fair enough.
NEW SPEAKER: The backwards direction of the proxy server behind you, with U A S, what's the motivation, I guess? What are you trying to accomplish by authenticating that guy? Or what about it exactly, do you want to trust or, can you, is there, I forget if there's a section in the draft. Are you holding a conference for that?
NEW SPEAKER: I think that this is just that, you might not, you might not trust, you might not, or you might trust the proxy, but you might not necessarily trust the mechanism of the link between the proxy and yourself. If you've got something like the radio interface, then it's going to be a lot easier for people to interject messages.
NEW SPEAKER: Okay. Okay. I mean, so, just for the integrity portion rather than authentication portion? Because I mean, authenticating, I guess that's my question, what's the motivation for authentication?
NEW SPEAKER: Well, the authentication and integrity are closely linked, because an attack err can provide the message, and then the integrity is correct, because that was the message that the attack put on and you've just got a simple chat. And without the authentication, the integrity is a bit pointless.
NEW SPEAKER: John, imagine that I have a service running that screens incoming callers.
NEW SPEAKER: I'll sit down.
NEW SPEAKER: And basically, saying what you're going to say.
NEW SPEAKER: Between incoming callers and I want to make sure you're on my less before I ring my phone. And you know I'm running this service, so you want to spoof it to make it look like all the via headers you forge and send it directly to my phone. That's something that I don't want happening.
NEW SPEAKER: Is that what's in the draft?
NEW SPEAKER: I don't believe there is any motivation in the draft.
NEW SPEAKER: So, I think we need to really think about whether this is, it seems like this is something which is trivially solved by I T S as well and I don't have an objection to alternate ways, but we should be able to understand under which-z we would not want to use that particular approach.
NEW SPEAKER: Well, of course, the problem with T L S is that you always trust things, like the last op, but potentially with this mechanism, if your screening service was running on something that was another step away, you've still got that check.
NEW SPEAKER: How would you know that, actually?
NEW SPEAKER: Well, that's why the person who mentioned --
NEW SPEAKER: Talk into the Mike.
NEW SPEAKER: Yes.
NEW SPEAKER: Okay. I'll point out the problem. This is a flaw in the approach that I just mentioned, which was that you don't necessarily know which proxy you're trying to authenticate. You only know sort of the provider and you don't know whether the one right in front of you or two in front of you was the one who actually provided the service and you just want to authenticate that it came from this realm. But that makes me kind of queasy, I don't know.
NEW SPEAKER: There's a solution to this in the draft, that using the 49 2 mechanism, you can actually target, a from get domain. So if you've got the domain of your service provider, that's doing the filtering, you don't need to know which particular by it was then. You just direct them and you know someone along the chain is, you've got to warn that back of them.
NEW SPEAKER: There may be away to combine the two approaches to get the best of both.
NEW SPEAKER: I would like to just run through this slide quickly. But another deficiency we've got is that the client side can't initiate authentication. That the mechanisms are being looked at to provide this. They are quite awkward. In that if you included an authentication header, or an authorization header or some new header, you're going to have to rely on the thing responding in the way that you want and you can't generally respond to responses which means that, for some things like an invite, you could immediately tear down the dialogue. But you can't respond to the result of a notify for instance.
This combined with things like if you made just a require option, you're not requiring it at all hops along the path, you're only requiring it at a specific place. So using the require option is a bad idea.
There's then also problems that you'd have with the response collation which makes me think it's a specific limitation of this proposal.
My final slide is related to that, when it's whenever we have mechanisms that involve forking, and the response collation, these are obviously designed to make calls success as quickly as possible, but not designed to support authentication. Which means that whenever you get a user agent list prepared to respond with, with a 200, it's, you're always going to see that, rather than the authentication which would be seen as a failure.
NEW SPEAKER: RF P thing in the middle of the network.
NEW SPEAKER: Yes.
NEW SPEAKER: Encrypt graphic comment, you mentioned weak pass words. One problem is, there are no strong pass words, due to the nature of language and print able symbols. So you are very unlikely to create a password so long that it will have enough something, in other words, even if the exact word you chose for the password is not in the dictionary, if it's still usable if it's still crack able. It's still crack able. The point I'm trying to make is, this issue should be addressed. Bus pass words will be weak and rely upon a real random long bit key, is not always an option.
NEW SPEAKER: So you're saying, damned if we do, damned if we don't, but we need to solve it?
NEW SPEAKER: I'm saying that you cannot just say, well, if we choose a weak password, it's your problem. There are techniques of dealing with it. And I suggest they be employed.
NEW SPEAKER: I would like to visit that point. A person should not digest when we write codes for consumption in the mass market, is that digest, something is not compatible, because of that problem. If we use digest at all, it should be combined with a strong identification of the sell requesting a digest. If you don't do that, there's a classic --
NEW SPEAKER: That's what we have. That's the only thing we actually have today.
NEW SPEAKER: No, you don't.
NEW SPEAKER: Digest over T L S.?
NEW SPEAKER: No, that's not what you have. What you have today is that, you can have, digest requested by an arbitrary third party at the end.
NEW SPEAKER: That's true.
NEW SPEAKER: And it goes all the way to your client. That's one of the reasons why you should not do basic at all, that's for sure. Okay. Because if you do basic at all, it's a class of attack, in which a caller on the other hand, I mean, click here to speak to this live, or whatever. And it sends you back the request and runs your password.
NEW SPEAKER: We should be somewhat --
NEW SPEAKER: Okay.
(Several people talking.)
NEW SPEAKER: That's the reason you don't use basic, but the same reason goes for duplicating digest, unless you have strong identification of the server, in the message requesting the digest.
NEW SPEAKER: When people talk about password here, I wouldn't imagine, in most cases, the same cases, it is a human generated thing. It's effectively a random bit string. So it's, because it's not usually typed in. It's, or it can be a random bid string. Again, when, when there's any password that you have, it can always be derived from a password and that may or may not be a good idea.
But here, in the digest, nothing says this that is something about typing in the spouse's name. It's much more than a typical web type environment. It's likely to be invisible to the user. In the sense it's assigned randomly. And as long as you're doing it randomly --
NEW SPEAKER:
(Several people talking.)
NEW SPEAKER: Okay. Are we going to close any of these today? If not, let's take further discussion on to the mailing list.
NEW SPEAKER: Okay.
NEW SPEAKER: I think Mr. Somebody to have his time. He's been patiently waiting, so I want him to talk. But I think this has been hanging on for an extremely long time, with lots of list discussion, and I'd like to figure out whether we are or not going to extend digest, and make it more useful, or we're going to not play around with it anymore and do other things. Let's decide.
Three
NEW SPEAKER: Three things, actually, because I listened to people. The password issue is, in the case of digest, it's not so much about authenticating a route server but authenticating over the clear, in the clear, and then someone, not an off line dictionary attack, that's possible as long as you use weak password of any kind. I don't know if I always use these key things.
The, okay. Well, two things. The second thing is, I never liked digest when it first came out. I like it less now. If, all this ad hoc stuff, if we're going to authenticate some things and not others, and now you want to glue some integrity system into it. I'm much happy with some sort of proxy mechanism that has encapsulation of data. If we're going to eat this password stuff anyway, that's fine. And then you don't have to worry about all the details of that, how those are handled. You still need a prompting mechanism, but that's really quite different. That at least gets rid of all the weird header stuff.
NEW SPEAKER: I'm more than happy to say that digest does have a lot of problems.
NEW SPEAKER: It should be --
NEW SPEAKER: Just to say one thing real quick. I do think SIP has improved the prospect of digest in this regard.
NEW SPEAKER: I'm at a loss to know how to go ahead. You know, we've got people saying digest is terrible. You've got people saying, yes, but it's useful and there isn't anything else.
NEW SPEAKER: And both are correct.
NEW SPEAKER: And I'm never in favor of patching problems that really need to go away and get really fixed. But, I don't see other alternatives on the floor or even kind of circulating in --
NEW SPEAKER: Brian.
NEW SPEAKER: Drafts or whatever.
NEW SPEAKER: The point of digest, one problem is when you send digest on clear text transmission paths and as Jonathan was saying, over T L S, that's kind of okay. The other problem is, when you're doing any kind of digest stuff with a third party, that you are not authenticated, so, the simple thing for us to do, would be to only use digest in say the rich transaction, when you do something. But using it for anything else, is basically calling for trouble.
( He has an accent I don't understand everything he says. )
NEW SPEAKER: There's no other solution on the table.
NEW SPEAKER: There's plenty of stuff.
NEW SPEAKER: No. There's only -- none of the things --
(Several people talking.)
NEW SPEAKER: Are solved.
NEW SPEAKER: None of the things --
NEW SPEAKER: The security review for BIS, came down to, that digest is a way, is a very light way to do some form of user provider password, was, you know, it was a deploy able, but we could understand, it's not really basic. And this document partly is with us, not by, by the way, not this SIPPING with digest aka, the extended digest that does message integrity and a lot of other things that digest hasn't done before. It was with us partly because GP P three is wanting to find solutions. And there's a good possibility of taking more time on this. And doing some that's right. With some good security input. For example, the question of whether this is supposed to work through Eintermediary, I mean, for E intermediary s, it's not clear cut. The security where intermediaries are present, they're supposed to do stuff and so there's a real possibility that the right thing to do is say, this document is not proceeded. Certainly it's not a working group document. It's been given a lot of thrust before because of three GP P and we should discuss for the charter document that does something a little bit more longer term and quite possibly exploits what we have on the desk now. And extend that.

NEW SPEAKER: I just want to mention that, of the things in James's draft, that there are probably some of them that we could probably get consensus on fairly quickly. And that sort of, you know, as some of the mechanism gets more and more difficult and the applicability gets smaller and smaller,
That the support for various parts of the draft are different and I'd like to try and --
NEW SPEAKER: But you're trying to walk a line. You're taking what Alison just said, and ignoring it. They're saying, don't use digest, period. Come up with a better mechanism.
NEW SPEAKER: No, no. There are, there's some, there's clearly some low hanging fruit here. And we should be picking it. And you know, we may even decide anyway, that there's some compelling reason to do a more complex version of this draft. But it sounds like that has to be evaluated first. All right. But, we should definitely take the low hanging fruit.
NEW SPEAKER: I clearly want to separate, I mean, I don't, there's a huge deployment of digest and there's a simple role where we don't have D L S and we have a certain need to authenticate it and get a password from an end user and we don't have a certificate. The digest N V 5 is not known to be throw out let's get rid of it altogether.
Then there's the topic we're going to have now, which is not extending the things digest does, but giving digest a method that supports a different kind of password than the ones that aka does. So you keep saying choose this document or throw out digest, that's not what we're saying. What we're saying is, consider what this document, what requirements it's trying to meet, and don't take, don't go against the security community's advise of extending digest to meet the requirements. They're telling us that's a bad idea. Look at the requirements, and find a way to do it. Don't throw out digest where the requirements are met. If there are a couple of other simple ones in that document, that's possible, but let's hear what those are. There are ones than what we are pushed to do and that's what the security community has been telling us.
NEW SPEAKER: I think one of the core things that digest is desperately needed for and doesn't do is register authentication. That's one, and I mean, every device needs that. Basically, right now, because of the lack of protection, we can't do that reliably. That I think should be, if we do at all, but we need something, which is deploy able, for simple devices which currently only do digest but can do full protection of registration. It's not a matter of perfect security. It's a matter of improving. I think authenticating the previous hash and all these other things, that's all nice but it's not a known vulnerability that we need to solve for the current digest use. It's actually instrumental when we register ourselves.
NEW SPEAKER: Thank you. Steven heyns, I'm coordinator. I represent the three GP P point of view.
We do have a requirement to protect messages over the first hop. We are not so concerned about subsequetn hops so we have sort of a basic need. We don't want to dictate what the solution is, but we need a solution.
So we would like to know sort of what the intentions of the working group are toward digest. Because if it's not a mechanism that we can rely on, then we need to try to put other plans in place, such as using IP sec or something like that. But we need a solution to to this problem and we need the direction very soon, otherwise we're in a bind and we won't be able to deploy as we planned. Thank you.
NEW SPEAKER: We have to wrap this up. We're over our time already.
NEW SPEAKER: Only comment I'd like to point out. I think we have a need for some of the stuff that's beyond just three GP P. I think we have a requirement for middle to client authentication, for sure. And we don't have a good solution for it and there's other non mobility phones that require that. I'm also, I'm always fine, you know, with if there's something better, I'll take it. I also just heard that the problem of Eintermediary decline and authentication, is a very hard one. I'd rather, if there isn't a cooked solution from the security community that works, like S Y did and there's no alternative, I guess I'd rather have something that's not perfect rather than nothing at all.
NEW SPEAKER: But digest --
NEW SPEAKER: Just what is the solution?
NEW SPEAKER: Steven just mentioned, use IP sec, and one points that we've had in discussion in the past in this working group, there are environments where IP sec transport security is going to be there. Channel security is going to be there. So there was actually a thought to have a little area of an IP sec approach that the three GP P people would do for the first hop, for some review and it's not happening today because there was some difficult. But that might be the right thing for the short term solution. Because IP sects is always okay, as long as you you have it there the particular role. And if you can specify how you're using it, that is possibly the right way of meeting that requirement.
So, one thing is maybe we can have 5 minutes on the, on another agenda to talk about that. I don't know if there are anymore agendas left.
NEW SPEAKER: We're already way over on this item. And I don't know where we're going to find time to finish our schedule. Go ahead.
NEW SPEAKER: I don't see this on three GP P what I see on the mailing list for the security and I just noticed some notes that were sent out that the three G two. Is indeed considered an IP sec, as the way to secure links between proxies. So I think, I felt like I should mention this, in case it matters.
NEW SPEAKER: All right. Let's finish it. These are the last two.
NEW SPEAKER: Just for clarification, the three G S A three group will vote in the next week on either to use this mechanism or to use IP sec, so this is the truth, in three G, and if we can't get guidance from the SIP group telling us -- okay. Thank you. Saying, this is the solution from SIP point of view, then I think this would be very helpful for this vote. Thank you.
NEW SPEAKER: I just got the comment to say the IP sec is not the perfect solution and I believe it will place limitations on SIP, especially when combined with signaling compression. So I don't think there is an ideal off the shelf solution.
NEW SPEAKER: I don't think the IP sec solution can be off the shelf. I need an area director. We made T L S and something else mandatory for proxies. And as they come along, T L S is going to be preferred. And there may be some other issues, but, the, these plans, the availability of T L S should be greater and greater, and that's what's been reviewed as the preferred solution for doing this.
NEW SPEAKER: Okay. Just on the issue of header compression and three GP P that's been studied and there are no severe limitations seen to that. But I think it's not a discussion for here.
NEW SPEAKER: It's actually the SIP compression, not the head err compression. And the whole point of doing the compression the way it's being done now, is so that you could use IP sec at a lower layer. That's the whole point. So there's no problem with either header compression, because I S P is something, and I just wanted to clarify that.
NEW SPEAKER: My last comment, for a single hop security, there are certainly better things than digest. How can I, I thought we were solving a different problem and digest is more sort of odd err relationship kind of things that have proxies there the middle and we don't have any other solution from the security community from that. Maybe I'm wrong and I missed that working group. Now she's he's going to tell me I'm wrong.
NEW SPEAKER: The real risk of digest is trying to do it with somebody you Done know. It's kind off okay to use digest, in a limited scope when you talk to a local guy you know, bass basically, you don't feel it. If you are doing digest, with the third party you never heard about, forget about it.
NEW SPEAKER: Okay. We're not getting anywhere. Let's move on. We'll have to take it to the list.
NEW SPEAKER: Just move on.
NEW SPEAKER: All right. So, my name is up there and I'm here to talk about the draft using aka inside digest authentication. And basically, the people in Salt Lake City, I did something on a similar note. Basically the motivation for this work is that there is some infrastructure that all security needs. Since most of the set up cost is in equipment and stuff like that, then there's a strong desire to re use that existing infrastructure.
So, this really materializees in three GP P into a is sub system where there is authentication is a key agreement mechanism available, and it is really would be nice to re use that in also the I MS certification.
So this is a shared secret based authentication that uses a smart card device for storing the long term circuit. So the previous approach was using E A P on top of SIP. This was presented in Salt Lake City and we got some pretty good feedback on that. And I know it was decided that a more, say, tighter scope was needed for this work. So E A P itself is much more of a general problem and really, it's a bigger problem, and not basically something that's solve able in this time frame that we have at this point.
So, I'm a little bit of this aka mechanism, basically, it's a challenged response, authentication mechanism where the server calculates a random challenge using this, or actually, that's a random challenge and then calculates the network authentication token, using the shared secret. Sends those to the client who uses the ran to calculate a response, or optionally, the alts parameter, which will tell the server that the synchronization between the client and server has fallen out. So has to re send the numbers.
And so, the digest aka, re uses the, digest scheme, and uses the aka parameters as sort of input for digest mechanism. So digest challenge contains the aka challenge, which is the rand and all those parameters. And aka rest is used when used as input in calculating the digest credentials. And also, a new S Q N synchronization.
So, basically, to kind of add it up. Aka is used as a one time password mechanism for digest mechanism.
And a couple of issues, this first issue, choke point attack, so, was also raced on the SIPPING list, and it's basically sort of a similar attack of saying the weak password that was discussed here earlier, that if we re use the res, not use it as a one time password, but sort of a longer term key, that it is possible to have an attack and guess the rest and get messages. But this is pretty much the result of confusion where the mechanism actually stands.
It was somehow mixed with the NAS digest and these are totally separate mechanisms.
And the other issue is that, whether we should adopt this solution which would re use the, digest framework and thus provide limited message integrity and be complimentary to what digest does today. Or, whether we should define these as a clear text http://Aka, in which we would not use M.D. 5 or anything like that. And make it optional. So basically define a new authentication scheme that would just transmit those aka parameters in clear text.
So, the future for this work, I would like it to be a work item, for the SIP working group and we'd like to get some input on what the category for this would be. And also, we propose that this draft is taken as a solution, proposal for solution, and work out the a for mentioned issues. And the test this for time pressure, because it is critical to the three GP P release 5th spring.
NEW SPEAKER: When you say transmit the aka parameters over the H T T P, in instant messages, do you mean, the first two messages or you just mean the final result?
NEW SPEAKER: Well, the aka challenge, and the results.
NEW SPEAKER: Okay. So, right. So,
NEW SPEAKER: So I mean, it would basically look like H T T P based but of course with this one time aka pass words.
NEW SPEAKER: So basically, you cut and paste the text?
NEW SPEAKER: Right. Right.
NEW SPEAKER: But I mean, if the I N S context there will be protection after the authentication has, as we've discussed actually earlier, after the authentication has succeeded, aka is able to generate keys that can be used to protect the session after that. So, for example, key material for something digest and IP sec.
NEW SPEAKER: But if you just carry headers and using it as input for digest calculation, then it's perfectly easy to cut and paste the text for arbitrary requests?
NEW SPEAKER: Right.
NEW SPEAKER: So in this, it's probably somewhat othogonal, but the question is, could you be operating in a mode where you would include a message slash step in this mode and thus avoid the head err problem, if you use it in digest mode?
NEW SPEAKER: Yes, because this is exactly like digest. I mean, we're not changing the way digest works, we're just adding new, say, password system. So it would be possible to also protect the headers.
NEW SPEAKER: The body.
NEW SPEAKER: The body. Yes.
NEW SPEAKER: With both, protection.
NEW SPEAKER: This doesn't involve any SIP extension? This is strictly extension of the H T T P method?
NEW SPEAKER: Right. Right. So basically, that's one thing that I kind of wanted to get input on, is what exactly are we doing here?
NEW SPEAKER: Because it's good to get the SIP people's knowledge. And also, it would be something that would be kind of allowed, you know, and basic is not allowed, but this would be allowed, so there's a little bit of influence. But there's no reason that the session has to be a working group document, having had this review here. It could be an individual and even go to proposed standard with last call, with a longer last call without a working group document. And I don't have a strong sense of that. It be --
NEW SPEAKER: We'll just ask if they want to do it. It is definitely possible to have it go through without it being a work item. But is there any more discussion on this item?
NEW SPEAKER: They seem to be thinking that you would be better off using the parameters as an input to digest, not just leaving them.
NEW SPEAKER: I think that's been the thought of the authors as well.
NEW SPEAKER: Yes. Any, you guys want to say anything?
NEW SPEAKER: So, I think that, the question at hand is, is there sufficient interest within the group to make this a group item or should we just ask them to continue on as a an individual submission. I think the issue is, whether the people in the room see a use for this beyond three G. Is in this going to be useful to you? If it's going to be useful, we should do it. Can I get a hum for people who think it's sufficiently useful and we should go ahead and make it a working group item. Hum if you want to do that. Okay. Opposed? Pretty clear consensus. Thank you.
( No one hummed on the second request. I don't know what he said. )
NEW SPEAKER: No reading or no IP O? Do we have a reading?
NEW SPEAKER: We don't have it. I mean, whatever claim in the draft, of course.
(Several people talking.)
NEW SPEAKER: It's 20 26 compliant.
NEW SPEAKER: Okay.
NEW SPEAKER: Okay. So, we'll do a working group, sorry. It will be a working group item. There are suggestions on how to fix the one issue. And we'll go on with it. And it seems like we can run this through pretty quick.
NEW SPEAKER: Just for clarification, what is interest of the group on using this mechanism in outside three G networks? I mean, I am suspicious that people have nothing better to do other than hum.
NEW SPEAKER: It's possible.
NEW SPEAKER: I'm really curious, I just want to know what people are thinking to use mechanism called aka, that it was assigned to use in 3-D networks outside the scope. So I'm really, I don't see that. I don't see why it is going to be working group item.
NEW SPEAKER: I second that.
NEW SPEAKER: Well, there might be a case where you would use the 3-D something socket, but run over, or something like that. So in that sense, it might be useful to running other methods as well.
NEW SPEAKER: I guess the whole generality is, I mean, it's limited because you need the aka infrastructure to use that. But if you have it, so,
NEW SPEAKER: All right. I think we may have a little more discussion on it. And then visit that issue again. Because, it's, it may be much more limited. It may be better to just leave it as an individual.
NEW SPEAKER: Okay. There's some confusion on who is going to present next, but I'm going to talk about some issues with security open issues, and security negotiation. And also, my draft, draft arc co-SIP sec agree zero one.
Basically, the issue is, s we have some networks where there's first of all, different kinds of devices that the grand mother's phone, ten years old and your new high tech phone and they need to work together, and they need to work together with the infrastructure. There's no network control so you can't decide today at 2 o'clock, in four minutes, we will switch the network into using foo security, instead of bar security. So when we have this protocol, such as this, we have different security mechanisms, such as T L S or S MIME or IP sec or digest. We have this problem of how to select between these mechanisms and we have to support multiple mechanisms, at least at the infrastructure site.
And, always when we have these multiple mechanisms, we would like to use the strongest one available, between those two pierce, so if I support T L S I will use that with my server or proxy.
But the problem is that, if there's an attack err in the network, a man in the middle, he can sort of beat down this selection between the different schemes. Electric claim that the, you know, the T L S port is not reach able, or spoof, them or something like that, to make it go so that you will only run the weakest security that is agreeable to everybody.
So I believe this is a problem. So in this practical example that I have here, you downgrade to digest, or enhance digest, instead of T L S, even for those who did support T L S.
So, if this is a problem, here's the potential solutions. One solution is having in protocol I or T L S, there's some internal protection for selecting between algorithm parameters, and this is of course necessary, but this is only limited in use to that particular protocol. So it's only useful for algorithms between that, inside that protocol, not, it's not useful for selecting T L S for instance. They can't say anything about that.
And enhanced digest, we discussed earlier, bidding down protection. That's similar issues, only April applicable within enhanced digest, not outside that.
We also have since URL scheme and that makes sure that T L S is used. The problem with that is either you stick to using only T L S all over your network or you're still vulnerable to the bidding down a tax. And I don't support T L S at this port and so on.
So that's a problem. In my draft, we have sort of a more full solution that allows you to pick between different mechanisms. And it basically works like this, that the server lists its mechanism and then the client picks one of those and instructs it to use any say. T L S connection. And once you're using that security, you repeat the security list over that connection and the server will be able to detect if there has been a problem or a modification in this list, when it receives that note indication.
So notification.
So this allows you to do a bidding down proceed protection, but it assumes you have integrity protection from Day 1. So obviously, if we don't have any protection, there are a lot of holes, that this zero security indicates and we can't do anything. But we can do some things if we have integrity.
Okay. So there's a few issues around that, the solutions and the problems. So first of all, do we think this is a problem? Well, I do think, at least, that this is a problem. Maybe we should ask if this is a serious enough of a problem. I think there are cases for upgrading, from this to some other stuff like T L S, would be really useful. So I think it's a practical requirement for this.
Do we think that internal protection in some of these protocols like T L S or ike is enough, I think so, because it's only bidding that material, it doesn't help between the schemes, we have multiple schemes in SIP.
So, my proposal is that we should do something about this. And we should discuss whether this draft that I have is sufficient for that; we do require this protection before this can work. But it's probably not possible to do anything more than that. Integrity protection, by the way, must be of course, not vulnerable to attacks or at least not real time attacks. I think we can survive off line attacks. We would appreciate it, if there's anyone who thinks there's something we haven't thought about,
NEW SPEAKER: I'm not going to speak to that.
NEW SPEAKER: Okay. I don't know if you want to go into that.
NEW SPEAKER: All right. So, there's a few detailed issues within the draft. Such as whether to use support require headers and set tabs on behavior rules for that. Or new headers so that there's somewhat different semantics in these headers, and I think we need to have new headers, and negotiation, if the negotiation going to be end to end, or the sender of the message and the final receive, or also do sort of click in the path and I think we should also deal also sort of in the path and reduce the number of routes in our systems. And there's a few other things as well.
So, the way forward, I think we should do something about this. I am proposing that we do a small new RFC in this working group. Perhaps take my draft as a base for that. And as usual, this is stuff that is required for something like this, something like this is required for three GP P so there's time pressure. So that's it. Questions?
NEW SPEAKER: I was just going to ask, it's been a while since I read the dock, and I don't remember, does the document talk much about rule of human oversight and to what degree --
NEW SPEAKER: No, it does not. I do know there's some things in the C P S for instance, that deal with what the human can do and sort of, if human can have some sort of verification, and say, oh, I'm not getting secured, should I still proceed or not?
NEW SPEAKER: I guess the point is before you can even get to the stage where your security can be bid down down, you have to know that there's some reason, that you've gotten that idea, that you're going to try to use this particular type of security to reach that destination. And if there's one thing that SIP provides, that's it. You get somebody's address of record and you know, when I contact these people, I expect security, you know, the phone, like the little browser like that appears on Netscape. And it should prompt you, and not do the connection and skip it down. So I guess whatever it is that we in still in the protocol, that's possibly even more significant. And it's something that I don't think is really discussed. I know we talked about it a little bit, for a specific S MIME and BIS, but I think that would be interesting for this document to look at.
NEW SPEAKER: I think we need to look at that. It's probably not sufficient to just look at that. I mean, they're going to be to have to be able to call anyone and not know the pierce beforehand. So it's not sufficient to test, you know, to just go and get the URLs.
NEW SPEAKER: Is there an expectation of 3-D network that a certain security will always be used for every caller?
NEW SPEAKER: Right.
NEW SPEAKER: So I think we should probably set up applicability scope to that.
NEW SPEAKER: Other comments?
NEW SPEAKER: As far as I understand this idea, we have some kind of security procedure, assuming that there is some base security mechanism using integrity and so on.
NEW SPEAKER: That's correct.
NEW SPEAKER: And using that, we can level up the security negotiation. Now, the crucial thing is the security people are well aware of that, that security is not an ever lasting thing. Sometimes security is broken or needs to be improved. So the issue is, that we have weak link perhaps in it that we are not aware of it yet, and so that's the problem. The entire mechanism, that the overall security is based on that base security feature.
NEW SPEAKER: Well, okay --
NEW SPEAKER: I do not have a proposal how to improve it. Just want to point this out.
NEW SPEAKER: I basically agree, but of course, I mean, the base line security, you are allowed to change that. So, 5 years from now, we don't think this particular scheme that we are running as base line is not good enough, we should start changing that in our devices. But, I'm not sure if we can actually do much better than this. Because, I mean,
NEW SPEAKER: I like to, I mean, it's not as good as it could be in a perfect world, but it's as good as it can be given the circumstances we find ourselves in.
The, we're dealing with a situation where we have non homogenous implementations. And what we're trying to prevent is, if we have implementations that says, look, I'd really like some security. The more the better, but I don't want to talk too everybody. The implementation, something it's got and pick the securees one. And if some of them are too weak, as you say, we should always turn it off. So, yes, I think this is perfect until then.
NEW SPEAKER: Thank you.
NEW SPEAKER: So, other comments? What should we do with this?
NEW SPEAKER: Well, this one seems a little bit more clear. Anybody object to not going forward with this? To not, I'm sorry. Object to going forward with it?
Okay. Sorry. Too many negatives.
Let's do it.
NEW SPEAKER: Flemming.
NEW SPEAKER: My turn now?
NEW SPEAKER: Yes.
NEW SPEAKER: While Flemming is getting hooked up, he just really minds me to remind you all, that there is a three G, SIP, ad hoc meeting at 5:30 today in Duluth.
NEW SPEAKER: I'm going to talk about SIP extensions for network asserted caller identity and privacy within trusted networks.
Just a quick status of the draft. We have had a lot of good list discussion, about a month, month and a half ago, about what to do with the privacy draft. There was a lot of discussion about what kind of security mechanisms should we have and not have. We had fairly consensus there. Later on, there has been a lot of off line discussion and comments as well. Which most of you probably haven't seen, that have not been incorporated into the draft. John posted an e-mail, Monday, I think it was, raising a bunch of comments there and that's mostly what I'll look at here with the open issues. The document is currently in last call.
Quick overview that actually made it into the document. First of all, we have applicability statement that talks about the appropriate use of this extension. It is only suitable within an administrative domain or between cooperating administrative domains, where you clearly can control who are the trusted entities, that are actually subscribing to the services. And also the draft is not meant to address the issue of user asserted I'd Dee. So that's outside out identity, so that's outside the scope of this document.
The anonymity header got removed. This is really just one example of a more general problem of service location. And having a specific header for a specific service was probably in order a good idea. So that got taken out.
The issue of IP address privacy is still described in there but there's not an actual solution.
One of the things that we ended up discussing a lot is the issue of sense ability. I'll get back to that later. Right now, the document says, if you define an extension, it has to be documented in RFC and under go expert review.
Also, there were a couple of grammar fixes, consistency with 2543 BIS as well. The grammar, and editorial changes throughout the document.
The first open issue that was discussed and was raised on the list recently is how does the proxy handle a remote party I D, received from a proxy or U A. And we have been talking about two options. Option No. 1, which is what the draft says right now, basically says, well, if you can verify the identity that you set the screening parameters, it's yes. If you cannot verify, then default to leave the remote party I D in there and set the screen parameter to no. The other option which we suggested was that you should rather always remove an untrusted remote party I D, if you can then determine the identity, then you can always add the remote party I D, showing that identity information.
Comparing these two options, option one seems more general than option two. It allows us to have unsupported identity types that are being passed in the network, while still taking advantage of the general privacy functions that the draft actually defines.
Option two, on the other hand assumes that while if there is an untrusted remote party, and it's useless and should not be paced through the network. Option one says let the user decide about that. For example, header with caller I D, it may be interesting to me know what a caller I D is, even though it wasn't verified by the network. My recommendation, as to what is in the draft right now, is to go with option one.
NEW SPEAKER: And I will sit down again, because I have a lot on these open issues. But a couple of things on this.
I think, we added this applicability statement in the last version of the draft, and one of the things it speaks to is what sort of entities are expecting to be adding remote party I D header. And the mechanisms that follows is in some respects conforming with that, and in some respects not. Well, I might agree that it would be nice to have a non network asserted identity that you pass around, and SIP messages, I thought the appplicability of this was for network identities. And having the screen, having a non network identity that you're passing around.
NEW SPEAKER: Not necessarily, it's it just says that the network received it from somebody and it's not able to verify it. It could have been asserted by another network entity but you're not --
NEW SPEAKER: The appplicability is to the federation of domains that are related to each other, which I assume we're
NEW SPEAKER: Right.
NEW SPEAKER: We are talking about untrusted networks asserting it. So again, this may seem like a anybody semantic point. But it makes the applicability very unclear whether or not we're allowing user agents or untrusted user agents or not. If we have behavior, how we're going to handle it when user agent adds it and it's not behavior that is ignore it completely, it's do what you want with it and consider it be untrusted. All the suggestions that are provided as to what the decisions that are provided --
NEW SPEAKER: That's, but you always have to deal with the case where it was present in the message that you received from an untrusted --
NEW SPEAKER: Well, option two does suggest that.
NEW SPEAKER: Right. I'm just saying the problem is not going to go away. The only issue here is, do you enforce that it is going to be removed because you think that by definition, we're outside perhaps the applicability statement and there's going to be absolutely no way that the protocol should support. That mechanism support that or should we just allow that by setting a parameter. That's the real issue.
(Several people talking.)
NEW SPEAKER: Are we talking about protocols or are we talking about carrier policy here?
NEW SPEAKER: Protocol.
NEW SPEAKER: But, you're talking about policy decisions up there. It's not, it has nothing to do with protocol. Protocol allows you to have this field in the head err.
NEW SPEAKER: Right now, it allows, what John is arguing that issue not be there.
NEW SPEAKER: I thought he was doing option one or option two.
NEW SPEAKER: I'm option two.
NEW SPEAKER: Option two is remove, or to clear -- are you saying clear the field if it's untrusted?
NEW SPEAKER: No, remove the remote party completely. Don't allow it to be present.
NEW SPEAKER: If there's a trusted entity and it receives a message with remote I D for untrusted identity, remove them, rather than merely saying, these are untrusted and passing them along.
NEW SPEAKER: Either that or wiping it clear. But I think that's still --
NEW SPEAKER: I think you can have multiple remote I D party headers and I don't know what you mean by that as opposed to removing it.
NEW SPEAKER: Well, leaving the field null.
NEW SPEAKER: That's the same thing. Okay. That's fine too. Sure.
NEW SPEAKER: Either way, I think it's a carrier policy decision. If they receive this untrusted message or untrusted header field --
NEW SPEAKER: When you say clear it, you mean clear the screen parameter. When you say field, what do you mean?
NEW SPEAKER: Remote party I D.
NEW SPEAKER: So a remote party I D with nothing in it after it?
NEW SPEAKER: Yes. It's a carrier option if they're going to trust it or not the
NEW SPEAKER: I think I'd rather remove the head err, just entirely. Than leave it in with no value.
NEW SPEAKER: It's bordering on, a structure of of protocol, and a carrier decision of how they're going to treat the message when it arrives in their network. I don't know why we should waste too much time talking about it.
We're not documenting protocol behavior here. We're documenting policy.
NEW SPEAKER: The issue is what kind of protocol behavior do we want to enable? John has strict interpretations saying he only wants one particular behavior. If it's untrusted, it goes out. That's it. What option one says right now, in the draft, is a little bit more. It certainly allows you to leave it in there but you have to tag it and say this is untrusted.
NEW SPEAKER: So I think that this is, this should be basically a policy decision by, you know, by proxy. I think it's totally reasonable for them to set the policy that we're always working with it. But I think that having some information is more useful than no information. And it clearly says this is not verified. I'm happy to receive that.
NEW SPEAKER: Can I to that.
NEW SPEAKER: Sure.
NEW SPEAKER: I really think, I support option one, but I think the important thing is the first part of option one. I don't care what happens in the second part. In option one, first bullet, the network is still asserting, it agrees with what the user said. If the user is allowed to have three values, basically the network says, whichever value it uses is right.
NEW SPEAKER: You might want to choose your words carefully here.
NEW SPEAKER: The network is asserting, basically, it's assistance from the user who is not trusted.
NEW SPEAKER: This needs to be stressed it does not deal with the case where the user is using remote identities.
NEW SPEAKER: Here is the problem. It's not described there the draft, and we should understand why people want to use this this way. I mean, can we take off our masks and stop the cloak and dagger stuff here, and say, that is why this draft is being pushed forward, it's a three G requirement that we have this. And
(Several people talking.)
NEW SPEAKER: It's definitely not just three G. And the circuit switch world, the same switch had to be dealt with ISDN, or the features that are concerned here. The and the decision there was to essentially go with option one, and where the policy comes in, is what is the policy that is used by the carrier, to assert that it is verified the presented I D. Some carriers, when they're presented with the ID will never verify it. Other carriers have mechanisms available where they will verify it. To set the screen D S.
The point I was trying to make is, that, as I said, ISDN circuit switch networks do use option one, and if we don't have some mechanism to support it, there may be inter operability issues.
NEW SPEAKER: I think I'm familiar with that, and what correlates to this, but I don't actually believe that that is the usage that is being suggested by these parties.
NEW SPEAKER: It is.
NEW SPEAKER: There is a difference. Again, the problem is, the draft does not speak to any of, I mean dash
NEW SPEAKER: It should be
(Several people talking.)
NEW SPEAKER: The draft says it's network asserted.
NEW SPEAKER: The draft, clearly only talks about network asserted identity. But you are right. I mean, it keeps these things in mind. Make sure if anybody wants to do something like this in the future, there's nothing in the draft that will prevent this from working, it can be used.
NEW SPEAKER: So if there is a motivation for keeping around these unauthenticated identities and a behavior that some entity is going to take on account of that, I think that behavior should be characterized in a draft and we should change the applicability, but otherwise, if it's unmotivated, then we should remove it.
NEW SPEAKER: So, I think there is actually a use for this thing that's well within the scope. And I agree with John, that the scope is what's been described and everything needs to be cast into that light. When a request arrives at the edge of a network and comes from an untrusted network, everything should be thrown away. When you arrive at the edge of the network, you either authenticate the identity or not. And it may be that it's coming from a user that's not someone who comes from an external Gateway or something like that. It arrives at the edge not from one of your own users and you can't authenticate them. It's useful at the edge of the network, when you enter, clear what was there. Insert a statement of identity and mark it as we cannot trust this. Therefore, the way we use it in the network, we know we cannot trust the originator of this message, we must not run any service or functions based on authenticated and we don't know who they are. And it's useful in the network to know that so we don't try to re challenge other net networks, in the middle of the network. That's in the scope and spirit of what the draft is trying to do. And I would be happy to see the draft say, everything at the edge goes away, because that's problem space. And if you cannot verify, you put this in for this kind of purpose. And I'd welcome comments on that.
NEW SPEAKER: If wick make that general enough, because we have to cover a lot of scenarios here. It's not just three GP P.
NEW SPEAKER: What did I say that was three G specific?
NEW SPEAKER: I'm just saying, make it general. There are many edges to some networks.
NEW SPEAKER: I'm sorry. The model in this document is a domain or a fed rated trust of domains that have a relationship. That by definition defines a perimeter. That almost always excludes the end system. Okay. So that is the scope of this document. That's, and I think it's crystal clear that the nature of this document is that there's --
NEW SPEAKER: We're also talking policy again. Let's say someone is going to insert something or do something, why do we have to talk about policy, they're going to do whatever --
NEW SPEAKER: Who is they?
NEW SPEAKER: You said if it comes from the edge of the network, you must strip the head err if it's untrusted.
NEW SPEAKER: Part of the reason is to prevent --
(Several people talking.)
NEW SPEAKER: If we have a protocol that's brittle and that we can't prevent, once there's a slip and that invalid information flows all over the place, and we
NEW SPEAKER: That's not the responsibility --
NEW SPEAKER: Well, it is.
NEW SPEAKER: Well
NEW SPEAKER: It's the responsibility of the operator operating whatever country where the rules apply, to deal with that, to, that's what the way it works today. Same thing.
NEW SPEAKER: This isn't the B S D N today. As much as people want to think that.
NEW SPEAKER: I don't see how what you're saying, is defined in the draft.
NEW SPEAKER: When you say.
NEW SPEAKER: There's going to be privacy leaks. Where do you see that?
NEW SPEAKER: Actually, I was going to comment directly on his points. I got three main points that Jonathan made, which is that that this is brittle, if we, you know, this becomes brittle if we allow for options like this. And clearly, I know of more than one implementation that does it this way and it works and it's not brittle.
That the assumption being that you can only authenticate if you've got this ring of applicability that you can only authenticate on the edge of that ring and you can't pass information into the inside, that you can ought, that you can separately challenge or authenticate further on in the ring. That is the reason.
NEW SPEAKER: You did. You said if you strip it off the end of the network, there's no way you can get it into the middle of the network somewhere or something in the middle could then verify. There's nothing to verify. You've thrown it away.
If the first proxy, if something comes from one proxy and goes to, you know, to my proxy on the order of this domain, and it doesn't know how to authenticate it and it just marks it and says, I don't trust this, that passes it further on. Something else further on in the network -- might be able to verify it.
NEW SPEAKER: Is free to verify it by sending a 4 O 7 to the entity and then it can mark it, yes. And that is useful.
NEW SPEAKER: That's my point.
NEW SPEAKER: And then finally. The policy that Jonathan described, that if I don't trust it, I can do different things. You can still do that, because it says screen equals no. So if it's not there or says screen equals no, you can still do the same damn thing.
NEW SPEAKER: So before we take anymore comments, this is issue one out of 7.
NEW SPEAKER: And we're 20 minutes behind.
NEW SPEAKER: We're never going to resolve this.
NEW SPEAKER: If you quit talking now, we'll be on time.
NEW SPEAKER: Go ahead.
NEW SPEAKER: I have a lot more to say about this issue alone. I can do this for another hour. Probably.
NEW SPEAKER: Please don't.
(Several people talking.)
NEW SPEAKER: I think what he said is interesting, if you have the screen equals no, you can pass this to the middle of the network and something there can verify it. Something in the middle of the network that can ascertain your identity, can create the head err itself, rather than taking one that is there and changing it to screen equals no, unless there's something you're communicating from the untrusted side to the trusted side with that header. If that is true, and we all know it is, right, that that is like what this is about, then please, let's put it in the draft and say that is what this does. That is what it --
NEW SPEAKER: I don't have a problem with that. I think we agree on what is being said. But the question is, do we want to argue about it or not. I don't see any reasons to disallow it.
NEW SPEAKER: The I S G is less and less in fashion of passing documents with half security, and this document has been discussed. It's not going to fly. Fix the security.

NEW SPEAKER: So is that a general statement on the whole document or this particular issue?
NEW SPEAKER: Somebody more expert than I should speak to the details.
NEW SPEAKER: Alison?
NEW SPEAKER: Is the I S G has discussed the document, and if the scope is the scope, and it matches the applicability statement, it makes it more likely to pass. If things don't match the applicability, and the boundary is, there's some sort of information about privacy that is in some way flowing, even though we said it was only valid in the boundary and we're not doing a secure thing, we're doing option one, it's not likely to pass.
NEW SPEAKER: I don't see any security difference between option one and two. Can you elaborate on that?
NEW SPEAKER: Could I very quickly, all I want to say is that we are doing work on SIP ISIP in or SIP BIC inter working in study group 11. And at the moments, they have accepted a mapping, assuming the draft as it was. At the moment, they map, if screen set is no, they map the presented identity into additional calling number, which is some field apparently that presents additional information. But for the actual calling party number, they provide a network generated number.
NEW SPEAKER: I guess what we try to do here, in the ISDN, there are two cases and we try to represent both in option one. The first case in the ISDN, is when basically, the entity is providing the level of trust, and say the user has three trusted numbers, the information sent by the user is just to say, use this one, rather than the other two. And the other case, you get into the case of the user providing no screen case where you get Xs or whatever, and basically, you need to rely on that sending entity to be a trust fed entrusted entity.
When you get to built two in option bullet two, in option one.
I would say you're not doing security problems, because the information supplied to you, is just allowing you to choose one of the parties you would otherwise use for that, and you're providing the trust, saying, he's, these are all three values and I want to use one of them, and I've got no problem with it.
NEW SPEAKER: I agree with what he's saying should be in the privacy draft, because it would make it clearer what this draft is about. And I just wanted to say as well, that I do hope, and I want to make this absolutely clear to everybody here. I think we need this, I think we need a proxy mechanism, we need something to map to ice sop, and applaud the work we're doing. And we definitely need to do this. I hope that, in time, we too will find a good way of not being here at the IETF, mapping sit back users to the proxies, so.
NEW SPEAKER: One thing that I'd like to ask, and this is a very frustrating things in times of dealing with any draft, is the myth Cal security people have said no. That's useful. Do we have any myth Cal security people who can offer more specific guidance or someone who could get us suggestions on how to get more specific guidance that will lead to a solution, as to what in particular is wrong and what needs to be fixed
NEW SPEAKER:
NEW SPEAKER: We've already done this. We said we're going to do an applicability statement, which shows the narrow area that this is applied to
NEW SPEAKER: I think dash
NEW SPEAKER: So over to the areas that security people question this, the security people brought up good points, as to why this is an open draft covering a lot of areas, and now it's narrowed.
NEW SPEAKER: You're still complaining.
NEW SPEAKER: And there's going to be an applicability statement. We've got to wait for Flemming, or somebody.
NEW SPEAKER: It's in there.
NEW SPEAKER: It's in there now?
NEW SPEAKER: It's in there. And it's good too, in the last iteration of the draft, there's a lot of language with the network assertion material. But it does obfuscate the matter of what the requirements are of figuring out what the network asserts. And a lot of the disagreement is predicated on that. And until we understand what the requirements are, to have those explicit requirements, it's confusing when you need things like screen and you don't. If your authentication method could say, provide authentication. Let's say your method, is likely, digest authorization to provide a user name and that user name in this context could be the identity that the person wants to assert. Well, I mean, some authentication methods work that way. Some don't. What are the requirements that this one suggests? As long as that stuff is unspecified, I think there is a security problem with this.
NEW SPEAKER: Well, we have to be careful, because we have to generalize this. Because other groups, like the I T U are going to go off and develop a rich set of specifications going into great detail of how it's used. The IETF is not going to generate those documents.
NEW SPEAKER: ISIP requirements, that's all.
NEW SPEAKER: So if we can express that easily, within this document, without violating any rules of publication, that's fine. But, we can't just go up and write tremendous amount of specifications on how this is going to be used because other groups are doing that.
NEW SPEAKER: I think we can. And I think we should. We can make the document better. I think we need to do it. I'm really trying to work with things that will make this document better and more likely to pass the I S G.
NEW SPEAKER: So I guess what it really comes down to, if you want a a nutshell of, you have this if verifiable. The if verifiables is something that says I know I'm in my ring of trusted things. Now somebody starts using it in other places and the very ones that are doing it, the other trusted entities that are using it. Somehow valid for them to use it for some purpose. Now they start using it in environments where there's nothing for verification. And all of a sudden it's a general privacy mechanism instead of narrowly privacy issue for this particular configuration. It's very difficult for IETF people to do protocols which have narrow applicability. And we are very, very worried about boundary conditions on applicability.
NEW SPEAKER: I understand that, but at the same time, I mean, you were part of the development of the applicability statement.
NEW SPEAKER: And this is has been as I said, a problem with the applicability statement all along.
NEW SPEAKER: We should teach something about privacy. Because it's not about privacy. I mean, it's about the network extension or whatever. But it's not privacy.
NEW SPEAKER: I think what this wants to be and my reading is always been that it's network asserted identity, in order to create, to provide privacy.
NEW SPEAKER: Quite the opposite.
NEW SPEAKER: I understand
(Several people talking.)
NEW SPEAKER: And of course, I think we also need user provided privacy. This is another angle where the network asserts identity in order to provide privacy --
NEW SPEAKER: In order to not provide --
(Several people talking.)
NEW SPEAKER: It's the other way around.
NEW SPEAKER: I got too little sleep.
NEW SPEAKER: So the problem, I have all along said, I agree, the problem is, it introduces a privacy problem. The SIP spec has a very easy way to be private. A concept to me remains curious, why the other folks don't understand why this is fairly good. The network asserts identity so they have to --
NEW SPEAKER: To the other user.
NEW SPEAKER: Right. So remove, if you insert anything. Or they may say, great, I'm happy, you know, I'm Jonathan, I'm not afraid to say it. They may trust your asserted identity more than mine and reveal it. So that's the problem.
NEW SPEAKER: Let me restate what Jonathan said in much simpler terms.
NEW SPEAKER: Sorry.
NEW SPEAKER: What we have here is a situation where something in the network wants to break our privacy, and we're asking it nicely not to do so. And putting bounds about how it can go around expressing the information that we didn't want it to express to other people.
NEW SPEAKER: Sure. And let's take it a step further. I mean, I think, probably all of us agree that via hiding would play a more complete role, I think the concept of appealing to the network, to do some to make your conversation with other people private, from those other people, is not at all irrational. It's a perfectly good service to have. I think that's clearly applicability.
NEW SPEAKER: Realistic usagees of this draft are either sending this information to a P S D N Gateway with a P S T N, where the, you know, the information in other headers, like the U R I and the by headers and the addresses you use for your media are relevant, because they're totally hidden. Or they're going through, you know, an IP to IP anonymizer.
NEW SPEAKER: I think we're getting outside this issue now. How much more time do we have left
NEW SPEAKER: Zero.
NEW SPEAKER: Minus 50 minutes.
NEW SPEAKER: We're once again, we've done this on the mailing list. We've done this at the prior meeting, we had discussions on this. We've had lots of time here. We're no closer to solving this problem than we were when we got into this meeting.
And, the problem is, that not all players are present. That's it. I mean, you've got people who,
NEW SPEAKER: If you're talking about the I S P or security people are not present. What I told you is the statement, an applicability statement has to be vigorously candled by all aspects of the dock. I like the appplicability statement. And I was involved in writing it. But the document has to --
NEW SPEAKER: You're going to have to the help me out and tell me where it does not.
NEW SPEAKER: As I said, if there's usage that are not in these circles of trust, then that's not what we want, but I cannot pre --
(Several people talking.)
NEW SPEAKER: But you can drop it when you're using in a meaningful way. Because they wanted this, are not going to take it from people who are not part of the circle. That makes it a reasonable test able boundary on applicability. You can put the guys you want to use it in the circle. Maybe the problem is how you're defining who is in that federation or that trusted network. It's not that easy for the I S G to evaluate what, you know, what these external conditions are, unless you agree you've got this trusted network and maybe you need to call that something bigger than you really meant if there's these wonderful non brittle uses out there already.
But applicability statements are, you know, so, there's no missing parties here. Because I'm instigating this review, and I can write some more about it. But we have had plenty of discussion, I agree. I mean, --
NEW SPEAKER: Are we playing a joke here?
NEW SPEAKER: What does that mean. The
NEW SPEAKER: The notion that we're trying to force policy, into say a transport level protocol.
NEW SPEAKER: No. We won't do a document which is for a limited form of privacy, except under special conditions. And people want a privacy document that really does a complete form of privacy, with all the possible things that are valuable, that is also within the goals of this working group.
We're under some time pressure from this working group, from three GP P to give a limited form of these services, and with an applicability statement. And if you mean by we're pulling a something, we're doing architecture and I S G quality review, yes indeed.
NEW SPEAKER: Sometimes those can be mistaken for obstructism. Enjoy yourself.
NEW SPEAKER: So, if I summarize your comment, Alison. What you want is that the document has not only defined applicability, but has to enforce it. Is that accurate?
NEW SPEAKER: It has to provide tools for enforcing it and it has to provide tools for it.
NEW SPEAKER: The tools are in there.
NEW SPEAKER: No, your document will not cause people not to use this R pit wrong. But when somebody complains and says your product did this thing, the fact that the spec said don't do it, helps the vendor cure their problem. We don't want the spec to say it's okay to do things we don't think are okay.
NEW SPEAKER: I don't follow you. It says very, very clear in the document that it is not for use in a
NEW SPEAKER: But then you say.
NEW SPEAKER: But.
NEW SPEAKER: Whether we get it from someone who is not supposed to
NEW SPEAKER: No, I say when you get it from an untrusted entity.
NEW SPEAKER: That's someone
(Several people talking.)
NEW SPEAKER: It's for use among the trusted notes. It's for use among those things which have this external notion of a trusted group of notes. And then you say, but people who are, things which are not in that circle, may be using it let's process it and send it on. And you have to do a lot more mechanism to make that work, I mean, I guess one could sort of try to get some constructive, here's about 25 things you could do to make it so that you really know that, I really don't want to go there.
I said enough about it. That's what the thing is. You said that certain things can use it and these mechanisms are for certain kinds of configurations and we don't want to talk about the behavior of things using it which are outside the scope of applicability.
NEW SPEAKER: I think I'll hoist myself on my own something. I often, when people complain about a draft, I say, send text. So since there seems to be extreme confusion about what's wanted here, I think instead of wasting everybody's time for the next hour, trying to hammer on something, that we'll try to send text.
NEW SPEAKER: Thanks, appreciate it.
NEW SPEAKER: Move on.
NEW SPEAKER: Can I make one last comment, I don't know if -- when you send an invite, if it is a trusted entity that you're sending the invite to, you fill in the from field and you fill in the head err. And you only apply the trusted entity only when you send. When you receive, if you do get it, just go ahead and use it. So that could be a way.
NEW SPEAKER: Let's be done. Thanks.
NEW SPEAKER: All right. I want to briefly run through some of the discussion. We had a last call on refer in December January time frame. There wasn't a lot of discussion. I don't know how much of it was because there wasn't much to talk about.
One of the consistent pieces of feedback was, there was a desire to go ahead and fill a gap that we had a solution for and took away and just left open.
What that gap was, was when C receives a request with a refer by header in it, can C do anything? Can C take any algorithmic, make any functional difference on the processing of that invite, based on the content of that refer by header and what are the implications of it doing that if it can't in fact verify that the thing that is being claimed, what was being referred by, is there.
So, you know, to see what the kind of problems are, if it is something as simple as having what's in the refer by header displayed on the U A it's seen and the human is going to make a decision based on what gets displayed, you can end up influencing that human's choice by giving him information that is bogus.
And you can mess a human up that way, you can pick any algorithm you're going to put in your U A and mess it up much more quickly.
So, there have been several people that have suggested things that we could do to address this. One, get rid of the referred by header, don't make a claim about where this thing came from. You don't have a problem.
Two, we can leave refer as it is, go ahead and solve the problem. If we're going to solve the problem, we have to solve it somewhere. And this is what we talked about at salt lake. We could leave refer with just transport pieces that could carry the solution to the problem and then go solve the problem off in the transfer draft, for transfer itself. And some other use of refer can solve the problem in some other way.
We could also go ahead and specify a refer specific mechanism that would cover all uses of refer, or we could go to a much bigger cannon, a sufficient but not necessarily a necessary step, of solving a general problem of passing authorization tow Ken's around through third parties
( Tokens around through third parties. )
NEW SPEAKER: A fifth solution would be to simply limit the expressiveness of what you're saying, and say, I only trust being referred to the extent that I trust the issue of the invite. That means, if I trust whoever sent me the invite, then I trust whatever else they put in there. And if I don't trust them, well, I probably shouldn't trust anything else in there.
NEW SPEAKER: Scoping it --
NEW SPEAKER: Basically saying that this means, when I'm not trying to infer anything from that. Don't do third party trust,
NEW SPEAKER: Okay.
NEW SPEAKER: This is just another header. Simpler solution.
NEW SPEAKER: And one more to add to that, you could send a token directly from the transfer to --
NEW SPEAKER: Yes.
(Several people talking.)
NEW SPEAKER: I think any solution falls apart, I have a very old friend, somebody at the IRS wants to talk to me, I'm not sure you necessarily want to follow that path.
NEW SPEAKER: Okay. Let me step through some things.
In general, since we are very time constrained as I understand, I have slightly over 5 minutes, unless I severely offend somebody, wait until I get to the end of the all right.
So, the, out of these choices for a path forward, the ones, the one I'm going to talk about for the rest of the presentation, is specifying a refer specific mechanism, augmenting that possibly with things like April appplicability statements and usage descriptions.
So, the possibility mechanism is finding a solution inside refer, by the using the referred by generic parameters. And come up with an authorization level kind of authentication we've had around. Use S MIME body parts or, generic parameters, this is something like in the original transfer, came refer draft where we used the P GP signature mechanisms to embed a signature inside the head err. There would be a lot of mechanics to go down to the route. This is something at the bottom of the stack if everything else fails.
We could make use of something similar to the digest challenge response mechanisms that we've got. That would require getting a challenge from C to A so A could prove their identity, and whatever else we needed to do. And what that might like look is something like this. Refer hits B, triggered invite gets to C. C says tell me who A S. And that gets bun dead into the SIP frag and comes back in the notify to A. That refer transaction is over. With an authorization header in part of what the refer to is. The triggered request gets built with that authorization header in it. C gets it, C is happy. Okay.
We make this work. We can get an authorization out of this fairly quickly. We can get some proof to C that A said do something. It's going to be fairly hard to get some proof about what A said to do.
So, third option, to use S MIME body parts. Basically, start extending what we're doing with S MIME for the end stuff that we've got. To basically take the information that's involved in setting up the refer, the refer to header and the referred by header put it into a SIP frag, sign it, bury it somewhere in the message, body part, doesn't matter, just get it into the transport. Make sure that gets into the request, into the actual triggered request. So, this is actually likely to be more efficient than a challenged response and we get some proof of what it is that the refer was intending. Paragraph it would look something like this, refer, you know, bundles up the refer to and referred by, signs it and put it in the message, you know, multi part body or header. That things gets to B. B will trigger request. Invite in this case, signing the request and a piece of what's in that signature is the thing signed by A with if refer to and refer by. So you can exercise policy. Here's what you did with it, this is what A said to do. Does this look good enough for me. This is the best we can do. This exposes all of the information that was involved in this transaction.
NEW SPEAKER: Slow down just a little bit.
NEW SPEAKER:
( He's talking really fast. )
NEW SPEAKER: All right. A third option, define a completely new mechanism. We have a refer from A to B. C goes back to A and says, did you tell B to do that? And we tread new ground here.
That slide is actually a little bit out of order and kind of speaks to a little bit about what Henning said. The transfer draft, not the refer draft itself, but the transfer draft talks about the advantages ever sending the refer to one side or the other, depending on what your relationships with the two sides are, that has applicability to securing the transfer of information. If you are using the attended transfer in particular, the screening case, there is a great deal of advantage to sending the refer to the screened party instead of to the party that you're transferring, because in this case, B is the screener, C is going to care a Lowell lot more about being able to get trusted information from B, which it can get by that direct contact, than A is going to care about getting information about C.
So, the proposal that I've got and we can open things up for discussion now, is to go ahead and pursue adding this S MIME based mechanism forgetting the proof of identity and both of these refer headers between A and C. And then add some discussion like the kinds of things I just talked about in that attended transfer case.
NEW SPEAKER: I was just going to say that I do kind of like this S MIME based possibility. I think that has a lot of potential to provide a very versatile mechanism for this. And I think we should at least definitely go down that road and explore it and see what security would look like in that respect. Looks good.
NEW SPEAKER: One other comment I wanted to make about attended transfer is it solves the problem of making it deploy able. It depends on a shared secret. The S MIME approach is, you know, if you're using self signed certificates for this. The thing that you're actually able to do effectively, C is able to verify that it's being transferred by the person that it's already in conversation with. If you crypt graftly verify that, without any infrastructure or anything like that. So it actually is deploy able with crypt graph. And it doesn't require anything from anyone. And that's pretty cool, I think.
NEW SPEAKER: I like the S MIME idea, I think that one of the things that we also need to be sensitive about is that, you know, for example, A B and C may all be, you know, s let's say two of the those three parties may wish to remain a anonymous with respect to each other. And there's sort of, some additional work that would need to be done, you know, like we may need to generate an additional self serve that maintains another a anonymous entity.
NEW SPEAKER: Could you --
NEW SPEAKER: Could you start enumerating those kind of things and give it a framework so that we can explore it concretely.
NEW SPEAKER: On the list?
NEW SPEAKER: Or just mail it to me if not the list, but the list would be better.
NEW SPEAKER: Yes.
NEW SPEAKER: Any other comments? Is Alison still here?
Okay. Does this path look sane to you. If we start down this, do you think we have a reasonably high probability of hitting a target that that will fly?
NEW SPEAKER: I kept silent here because I don't know enough of the details to make any rationale judgments. As an observation, security is in general very much easier when you're dealing with two parties, and not three. Any time there's a man in the middle, an authorized man in the middle, you have a much more difficult problem of the first party knowing whether or not they can trust the third party.
Privacy consideration, of course might push you in the other direction, but, there will be drag. I'm not saying it's wrong.
NEW SPEAKER: Sure.
NEW SPEAKER: I'm just saying
(Several people talking.)
NEW SPEAKER: Are there
NEW SPEAKER: I don't know enough of the details of this to be qualified to express an opinion.
NEW SPEAKER: All right. Will you or, could you point at somebody that can go down that whole and get information back to me so that I don't waste time --
NEW SPEAKER: I will try to find a security person to work closely on this. SIP is one of the more difficult protocols to secure that we have in this organization.
NEW SPEAKER: Yes.
NEW SPEAKER: It's not likely to be an easy process.
NEW SPEAKER: Unfortunately, in those attended transfer kind of cases that you pointed to, we can sometimes reduce it down to two parties. There are really two parties that have a security association with one another, and that makes those inherently more secure than these other scenarios where it's like three way.
NEW SPEAKER: Okay.
NEW SPEAKER: That's good.
NEW SPEAKER: Okay. Two points to make it before everybody runs off. One, we didn't get to path. So if you want to talk about path, come to three GP P ad hoc at 5:30 Wednesday in the dual lieutenant room. Today. Second point, if you have presented slides, I need them and we have a new form to fill out for the secretary so we can get them into the proceedings, so come see me about that too. Thanks.

Updated 28 Mar 2002 01:15:50 -0600