[Emu] Issue: Encoding of NAIs within EAP-TLS certificates
RFC 3280 Section 4.1.2.6 says: Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. This leads me to believe that the statement below from Section 5.2 isn't quite right: Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. An RFC 3280-equivalent statement would be: Conforming implementations generating new certificates with network access identifiers MUST use the rfc822Name in the subject alternative name field to describe such identities. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue
-Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 7:40 AM To: Joseph Salowey (jsalowey); emu@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue RFC 3280 says: In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute. The attribute value for EmailAddress is of type IA5String to permit inclusion of the character '@', which is not part of the PrintableString character set. EmailAddress attribute values are not case sensitive (e.g., [EMAIL PROTECTED] is the same as [EMAIL PROTECTED]). Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. Based on this, if the certificate is encoding an NAI as a name, then the subject alternative name field MUST be used. Simultaneous inclusion of the NAI within an EmailAddress attribute in the subject distinguished name is deprecated, but permitted. So in the case where an NAI is encoded in the subjectAltName field, the subject DN would be a duplicate, no? [Joe] No, the EmailAddress RDN may not be included in the Subject DN. Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 16:37:08 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; emu@ietf.org CC: I agree, my intent wasn't to mandate a DN, my text needs to be improved. Does this help? It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject distinguished name is non-empty then it SHOULD be exported within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. Thanks, Joe -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 4:17 PM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Your right, there can be only one distinguished name. However there are also cases where there are more than one subjectAltName may be present with a empty DN also; I don't think mandating a DN is a good idea since 3280 doesn't do that. Ryan -Original Message- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 3:53 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Hi Bernard, I don't think a valid certificate can have multiple subject distinguished names. I think it would be more in line with RFC 3280 to treat the subject distinguished name as part of the valid name set if it is non-empty. It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to a non-empty subject distinguished name. EAP-TLS implementations SHOULD export a non-empty Subject distinguished name along with all the subjectAltName fields within Peer-Ids or Server-Ids; all of the exported Peer-Ids and Server-Ids are considered valid. Joe -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 10:05 PM To: emu@ietf.org Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue It has been pointed out that an EAP-TLS certificate can contain multiple subject or subjectAltName fields. To address this, I propose that we add the following text to Section 5.2: It is possible for more than one subjectAltName field to be present in a peer or server certificate. Where more than one subjectAltName field is present in a certificate, EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids; all of the exported Peer-Ids and Server-Ids are considered valid. Similarly, if more than one subject field is present in a peer or server certificate, and no subjectAltName field is present, then EAP-TLS implementations SHOULD export all of the subject fields within Peer-Ids and Server-Ids; all of the exported Peer-Ids and
RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
Not all identities are an RFC822 Name so using an RFC822 name is not always appropriate. If you are going to include an RFC822 name in the certificate then it should be in the RFC822 SubjecAltName. The Subject distinguished name may include other name elements. -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 7:54 AM To: emu@ietf.org Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates RFC 3280 Section 4.1.2.6 says: Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. This leads me to believe that the statement below from Section 5.2 isn't quite right: Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. An RFC 3280-equivalent statement would be: Conforming implementations generating new certificates with network access identifiers MUST use the rfc822Name in the subject alternative name field to describe such identities. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
Right. The RFC 3280 statement only applies to RFC 822 names. That's why I think that the text should focus on those names. Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Thu, 7 Jun 2007 08:57:49 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; emu@ietf.org Not all identities are an RFC822 Name so using an RFC822 name is not always appropriate. If you are going to include an RFC822 name in the certificate then it should be in the RFC822 SubjecAltName. The Subject distinguished name may include other name elements. -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 7:54 AM To: emu@ietf.org Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates RFC 3280 Section 4.1.2.6 says:Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted.This leads me to believe that the statement below from Section 5.2 isn't quite right: Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. An RFC 3280-equivalent statement would be:Conforming implementations generating new certificates with network access identifiers MUST use the rfc822Name in the subject alternative name field to describe such identities. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] Issue with RFC 2716bis key generation
It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced. The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption,client.random || server.random) The issue here is that RFC 2716 Section 3.5 specifies a different approach: MSK(0,63) = first 64 octets of: TLS-PRF-128(TMS, client EAP encryption,client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption,client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption,client.random || server.random) With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follows: Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, client EAP encryption, random) is computed up to 128 bytes, and the value PRF(, client EAP encryption, random) is computed up to 64 bytes (where is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
Is there any reason not to use the approach in RFC2716Bis? This guarantees backward compatibility and require less computation. From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 3:05 PM To: emu@ietf.org Subject: [Emu] Issue with RFC 2716bis key generation It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced. The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) The issue here is that RFC 2716 Section 3.5 specifies a different approach: MSK(0,63) = first 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follows: Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, client EAP encryption, random) is computed up to 128 bytes, and the value PRF(, client EAP encryption, random) is computed up to 64 bytes (where is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
The problem is that RFC 2716 specifies the use of TLS-PRF-128. If TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF), then RFC 2716bis implementations will not interoperate with RFC 2716 implementations. Subject: RE: [Emu] Issue with RFC 2716bis key generationDate: Thu, 7 Jun 2007 17:02:40 -0400From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: Is there any reason not to use the approach in RFC2716Bis? This guarantees backward compatibility and require less computation. From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 3:05 PMTo: [EMAIL PROTECTED]: [Emu] Issue with RFC 2716bis key generation It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced. The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption,client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption,client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption,client.random || server.random)The issue here is that RFC 2716 Section 3.5 specifies a different approach:MSK(0,63) = first 64 octets of: TLS-PRF-128(TMS, client EAP encryption,client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption,client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follows:Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, client EAP encryption, random) is computed up to 128 bytes, and the value PRF(, client EAP encryption, random) is computed up to 64 bytes (where is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
Is there a reason why we changed to TLS-PRF-128 for the MSK? Is this a huge issue given that there are not likely any existing implementations of EAP-TLS using TLS 1.2? Joe -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 12:05 PM To: emu@ietf.org Subject: [Emu] Issue with RFC 2716bis key generation It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced. The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) The issue here is that RFC 2716 Section 3.5 specifies a different approach: MSK(0,63) = first 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follows: Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, client EAP encryption, random) is computed up to 128 bytes, and the value PRF(, client EAP encryption, random) is computed up to 64 bytes (where is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
