SRV RR otherName

1
SRV RR otherName

• Stefan Santesson
• Microsoft

2
The ConceptRFC 2782
DNS Server
_service._protocol.domain.com
_service._protocol.domain.com host1.domain.com 192
.168.0.132
Service Host (host1.domain.com) (192.168.0.132)
Using service
Client
3
The Concept

• From RFC 2742
• Currently, one must either know the exact address
  of a server
• To contact it, or broadcast a question.
• The SRV RR allows administrators to use several
  servers for a
• Single domain, to move services from host to host
  with little
• fuss, and to designate some hosts as primary
  servers for a
• service and others as backups.
• Clients ask for a specific service/protocol for a
  specific
• domain and get back the names of any available
  servers.
• Example is discovery of a Kerberos KDC host but
  this could be used as a general mechanism for a
  variety of services.

4
The ThreatDNS spoofing
Spoofed DNS Server
_service._protocol.domain.com
_service._protocol.domain.com hostX.domain.com 192
.168.0.174
Hijacked Host (hostX.domain.com) (192.168.0.174)
Using service
Client
5
Proposal

• Submitted as draft-santesson-pkix-srvrr-00.txt
• Define a Subject Alt Name otherName for SRV RR
  query string (_service._protocol.domain).
• Example _ldap._tcp.example.com
• otherName structure
• id-on-sRVRRName OBJECT IDENTIFIER id-on
  ?
• SRVRRName UTF8String

6
Applicability Constraints

• From RFC 2782 I
• In general, it is expected that SRV records
  will be used by clients
• for applications where the relevant protocol
  specification indicates
• that clients should use the SRV record. Such
  specification MUST
• define the symbolic name to be used in the
  Service field of the SRV
• record as described below. It also MUST include
  security
• considerations. Service SRV records SHOULD NOT
  be used in the absence
• of such specification.
• Any use of SRV RR for host authentication MUST
  NOT be in conflict with any rules specified for
  deployed security protocols and
  application/service definitions.

7
Request

• Request that PKIX accept the task to define this
  SAN otherName so it can be referenced and used by
  other protocol specifications to support host
  authentication where applicable.

8
Path forward

• Correct known errors (IA5String -gt UTF8String)
• Submit as first pkix draft (00)
• Define appropriate constraints and security
  considerations
• Proceed as standards track
• WG last call after Vancouver IETF