summaryrefslogtreecommitdiff
path: root/third_party/heimdal/doc/standardisation/draft-srp.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-srp.txt')
-rw-r--r--third_party/heimdal/doc/standardisation/draft-srp.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-srp.txt b/third_party/heimdal/doc/standardisation/draft-srp.txt
new file mode 100644
index 00000000000..9c4cc954d7f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-srp.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group Love Hornquist Astrand
+<draft-hornquist-astrand-krb-wg-srp.txt> Stockholms universitet
+Internet-Draft December, 2003
+Expire in six months
+
+ Using SRP for Initial Authentication in Kerberos
+
+Status of this Memo
+
+ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
+
+ This memo provides information for the Internet community. ...
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved. ...
+
+
+Abstract
+
+ This document describes how to use SRP as a preauthentication
+ mechanism in Kerberos 5 [RFC1510]. This mechanism makes the initial
+ ticket request and response secure against dictionary attacks on
+ users passwords.
+
+Introduction
+
+ Kerberos without preauthentication make the protocol susceptible to
+ both to password dictionary attacks on initial tickets. There are
+ several pre-authentication mechanisms that tries to solve and/or
+ minimize this problem.
+
+ Encrypted time stamp have the same problem as Kerberos without
+ preauthentication, opportunities of the attacker to get key material
+ is only fewer. SAM require hardware token and typically, for most
+ SAM types, still require the user to have a password since they don't
+ provide enough key-material for Kerberos to encrypt the response
+ with. PKINIT large and complicated, and like SAM often require
+ hardware. Extra-tgt requires infrastructure to use, a key/bootstrap
+ must be present on each host that the users are expected to use.
+
+ The dictionary attack can also be solved by forcing the users to
+ select good password.
+
+ XXX Jacques' DH preauth ?
+ XXX tls protected as-req
+
+ SRP, Secure Remote Password protocol, [RFC2945], is a password
+
+
+
+Hornquist Astrand [Page 1]
+
+Internet Draft December, 2003
+
+
+ authentication and key-exchange protocol that can be used over
+ untrusted networks. SRP is designed to be resistable to dictionary
+ attacks (both by passive and active attackers).
+
+Specification
+
+ This document is based on SRP-6.
+
+ XXX read and think about rfc2944 (SRP over telnet)
+
+ SRP + Kerberos 5 preauthentication
+
+ Krb-srp-cookie in the protocol to enable the server be stateless.
+
+ TBA KRB-SRP-PREAUTH number
+
+ - Client send the AS-REQ
+
+ - Server looks up the principal, and finds N, g, v, salt, H. Then
+ the server generates the random number b and calculate B. All
+ operations are performed modulus N.
+
+ B = 3v + g^b
+
+ and sends back a KRB-SRP-CHALLENGE md-data in a KRB-ERROR. If the
+ server is stateless, it can store the information (encrypted) it
+ needs in krb-srp-cookie.
+
+ - If the client chooses to use the SRP preauthentication mechanism it
+ sends back KRB-SRP-CLIENT-RESPONSE. If krb-srp-cookie is present in
+ KRB-SRP-CHALLENGE its copied to KRB-SRP-CLIENT-RESPONSE. The client
+ generates the random number a and calculates
+
+ A = g^a
+ S = (B - 3g^x)^(a+ux)
+ M1 = H(DER(A) | DER(B) | DER(S))
+
+ u is H(DER(A) | DER(B)), where DER(n) is the n encoded with the
+ integer tag.
+
+ The client then it calculates the shared key K
+
+ K = s-to-key-bytes(S)
+
+ KRB-SRP-CLIENT-RESPONSE-ENC-DATA is filled in by the client,
+ encrypted with the shared key K
+
+ XXX should a keyed checksum just be used instead ?
+
+
+
+Hornquist Astrand [Page 2]
+
+Internet Draft December, 2003
+
+
+ XXX does this replace the need for M1
+
+ - When the server receives the KRB-SRP-CLIENT-RESPONSE response it
+ calculates
+
+ S = (Av^u)^b
+
+ and the shared key K,
+
+ K = s-to-key-bytes(S)
+
+ verifies the content in krb-srp-enc, and M1. If everything checks
+ out ok, the server sends back the AS-REP. The key that the AS-REP is
+ encrypted with is the SRP session key, K.
+
+ XXX Should the server send back M2 ?
+
+ s-to-key defined as:
+
+ b = DER(S)
+ if length of b is even, drop first char
+ b1 = H(b[0] | b[2] | b[4] | ...)
+ b2 = H(b[1] | b[3] | b[5] | ...)
+ K = random-to-key(b1 | b2).
+
+ random-to-key is the random to key function in [KCRYPTO].
+
+ASN.1 specification
+
+ XXX Krb-Nonce
+
+ KERBEROS-PREAUTH-SRP DEFINITIONS ::=
+
+ BEGIN
+
+ IMPORTS Checksum, Krb-Nonce FROM krb5;
+
+ KRB-SRP-CHALLENGE ::= SEQUENCE {
+ krb-srp-salt[0] OCTET STRING,
+ krb-srp-N[1] INTEGER,
+ krb-srp-g[2] INTEGER,
+ krb-srp-B[3] INTEGER,
+ krb-srp-hash[4] OBJECT IDENTIFIER,
+ krb-srp-flags[5] INTEGER (SIZE 4),
+ krb-srp-cookie[6] OCTET STRING OPTIONAL -- must include nonce ?
+ }
+
+ -- flags: "use combined s2k + srp key" ?
+
+
+
+Hornquist Astrand [Page 3]
+
+Internet Draft December, 2003
+
+
+ KRB-SRP-CLIENT-RESPONSE ::= SEQUENCE {
+ krb-srp-A[0] INTEGER,
+ krb-srp-M1[1] OCTET STRING,
+ krb-srp-hash[2] OBJECT IDENTIFIER,
+ krb-srp-enc[3] EncryptedData, -- bind nonce to pa
+ krb-srp-cookie[4] OCTET STRING OPTIONAL
+ }
+
+ KRB-SRP-CLIENT-RESPONSE-ENC-DATA :: SEQUENCE {
+ krb-srp-checksum[0] Checksum,
+ krb-srp-flags[1] INTEGER (SIZE 4),
+ krb-srp-nonce[2] Krb-Nonce
+ }
+
+ KRB-SRP-SERVER-RESPONSE ::= SEQUENCE {
+ krb-srp-M2[0] OCTET STRING
+ }
+
+ END
+
+Issues
+
+ send group/generator by name ?
+
+ how to bind request to pa data ?
+
+ what key should be used, the key from SRP, or the compiled key from
+ s2k + SRP, right now its a flag.
+
+Requirements on the KDC
+
+ The KDC needs to know more information for each principal. At least
+ the KDC needs to store:
+
+ N, the safe prime
+ g, the generator
+ v, the password verifier
+ salt, that salt that the principal used to form the verifier, v
+ H, hash function used to form the verifier, v
+
+ Also, since the KDC no longer have a list of keys, and thus an
+ implicit list what encryption types the principal is allowed use, it
+ needs to have a list for all the encryption types a user is allowed
+ to use with SRP preauthentication mechanism.
+
+Security considerations
+
+ SRP
+
+
+
+Hornquist Astrand [Page 4]
+
+Internet Draft December, 2003
+
+
+ see Security considerations in Nisses SSH SRP draft.
+
+ Kerberos
+
+ Preauthentication
+
+ SRP preauthentication mechanism doesn't require the client to compute
+ something before the server sends "expensive" cryptographic
+ operations.
+
+ Preauthentication have the problem that the response is not
+ authenticated, so a active attacker can modify that response from the
+ KDC to remove SRP to have the client choose a weaker initial
+ authentication method.
+
+References
+
+ [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+ Authentication Service (V5)", RFC 1510, September 1993.
+
+ [SRP] T. Wu, "The Secure Remote Password Protocol", In Proceedings of
+ the 1998 ISOC Network and Distributed System Security Symposium, San
+ Diego, CA, pp. 97-111.
+
+ [RFC2945] Wu, T, "The SRP Authentication and Key Exchange System",
+ RFC2945, September 2000.
+
+ [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+ Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in
+ progress.
+
+Author's Address
+
+ Love Hornquist Astrand
+ Enheten for it och media
+ Stockholms universitet
+ S-106 91 STOCKHOLM
+ SWEDEN
+
+ EMail: lha@it.su.se
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved. ...
+
+
+
+
+
+
+
+Hornquist Astrand [Page 5]
+