1. Authenticated Identity • Former draft-peterson-sip-identity-00 split into two drafts • One draft on the auth-id body format – a specification of a MIME body that could be used as an authentication token (draft-ietf-sip-auth • One draft on the authentication service mechanism – defining new status codes and practices for providing an authentication token (which might be auth-id body, or could be something else)

2. AuthID Body (AIB) • Format for a generic SIP authentication token • Carried as a MIME body within SIP requests or responses • Can be signed by a user agent, or potentially by an authentication service • Hopefully, adequate for needs of Referred-By • Now relies on either message/sip or message/sipfrag • If sipfrag, which headers need to be included to provide reference integrity and replay protection? • From, Call-ID, Date are MUST • To, Contact, CSeq are SHOULD • If we need more, this would be a good time to

3. Authentication Service • AuthService authenticates user agents, creates some sort of authentication token (as a MIME body), adds token to messages • Document describes three ways that body can be added to requests • (essentially) Redirection (push body back to UA) • Doesn’t work for responses, but seems best for requests • AuthService acts as B2BUA, adds body itself • Content-indirection (UA picks indirect URI that is populated by the AuthService) • This way is optimal for adding bodies to responses • Do we need to pick just one way? Or narrow this list down? • Normative support for AIB • Currently, none – do we need a normative statement?

4. AES and S/MIME • This is a piece of RFC3261 errata • Substitutes for a particular paragraph in 23.3 • Recommends changing the required encryption for the SIP profile of S/MIME from 3DES to AES • AES believed to have numerous advantages • Also, fixes some other nits in the way the SIP profile of S/MIME is described • Why worry about this now? Because S/MIME for SIP has yet to catch on – better fix it now than in the next rev of SIP • Lower footprint of AES might also help foster S/MIME adoption

5. AES Text • S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm, SHA1 as a digest algorithm, and AES as an encryption algorithm (as specified in [5]. For key wrap, S/MIME implementations MUST support the AES Key Wrap Algorithm ([6]). S/ MIME implementations of AES MUST support 128-bit AES keys, and SHOULD support 192 and 256-bit keys. Note that the S/MIME specification [4] mandates support for 3DES as an encryption algorithm, DH for key encryption and DSS as a signature algorithm. In the SIP profile of S/MIME, support for 3DES, DH and DSS is RECOMMENDED but not required. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for algorithms with the "SMIMECapabilities" attribute. • Transfer encoding used in S/MIME for SIP MUST use DER (Distinguished Encoding Rules), not the Basic ASN.1 Encoding Rules.