1 / 5

Authenticated Identity

The document explains the format and mechanisms for Authentication Service, including SIP message integrity and encryption recommendations. It covers AIB format, AES encryption, and signing algorithms. The goal is to enhance SIP security and adoption of S/MIME.

irichardson
Download Presentation

Authenticated Identity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related