RE: draft-ietf-rap-rsvp-authsession documents

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

OK, w.r.t. documents:

     draft-ietf-rap-rsvp-authsession-03.txt
     draft-ietf-rap-session-auth-04.txt

it seems that the list of security related issues
that I posted over a week ago now are the most serious
items to address. Here are 2 more issues to take into
account when you re-edit the docs:

- When you talk about:

      5  UNICODE_DN   X.500 Distinguished name as defined
                      in RFC-2253 as a UNICODE string.

  we assume you mean a UTF-8 string?
  Might be good to make that clear.

- The replay protection that was added to rsvp-auth depends 
  on some clock synchronization (when there isn't a policy
  server). It would be good to specify that this requires
  that the system be using NTP or GPS.


Thanks,
Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: vrijdag 26 juli 2002 22:59
> To: Rap-wg (E-mail)
> Cc: Steve Bellovin (E-mail); Eric Rescorla (E-mail)
> Subject: FW: draft-ietf-rap-rsvp-authsession documents
> 
> 
> Authors/WG, 
> 
> The documents 
>     draft-ietf-rap-rsvp-authsession-03.txt
>     draft-ietf-rap-session-auth-04.txt
> were on the IESG agenda yesterday. 
> 
> I still have to collect some more feedback, so the below is 
> incomplete.
> 
> But the security issues are the most serious concern, so here it is
> for your response and corrections. I have added Steve Bellovin and
> Eric Rescorla on the cc: list, so that when you respond, they can
> also see the responses and react immediately/directly. Steve and Eric
> (as you can see below) have worked on the comments together.
> 
> Here we go:
> 
> --- comment from Steve
> 
> The new version is a lot better, and goes a long way towards 
> resolving 
> my objections.  But I don't think it specifies the authentication 
> process clearly enough for people to implement from the spec. 
>  I suspect
> we can resolve this by email in the next couple of days.
> 
> For shared secret and Kerberos, I *think* that the intent is 
> the key is 
> used only for an HMAC or similar algorithm such as a CBC-MAC.  That 
> should be stated explicitly.  It should also state that the expected 
> length of the authentication data is a preconfigured parameter, and 
> MUST match the data length in the message.  (There's an attack if the 
> data length is taken from the message; details are left as an 
> exercise 
> for the reader.)  
> 
> Be more explicit about what HMAC-MD5-96 means -- I don't believe that 
> that string is defined in 2104.  Why truncate to 96 bits?  
> It's secure 
> -- but it's done in IPsec because of boundary alignment 
> considerations.
> 
> Anyway -- the text should say something like this:
> 
> 
> 	If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR,
> 	FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use
> 	the identity to consult a table keyed by that identity.  The
> 	table should identify the cryptographic authentication algorithm
> 	to be used and the expected length of the authentication data.
> 	At a minimum, all implementations must support HMAC [RFC2104]
> 	using the MD5 [RFC1321] hash algorithm with an output length of
> 	16 bytes.  New algorithms may be added by the IETF standards
> 	process.
> 
> 	If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm
> 	table is consulted.  In this case, however, the key is taken
> 	from the Kerberos ticket.  At a minimum, all implementations
> 	must support the same HMAC hash described above.
> 
> 	Authentication is done as follows.  The entire message is
> 	constructed, excluding the length, type, and subtype fields
> 	of the AUTH DATA field.  Note that the message MUST include
> 	either a START_TIME or a SESSION_ID (See Section 9), to prevent
> 	replay attacks.  The output of the authentication algorithm,
> 	plus appropriate header information, is appended to the message.
> 
> 	Verification is done by a similar process; however, the receiver
> 	MUST verify that the indicated length of the authentication data
> 	is consistent with the configured table entry.
> 
> 
> Much more needs to be said about generating signatures to be verified 
> via an X.509 certificate.  I'm not 100% certain which RFCs need to be 
> cited -- ekr or jis, can you fill in some details? -- but 
> they probably 
> include PKCS 1 and 7 (published as RFCs -- btw, there is an obsolete 
> RFC cited for PKIX).  I frankly don't recall if the preferred hash 
> algorithm is in the X.509 certificate, though the public key 
> algorithm 
> used is implicit in the key type in the cert.  Similar 
> concerns apply to
> PGP_CERT, but I don't even know what to cite for it.
> 
> --- here comes a response to the above from Eric
> 
> I agree that this is unsatisfactory, on several fronts:
> (1) It only appears to be possible to pass a single certificate.
> What about certificate chains?
> (2) It doesn't actually SAY that a signature is what is present 
> in the authentication data field, though I suppose we're supposed
> to intuit that.
> (3) It doesn't specify the digest algorithm.
> 
> In answer to your questions:
> (1) It's necessary to reference PKCS-1 [RFC 2437] since that describes
> how to perform RSA signatures. (I'm assuming that they want to use
> PKCS-1 rather than PSS or some other newfangled RSA padding
> If DSS is to permitted they should also reference FIPS 186-2.
> 
> (2) It's not necessary to reference PKCS-7 unless you're using
> it as a certificate chain container. (See my comment about
> chains above).
> 
> (3) In general, X.509v3 certificates do not carry preferred digest 
> indicators. Either the digest name should be manually configured
> or contained in the message. While it's technically possible
> to discover what digest was used from the signature (it's in the
> DigestInfo), generally APIs and hardware assume that you already
> know. 
> 
> 
> Further more:
> 
> (1) Section 4.1 talks about "shared private keys". This is confusing
> since "private key" is generally used to refer to the private half of
> an asymmetric key pair. I think this would be clearer if it talked
> about "shared symmetric keys".
> 
> (2) The Kerberos authentication mechanism doesn't appear to contain
> authentication data but instead merely the principal name. The text
> here suggests that the authentication is interactive:
> 
>       An authorizing entity is configured to construct the 
> AUTH_SESSION 
>    policy element that designates use of the Kerberos authentication 
>    method (KRB_PRINCIPAL).  Upon reception of the RSVP request, the 
>    router/PDP contacts the local KDC to request a ticket for the 
>    authorizing entity (principal@realm). The router/PDP uses 
> the ticket 
>    to access the authorizing entity and obtain authentication 
> data for 
>    the message. 
> 
> That seems unusual. Wouldn't you want the authorizing entity to send a
> ticket, thus avoiding a round trip? Is the problem that the
> authorizing entity can't guess the principal name of the router/PDP?
> If so, how does he know it's right when the router/PDP asks for
> authorization? What are the contents of the "authentication data" that
> the router/PDP obtains? This all seems quite hairy and underspecified.
> 
>