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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:10:47 +0200

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:[email-masked]]
> 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.
> 
>

---

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Tue, 6 Aug 2002 12:39:13 -0400

Bert, Steve, Eric, All,

Sorry for the late response. I just came back from an overseas meeting and 
the other co-authors were on vacation.
Please see my comments/questions below.

Cheers,
Louis-Nicolas

> Sent: Monday, August 05, 2002 7:11 AM
> To: Rap-wg (E-mail)
> Subject: RE: draft-ietf-rap-rsvp-authsession documents
> 
> 
> OK, w.r.t. documents:
> 

YES - That's what RFC-2253 specifies...I can clarify this in the draft.

>   that the system be using NTP or GPS.

No problem. We specified NTP...I will make this clear also.

> > we can resolve this by email in the next couple of days.

I agree. Once we agree on the changes, I will provide an updated version.
Hopefully,
we can resolve all issues this week.

> > that string is defined in 2104.  Why truncate to 96 bits? 

I simply followed what was specified in the COPS RFC (rfc 2748 SECTION
2.2.16) to encourage
re-use of what has been specified already. But, as you suggest in the text
below,
I am fine with 16 bytes.
 
> > 	is consistent with the configured table entry.

This text does clarify. I will input it your suggested text into the
appropriate sections of the next revision.

> > PGP_CERT, but I don't even know what to cite for it.
PGP_CERT: Maybe Eric can help out here also? If not, I will dig deeper into
this and provide the references and needed text.

> > What about certificate chains?

We should support certificate chains. We define it as follows:
8  X509_V3_CERT        A chain of authorizing entity's X.509 V3  
                             digital certificates.

I can simply state this also in section 4.3 and reference
the appropriate RFCs (see comment below). 

> > in the authentication data field, though I suppose we're supposed
I though this was sort of straightforward. I can add a sentence specifying
that
a signature is present.

> > If DSS is to permitted they should also reference FIPS 186-2.

Will add a reference to RFC 2437.

> > it as a certificate chain container. (See my comment about

Yes, should be supported. Will add a reference to PKCS-7.

> > DigestInfo), generally APIs and hardware assume that you already

We would prefer to have this contained in the message. How should I specify
this?
Should I simply state that the preferred digest name is contained in the
certificate?
What do other applications using X.509v3 certificates specify?

> > about "shared symmetric keys".

Agreed. Will make the change.

> > the router/PDP obtains? This all seems quite hairy and 

This is explained in section 9:
"If shared private keys are not a valid option, the Kerberos 
   authentication mechanism is reasonably well secured and efficient in 
   terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain 
   the principal@realm name of the authorizing entity. This is much 
   more efficient than the PKI authentication option. "
Does that answer your questions? Basically, since only the principal@realm
name is needed
the AUTH_SESSION is smaller in size (as compared to if it contained the
kerberos ticket).

---

From: "Durham, David" <[email-masked]>
Date: Tue, 6 Aug 2002 09:56:53 -0700

> From: Louis-Nicolas Hamer [mailto:[email-masked]]
2.2.16) to encourage 
below, 
> I am fine with 16 bytes. 
  
[Dave] COPS RFC truncates the HMAC-MD5 because a full precision 16 byte HMAC
opens the system up to attacks. It is recommended to truncate to some subset
of the bits. See 2104 section 5. Note also that the HMAC-MD5-XX string
convention is indeed introduced in RFC 2104 section 5!