Authenticated Identity

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)
• Doesnt 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.