Prepared by Vijay Gurbani
SIP Session 2, 53rd IETF
Start 13:06 CST
Added AKA Digest and Path discusssion to the Agenda.
Agenda accepted.
Digest based authentication -- James Undery, Ubiquity
Quick run through of improvements to Digest authentication. UAC->UAS auth, UAC->Proxy authentication supported in the SIP spec. Our draft adds Proxy->UAS auth., bid-down protection, mutual auth., integrity. Added 3 new headers and 1 new response (492) for Proxy->UAS authentication Bid-down protection: prefix added to nonces, protects scheme and quality of detection.
Open issues: 1) No algorithm protection - if a hashing algo is broken, we need algo revocation. Proposal: make limitation explicit and rule that algo revocation is out of scope. 2) No negotiation of body integrity protection -- Proxies can't alter message bodies; Proposal : leave unchanged 3) No protection against weak passwords: Proposal - make limitation explicit, the solution is out of scope. 4) Client side can't initiate authentication 5) Forking and response collation issues - can't guarantee upstream entities see the challenges; response collation oriented towards success. Proposal: make limitations explicit.
Jon: What are you trying to accomplish as a UAS by authenticating your upstream proxy? James: You may trust the proxy but not the link between the proxy and the UAS (for example: a radio interface). Jon: So this is the integrity process, not an authentication one. James: Authentication and integrity are closely linked. Rohan: We need to think about if this is needed? Looks like it is solved by TLS anyway. We need to understand under what circumstances we will use this approach. Jonathan: With this you do not know which proxy -- one up or 2 up -- you want to authenticate.
Comment: You mention weak passwords; there are no strong passwords. You are unlikely to create a password that is not uncrackable, regardless of them appearing in the dictionary or not. Relying on a long random key is of no help. Christian: I would like to reinforce this point. Digest should be combined with strong authentication of the server, not on its own. Henning: when people talk about passwords, I wouldn't think that this is human generated; it is random string generated by some automata.
Dean: Are we going to close any of these today? If not, let's take this to the mailing list. Brian: This has been hanging on for a long time; are we going to extend digest or not fortify it anymore. I do not know how to go ahed. People are saying that digest is terrible, but others are saying that it is still useful. I do not see other alternatives on the floor. Christian: 2 forms with digest: 1 is if you are sending it as cleartext. 2 is when you are doing digest with a 3rd party you have not authenticated. Simple thing for us is to use digest only for REGISTER not anything else. Brian: But there is no other solution on the table. Allison: The security review for bis came out as digest being a very lightweight way to do user authentication is okay. There is a good possiblity of taking some time over this and making it better; maybe we should say that this document is not a WG document. We should discuss for the charter document something that exploits S/MIME. Rohan: There is some stuff in James' draft we can get consensus quickly; others may take some time. Allison: There is a huge deployment of digest. MD5 digest is known weak, but is not going to be thrown out. The topic we have now is not extending digest, but supporting some other password (a la AKA). For this document, consider what requirements it is meeting? Henning: One thing desperately needed in digest is registrar authentication. If we do something with digest at all, it must be this. Authenticating previous hops is nice, but not a known vulnerability we need solve now. Steven (3GPP): We do have a basic need to protect last hop integrity. We need to know what the intentions of the WG are towards digest. We need the direction very soon otherwise we are in a bind. Allison: Maybe, as Steven said, IPSec could be used for the short duration -- could be the right way of meeting the requirement. Maybe we can have 5 minutes on some other agenda to talk about this. Brian: We are not getting anywhere -- let's move on and take it to list.
Digest AKA Authentication - AKi Niemne
AKA is a shared secret based auth that uses a smart card like device. Previous proposal (...-eap-01.txt) got good reception at SLC.
Digest AKA resuses the digest scheme and uses the AKA parameters as input to the digest mechanism. AKA generates "one-time" passwords for Digest.
Issues: 1) "Choke point" attack - similar to the weak password attack. 2) Should we adopt draf-niemi-sipping-digest-aka-00? It provides message integrity and is complementary to vanilla digest used today.
Future: Will this become a work item for SIP WG? RFC category? There is some time pressure since 3GPP R5 is coming up. Can draft-niemi-digest-aka-00.txt be adopted as a solution?
Allison: This does not involve any SIP extensions; just the extension of HTTP methods. It is good to get the SIP people's knowledge. There is no need for it to be a WG document; you can take it to RFC as an individual submission. Brian: Is there sufficient interest in the group to make it a WG item, or continue as an individual submission? [Took hum; the hum for people who want to make it a WG document prevailed]. Miguel Garcia: why use a 3G specific technology which has no broad impact on the Internet? Adam seconded. [The chairs agreed that we may have to revisit this issue again]
Security Negotiation open issues, Jari Akko
Presented issues, asked what to do next. Brian: Anyone object to NOT go forward with this? [No one objected; this is part of SIP WG]
SIP Extensions for Network Asserted Caller Identity and Privacy within trusted networks - Fleming Andreason
Good list discussion 1 month ago; currently in WG LC. There have been some offline comment that have not been incorporated in the I-D yet.
Overview of changes: applicability statement (only suitable in the same admin domain, draft is for network-asserted identity, not user-asserted). Anonymity header got removed. Grammar fixes to be consistent with -09 bis.
Open issues: 1) Proxy handling of RP-ID received from untrusted entity (proxy or UA) 2 options: 1) if verifiable, set screen=yes 2) always remove untrusted RP-ID Option 1 seems more general then 2; Recommendation: Option 1.
This generated a lot of discussion, mostly revising around policies vs. protocols, network asserted identities vs. user asserted identities, (in)security of this I-D and why it will not be acceptable to IESG, and this being more for the benefit of 3GPP.
updated 20 Mar 2002 16:00 -0600