oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

newer drafts

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8048 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-03-18 02:04:53 +00:00
parent 89ac710427
commit 9a3cefb99d
3 changed files with 3980 additions and 3789 deletions
Download Patch File Download Diff File Expand all files Collapse all files

387
doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt → doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
View File

@@ -1,12 +1,12 @@
INTERNET-DRAFT Brian Tung INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman
Updates: RFC 1510 ISI Updates: RFC 1510 USC/ISI
expires April 30, 2000 Matthew Hur expires September 15, 2000 Matthew Hur
CyberSafe Corporation CyberSafe Corporation
Ari Medvinsky Ari Medvinsky
Excite Keen.com, Inc.
Sasha Medvinsky Sasha Medvinsky
General Instrument Motorola
John Wray John Wray
Iris Associates, Inc. Iris Associates, Inc.
Jonathan Trostle Jonathan Trostle
@@ -41,7 +41,7 @@ expires April 30, 2000 Matthew Hur
munnari.oz.au (Pacific Rim). munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15,
2000. Please send comments to the authors. 2000. Please send comments to the authors.
1. Abstract 1. Abstract
@@ -181,7 +181,7 @@ expires April 30, 2000 Matthew Hur
In many cases, PKINIT requires the encoding of the X.500 name of a In many cases, PKINIT requires the encoding of the X.500 name of a
certificate authority as a Realm. When such a name appears as certificate authority as a Realm. When such a name appears as
a ream it will be represented using the "other" form of the realm a realm it will be represented using the "other" form of the realm
name as specified in the naming constraints section of RFC1510. name as specified in the naming constraints section of RFC1510.
For a realm derived from an X.500 name, NAMETYPE will have the value For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC2253. The full realm name will appear as follows: X500-RFC2253. The full realm name will appear as follows:
@@ -235,12 +235,62 @@ expires April 30, 2000 Matthew Hur
name-string[1] SEQUENCE OF GeneralString name-string[1] SEQUENCE OF GeneralString
} }
For the purposes of encoding an X.500 name within this structure, For the purposes of encoding an X.500 name as a Kerberos name for
the name-string shall be encoded as a single GeneralString. use in Kerberos structures, the name-string shall be encoded as a
single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL,
as noted above. All Kerberos names must conform to validity
requirements as given in RFC 1510. Note that name mapping may be
required or optional, based on policy.
Note that name mapping may be required or optional based on We also define the following similar ASN.1 structure:
policy. All names must conform to validity requirements as given
in RFC 1510. CertPrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF UTF8String
}
When a Kerberos PrincipalName is to be placed within an X.509 data
structure, the CertPrincipalName structure is to be used, with the
name-string encoded as a single UTF8String. The name-type should be
as identified in the original PrincipalName structure. The mapping
between the GeneralString and UTF8String formats can be found in
[19].
The following rules relate to the the matching of PrincipalNames (or
corresponding CertPrincipalNames) with regard to the PKI name
constraints for CAs as laid out in RFC 2459 [15]. In order to be
regarded as a match (for permitted and excluded name trees), the
following must be satisfied.
1. If the constraint is given as a user plus realm name, or
as a user plus instance plus realm name (as specified in
RFC 1510), the realm name must be valid (see 2.a-d below)
and the match must be exact, byte for byte.
2. If the constraint is given only as a realm name, matching
depends on the type of the realm:
a. If the realm contains a colon (':') before any equal
sign ('='), it is treated as a realm of type Other,
and must match exactly, byte for byte.
b. Otherwise, if the realm contains an equal sign, it
is treated as an X.500 name. In order to match, every
component in the constraint MUST be in the principal
name, and have the same value. For example, 'C=US'
matches 'C=US/O=ISI' but not 'C=UK'.
c. Otherwise, if the realm name conforms to rules regarding
the format of DNS names, it is considered a realm name of
type Domain. The constraint may be given as a realm
name 'FOO.BAR', which matches any PrincipalName within
the realm 'FOO.BAR' but not those in subrealms such as
'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
matches PrincipalNames in subrealms of the form
'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
d. Otherwise, the realm name is invalid and does not match
under any conditions.
3.1.1. Encryption and Key Formats 3.1.1. Encryption and Key Formats
@@ -330,16 +380,18 @@ expires April 30, 2000 Matthew Hur
PA-PK-AS-REQ ::= SEQUENCE { PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14 -- PA TYPE 14
signedAuthPack [0] SignedData signedAuthPack [0] SignedData
-- defined in CMS [11] -- Defined in CMS [11];
-- AuthPack (below) defines the data -- AuthPack (below) defines the
-- that is signed -- data that is signed.
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
-- CAs that the client trusts -- This is a list of CAs that the
-- client trusts and that certify
-- KDCs.
kdcCert [2] IssuerAndSerialNumber OPTIONAL kdcCert [2] IssuerAndSerialNumber OPTIONAL
-- as defined in CMS [11] -- As defined in CMS [11];
-- specifies a particular KDC -- specifies a particular KDC
-- certificate if the client -- certificate if the client
-- already has it; -- already has it.
encryptionCert [3] IssuerAndSerialNumber OPTIONAL encryptionCert [3] IssuerAndSerialNumber OPTIONAL
-- For example, this may be the -- For example, this may be the
-- client's Diffie-Hellman -- client's Diffie-Hellman
@@ -361,29 +413,38 @@ expires April 30, 2000 Matthew Hur
} }
Usage of SignedData: Usage of SignedData:
The SignedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF. The SignedData data type is specified in the Cryptographic
- The encapContentInfo field must contain the PKAuthenticator Message Syntax, a product of the S/MIME working group of the
and, optionally, the client's Diffie Hellman public value. IETF. The following describes how to fill in the fields of
- The eContentType field shall contain the OID value for this data:
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1) 1. The encapContentInfo field must contain the PKAuthenticator
- The eContent field is data of the type AuthPack (below). and, optionally, the client's Diffie Hellman public value.
- The signerInfos field contains the signature of AuthPack.
- The Certificates field, when non-empty, contains the client's a. The eContentType field shall contain the OID value for
certificate chain. If present, the KDC uses the public key from pkdata: iso (1) org (3) dod (6) internet (1) security (5)
the client's certificate to verify the signature in the request. kerberosv5 (2) pkinit (3) pkdata (1)
Note that the client may pass different certificates that are used
for signing or for encrypting. Thus, the KDC may utilize a b. The eContent field is data of the type AuthPack (below).
different client certificate for signature verification than the
one it uses to encrypt the reply to the client. For example, the 2. The signerInfos field contains the signature of AuthPack.
client may place a Diffie-Hellman certificate in this field in
order to convey its static Diffie Hellman certificate to the KDC to 3. The Certificates field, when non-empty, contains the client's
enable static-ephemeral Diffie-Hellman mode for the reply; in this certificate chain. If present, the KDC uses the public key
case, the client does NOT place its public value in the AuthPack from the client's certificate to verify the signature in the
(defined below). As another example, the client may place an RSA request. Note that the client may pass different certificate
encryption certificate in this field. However, there must always chains that are used for signing or for encrypting. Thus,
be (at least) a signature certificate. the KDC may utilize a different client certificate for
signature verification than the one it uses to encrypt the
reply to the client. For example, the client may place a
Diffie-Hellman certificate in this field in order to convey
its static Diffie Hellman certificate to the KDC to enable
static-ephemeral Diffie-Hellman mode for the reply; in this
case, the client does NOT place its public value in the
AuthPack (defined below). As another example, the client may
place an RSA encryption certificate in this field. However,
there must always be (at least) a signature certificate.
AuthPack ::= SEQUENCE { AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator, pkAuthenticator [0] PKAuthenticator,
@@ -503,7 +564,13 @@ expires April 30, 2000 Matthew Hur
Even if all succeeds, the KDC may--for policy reasons--decide not Even if all succeeds, the KDC may--for policy reasons--decide not
to trust the client. In this case, the KDC returns an error message to trust the client. In this case, the KDC returns an error message
of type KDC_ERR_CLIENT_NOT_TRUSTED. of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
the presence or absence of an Enhanced Key Usage (EKU) OID within
the certificate extensions. The rules regarding acceptability of
an EKU sequence (or the absence of any sequence) are a matter of
local policy. For the benefit of implementers, we define a PKINIT
EKU OID as the following: iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
If a trust relationship exists, the KDC then verifies the client's If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error signature on AuthPack. If that fails, the KDC returns an error
@@ -554,7 +621,7 @@ expires April 30, 2000 Matthew Hur
the subjectAltName version 3 extension , that name may utilize the subjectAltName version 3 extension , that name may utilize
KerberosName as defined below, or, in the case of an S/MIME KerberosName as defined below, or, in the case of an S/MIME
certificate [17], may utilize the email address. If the KDC certificate [17], may utilize the email address. If the KDC
is presented with as S/MIME certificate, then the email address is presented with an S/MIME certificate, then the email address
within subjectAltName will be interpreted as a principal and realm within subjectAltName will be interpreted as a principal and realm
separated by the "@" sign, or as a name that needs to be separated by the "@" sign, or as a name that needs to be
canonicalized. If the resulting name does not correspond to a canonicalized. If the resulting name does not correspond to a
@@ -604,34 +671,47 @@ expires April 30, 2000 Matthew Hur
} }
Usage of SignedData: Usage of SignedData:
If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
provides authenticated Diffie-Hellman parameters of the KDC. The When the Diffie-Hellman option is used, dhSignedData in
reply key used to encrypt part of the KDC reply message is derived PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
from the Diffie-Hellman exchange: of the KDC. The reply key used to encrypt part of the KDC reply
- Both the KDC and the client calculate a secret value (g^ab mod p), message is derived from the Diffie-Hellman exchange:
where a is the client's private exponent and b is the KDC's
private exponent. 1. Both the KDC and the client calculate a secret value
- Both the KDC and the client take the first N bits of this secret (g^ab mod p), where a is the client's private exponent and
value and convert it into a reply key. N depends on the reply key b is the KDC's private exponent.
type.
- If the reply key is DES, N=64 bits, where some of the bits are 2. Both the KDC and the client take the first N bits of this
replaced with parity bits, according to FIPS PUB 74. secret value and convert it into a reply key. N depends on
- If the reply key is (3-key) 3-DES, N=192 bits, where some of the the reply key type.
bits are replaced with parity bits, according to FIPS PUB 74.
- The encapContentInfo field must contain the KdcDHKeyInfo as 3. If the reply key is DES, N=64 bits, where some of the bits
defined below. are replaced with parity bits, according to FIPS PUB 74.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549) 4. If the reply key is (3-key) 3-DES, N=192 bits, where some
pkcs(1) pkcs7(7) data(1) of the bits are replaced with parity bits, according to
- The certificates field must contain the certificates necessary FIPS PUB 74.
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in 5. The encapContentInfo field must contain the KdcDHKeyInfo as
the PA-PK-AS-REQ. This field may be empty if the client did defined below.
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client a. The eContentType field shall contain the OID value for
already possesses the KDC's certificate). pkdata: iso (1) org (3) dod (6) internet (1) security (5)
- The signerInfos field is a SET that must contain at least one kerberosv5 (2) pkinit (3) pkdata (1)
member, since it contains the actual signature.
b. The eContent field is data of the type KdcDHKeyInfo
(below).
6. The certificates field must contain the certificates
necessary for the client to establish trust in the KDC's
certificate based on the list of trusted certifiers sent by
the client in the PA-PK-AS-REQ. This field may be empty if
the client did not send to the KDC a list of trusted
certifiers (the trustedCertifiers field was empty, meaning
that the client already possesses the KDC's certificate).
7. The signerInfos field is a SET that must contain at least
one member, since it contains the actual signature.
KdcDHKeyInfo ::= SEQUENCE { KdcDHKeyInfo ::= SEQUENCE {
-- used only when utilizing Diffie-Hellman -- used only when utilizing Diffie-Hellman
@@ -644,42 +724,60 @@ expires April 30, 2000 Matthew Hur
} }
Usage of EnvelopedData: Usage of EnvelopedData:
The EnvelopedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF. The EnvelopedData data type is specified in the Cryptographic
It contains an temporary key encrypted with the PKINIT Message Syntax, a product of the S/MIME working group of the
client's public key. It also contains a signed and encrypted IETF. It contains a temporary key encrypted with the PKINIT
reply key. client's public key. It also contains a signed and encrypted
- The originatorInfo field is not required, since that information reply key.
may be presented in the signedData structure that is encrypted
within the encryptedContentInfo field. 1. The originatorInfo field is not required, since that
- The optional unprotectedAttrs field is not required for PKINIT. information may be presented in the signedData structure
- The recipientInfos field is a SET which must contain exactly one that is encrypted within the encryptedContentInfo field.
member of the KeyTransRecipientInfo type for encryption
with an RSA public key. 2. The optional unprotectedAttrs field is not required for
- The encryptedKey field (in KeyTransRecipientInfo) contains PKINIT.
the temporary key which is encrypted with the PKINIT client's
public key. 3. The recipientInfos field is a SET which must contain exactly
- The encryptedContentInfo field contains the signed and encrypted one member of the KeyTransRecipientInfo type for encryption
reply key. with an RSA public key.
- The contentType field shall contain the OID value for
id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) a. The encryptedKey field (in KeyTransRecipientInfo)
pkcs(1) pkcs7(7) signedData(2) contains the temporary key which is encrypted with the
- The encryptedContent field is encrypted data of the CMS type PKINIT client's public key.
signedData as specified below.
- The encapContentInfo field must contains the ReplyKeyPack. 4. The encryptedContentInfo field contains the signed and
- The eContentType field shall contain the OID value for encrypted reply key.
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1) a. The contentType field shall contain the OID value for
- The eContent field is data of the type ReplyKeyPack (below). id-signedData: iso (1) member-body (2) us (840)
- The certificates field must contain the certificates necessary rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in b. The encryptedContent field is encrypted data of the CMS
the PA-PK-AS-REQ. This field may be empty if the client did type signedData as specified below.
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client i. The encapContentInfo field must contains the
already possesses the KDC's certificate). ReplyKeyPack.
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature. * The eContentType field shall contain the OID value
for pkdata: iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkdata (1)
* The eContent field is data of the type ReplyKeyPack
(below).
ii. The certificates field must contain the certificates
necessary for the client to establish trust in the
KDC's certificate based on the list of trusted
certifiers sent by the client in the PA-PK-AS-REQ.
This field may be empty if the client did not send
to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the
client already possesses the KDC's certificate).
iii. The signerInfos field is a SET that must contain at
least one member, since it contains the actual
signature.
ReplyKeyPack ::= SEQUENCE { ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman -- not used for Diffie-Hellman
@@ -715,26 +813,27 @@ expires April 30, 2000 Matthew Hur
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
GeneralName ::= CHOICE { GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME, otherName [0] OtherName,
... ...
} }
OTHER-NAME ::= TYPE-IDENTIFIER OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id
}
In this definition, otherName is a name of any form defined as an For the purpose of specifying a Kerberos principal name, the value
instance of the OTHER-NAME information object class. For the purpose in OtherName shall be a KerberosName as defined in RFC 1510, but with
of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will the PrincipalName replaced by CertPrincipalName as mentioned in
be chosen and replaced by the type KerberosName: Section 3.1:
KerberosName ::= SEQUENCE { KerberosName ::= SEQUENCE {
realm [0] Realm, realm [0] Realm,
-- as defined in RFC 1510 principalName [1] CertPrincipalName -- defined above
principalName [1] PrincipalName,
-- as defined in RFC 1510
} }
This specific syntax is identified within subjectAltName by setting This specific syntax is identified within subjectAltName by setting
the OID id-ce-subjectAltName to krb5PrincipalName, where (from the the type-id in OtherName to krb5PrincipalName, where (from the
Kerberos specification) we have Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1) krb5 OBJECT IDENTIFIER ::= { iso (1)
@@ -765,11 +864,11 @@ expires April 30, 2000 Matthew Hur
to be implemented in order to comply with the proposed standard. to be implemented in order to comply with the proposed standard.
Below is a list of the required algorithms: Below is a list of the required algorithms:
- Diffie-Hellman public/private key pairs * Diffie-Hellman public/private key pairs
- utilizing Diffie-Hellman ephemeral-ephemeral mode * utilizing Diffie-Hellman ephemeral-ephemeral mode
- SHA1 digest and DSA for signatures * SHA1 digest and DSA for signatures
- 3-key triple DES keys derived from the Diffie-Hellman Exchange * 3-key triple DES keys derived from the Diffie-Hellman Exchange
- 3-key triple DES Temporary and Reply keys * 3-key triple DES Temporary and Reply keys
4. Logistics and Policy 4. Logistics and Policy
@@ -793,11 +892,12 @@ expires April 30, 2000 Matthew Hur
First of all, PKINIT introduces a new trust model, where KDCs do not First of all, PKINIT introduces a new trust model, where KDCs do not
(necessarily) certify the identity of those for whom they issue (necessarily) certify the identity of those for whom they issue
tickets. PKINIT does allow KDCs to act as their own CAs, in order tickets. PKINIT does allow KDCs to act as their own CAs, in the
to simplify key management, but one of the additional benefits is to limited capacity of self-signing their certificates, but one of the
align Kerberos authentication with a global public key additional benefits is to align Kerberos authentication with a global
infrastructure. Anyone using PKINIT in this way must be aware of public key infrastructure. Anyone using PKINIT in this way must be
how the certification infrastructure they are linking to works. aware of how the certification infrastructure they are linking to
works.
Secondly, PKINIT also introduces the possibility of interactions Secondly, PKINIT also introduces the possibility of interactions
between different cryptosystems, which may be of widely varying between different cryptosystems, which may be of widely varying
@@ -837,16 +937,14 @@ expires April 30, 2000 Matthew Hur
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
Authentication in Kerberos. Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt
draft-ietf-cat-kerberos-pk-cross-04.txt
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
Kerberos. Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt
draft-ietf-cat-kerberos-anoncred-00.txt
[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
Tickets for Application Servers (PKTAPP). Public Key Utilizing Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt draft-ietf-cat-pktapp-02.txt
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed Using Public Key Cryptography. Symposium On Network and Distributed
@@ -898,6 +996,10 @@ expires April 30, 2000 Matthew Hur
[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
Protocol (v3), December 1997. Request for Comments 2251. Protocol (v3), December 1997. Request for Comments 2251.
[19] ITU-T (formerly CCITT) Information Processing Systems - Open
Systems Interconnection - Specification of Abstract Syntax Notation
One (ASN.1) Rec. X.680 ISO/IEC 8824-1
8. Acknowledgements 8. Acknowledgements
Some of the ideas on which this proposal is based arose during Some of the ideas on which this proposal is based arose during
@@ -912,7 +1014,7 @@ expires April 30, 2000 Matthew Hur
9. Expiration Date 9. Expiration Date
This draft expires April 30, 2000. This draft expires September 15, 2000.
10. Authors 10. Authors
@@ -932,14 +1034,14 @@ expires April 30, 2000 Matthew Hur
E-mail: matt.hur@cybersafe.com E-mail: matt.hur@cybersafe.com
Ari Medvinsky Ari Medvinsky
Excite Keen.com, Inc.
555 Broadway 150 Independence Drive
Redwood City, CA 94063 Menlo Park CA 94025
Phone +1 650 569 2119 Phone: +1 650 289 3134
E-mail: amedvins@excitecorp.com E-mail: ari@keen.com
Sasha Medvinsky Sasha Medvinsky
General Instrument Motorola
6450 Sequence Drive 6450 Sequence Drive
San Diego, CA 92121 San Diego, CA 92121
Phone +1 619 404 2825 Phone +1 619 404 2825
@@ -955,4 +1057,3 @@ expires April 30, 2000 Matthew Hur
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
E-mail: jtrostle@cisco.com E-mail: jtrostle@cisco.com

7366
doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt → doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
View File

File diff suppressed because it is too large Load Diff

16
doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt → doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
View File

@@ -1,7 +1,7 @@
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-01.txt Microsoft draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft
February 2000 Jonathan Trostle March 2000 Jonathan Trostle
Cisco Systems Cisco Systems
John Brezak John Brezak
Microsoft Microsoft
@@ -132,9 +132,11 @@ Request Message
} }
NewPasswdOrKeys :: = CHOICE { NewPasswdOrKeys :: = CHOICE {
passwords[0] KeySequence, passwords[0] PasswordSequence,
keyseq[1] PasswordSequence keyseq[1] KeySequences
}
KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE { KeySequence :: = SEQUENCE {
key[0] EncryptionKey, key[0] EncryptionKey,
@@ -146,7 +148,7 @@ Request Message
newpasswd[0] OCTET STRING, newpasswd[0] OCTET STRING,
oldpasswd[1] OCTET STRING OPTIONAL oldpasswd[1] OCTET STRING OPTIONAL
-- oldpasswd always present for change password -- oldpasswd always present for change password
-- but not set password -- but not present for set password
} }
The server must verify the AP-REQ message, check whether the client The server must verify the AP-REQ message, check whether the client
@@ -295,7 +297,7 @@ Reply Message
5. Expiration Date 5. Expiration Date
This draft expires in August 2000. This draft expires in September 2000.
6. Authors' Addresses 6. Authors' Addresses
@@ -317,5 +319,7 @@ Reply Message
Bill Gossman Bill Gossman
Cybersafe Corporation Cybersafe Corporation
1605 NW Sammamish Rd.
Issaquah, WA 98027-5378
Email: bill.gossman@cybersafe.com Email: bill.gossman@cybersafe.com