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

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

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.